141–150 of 189 posts
Must be Wednesday. TODO next week: Go collect all of the blog post cycles of "Agile Sucks" -> "No, agile in theory is fine, it's just marketing and implementation that sucks." It's a full-fledged meme at this point. And I think if you distilled all of these posts down to their essence, you'd have a really solid critique and we could build some lessons learned, and the next time someone gets burned by a bad implementa…
(blog author) +1
Earlier quoted context omitted.
No amount of process can fix bad communication. Sure it can. If I've got a team member who can't be bothered to let people know what he's doing on his own, I can hold a standup every morning to make sure the information gets communicated to the team. If he lies every day about what he does, the longest he can go is one sprint before his work gets verified. I'm trying to imagine standups on a building site. I don't kn…
" Sure it can... If he lies every day about what he does, the longest he can go is one sprint before his work gets verified. " That's not fixing bad communication. That's wrapping it up in process, and calling it "good enough". The team communication, and probably its morale and output, still sucks. " etc. Pretty much what actually happens at a construction site " That communication happens continuously, throughout t…
"Good enough" is certainly better than "not good enough". And it doesn't have anything to do with morale. The team's morale might be sky-high and they can still make mistakes because person A didn't know what person B was doing in a timely fashion. People have a tendency to overestimate their skills in general, and communication is no exception. Standups are just a form of insurance and cost almost nothing. Even if your team communicates like they're telepathic, 15 minutes a day in standup isn't going to hurt them.
If isn't happening continuously, throwing a standup at it ain't gonna fix it.
If I'm managing 5 job sites, I'm not there continuously. It might not be perfect, but once a day sure beats nothing. Most of the time when someone is doing something wrong, they don't know they're doing something wrong. No one is going to call me up and say, "Hey, I'm about to do something stupid and wanted to run it by you."
See, the thing is, the success of the coding-part of a project is dependent on the calibre of the engineers doing that coding and not the process they follow. The success of the non-coding part of a project is dependent on the calibre of your sales/management and how they interact with the customer. If you are trying to prescribe some rigid process, however lean, in order to make that interaction effective, then you…
[T]he success of the coding-part of a project is dependent on the calibre of the engineers doing that coding and not the process they follow. And the success of an NFL team has nothing to do with process either. It's all the players. That's why they never hold practices or review footage with the coaches. Who needs set plays? Tom Brady just tells Wes Welker to go deep and get open. You guys up front block. That's it.…
the success of the coding-part of a project is dependent on the calibre of the engineers doing that coding and not the process they follow.
seems to me obviously untrue, for >3 engineers, and the larger that count gets, the more process you need. As an engineer I find that statement very appealing, but experience suggests it's off base.
Earlier quoted context omitted.
" Sure it can... If he lies every day about what he does, the longest he can go is one sprint before his work gets verified. " That's not fixing bad communication. That's wrapping it up in process, and calling it "good enough". The team communication, and probably its morale and output, still sucks. " etc. Pretty much what actually happens at a construction site " That communication happens continuously, throughout t…
That's wrapping it up in process, and calling it "good enough". "Good enough" is certainly better than "not good enough". And it doesn't have anything to do with morale. The team's morale might be sky-high and they can still make mistakes because person A didn't know what person B was doing in a timely fashion. People have a tendency to overestimate their skills in general, and communication is no exception. Standups…
In the scenario that you described, someone went from not communicating at all to lying every day, and getting "caught" at the end of a sprint. Standups didn't fix anything there. Also, there is a world of difference between calling something good enough, and it being good enough.
If I'm managing 5 job sites ... once a day sure beats nothing
If, as a manager of 5 teams, you feel like you need a direct, daily report of what every person on every team does, your life is going to be hard. If you attempt to control those teams by adding more process, you will interfere with the productivity of your good teams, and your bad teams will continue to suck.
Earlier quoted context omitted.
[T]he success of the coding-part of a project is dependent on the calibre of the engineers doing that coding and not the process they follow. And the success of an NFL team has nothing to do with process either. It's all the players. That's why they never hold practices or review footage with the coaches. Who needs set plays? Tom Brady just tells Wes Welker to go deep and get open. You guys up front block. That's it.…
Programming != football.
Earlier quoted context omitted.
That's wrapping it up in process, and calling it "good enough". "Good enough" is certainly better than "not good enough". And it doesn't have anything to do with morale. The team's morale might be sky-high and they can still make mistakes because person A didn't know what person B was doing in a timely fashion. People have a tendency to overestimate their skills in general, and communication is no exception. Standups…
"Good enough" is certainly better than "not good enough". In the scenario that you described, someone went from not communicating at all to lying every day, and getting "caught" at the end of a sprint. Standups didn't fix anything there. Also, there is a world of difference between calling something good enough, and it being good enough. If I'm managing 5 job sites ... once a day sure beats nothing If, as a manager o…
We don't do standups to fix broken team communication. We do standups to augment ordinary team communication. If you've got an uncommunicative team member, that's not unusual. If you don't have an uncommunicative team member, now that's unusual.
If, as a manager of 5 teams, you feel like you need a direct, daily report of what every person on every team does, your life is going to be hard.
I may or may not need the report, but I want to make sure that every member of every team knows what's going on on their team. That's not adding process for process' sake, it's just ensuring communication rather than leaving it to chance or some utopian vision of human nature. A 15-minute standup isn't going to hurt a good team's productivity, while it could greatly improve the productivity of a mediocre team.
Earlier quoted context omitted.
"Good enough" is certainly better than "not good enough". In the scenario that you described, someone went from not communicating at all to lying every day, and getting "caught" at the end of a sprint. Standups didn't fix anything there. Also, there is a world of difference between calling something good enough, and it being good enough. If I'm managing 5 job sites ... once a day sure beats nothing If, as a manager o…
The scenario isn't about the lying, I was just anticipating the argument that the standup wouldn't improve communication if someone wanted to subvert it. The basic situation---a teammate who isn't communicative---can only be 'fixed' by getting him to communicate. You might argue that I fire him and spend weeks looking for someone who codes as well, or alternatively hire a 'communication coach' to help him with his pe…
It takes a lot to noticeably hurt a good team's productivity. But it's mean, just fucking mean, to punish a good, productive, communicative team with more process because you also manage crappy teams.
[Obligatory plug and disclaimer: Agile professional who wrote an earlier rant "Agile Ruined my Life" http://www.whattofix.com/blog/archives/2010/09/agile-ruined-... Also I am writing some practical how-to Agile e-books trying to undo some of the damage: http://tiny-giant-books.com/scrummaster.htm ] Just differentiate between what Agile is and how people are pushing Agile on you. Different things entirely. Agile is be…
Exactly. And this shit makes me furious. I got involved with this stuff before the term "Agile" existed. At the beginning, it was a bunch of professionals (mostly developers) sincerely trying to find better ways of working. Extreme Programming, for example, came to be because the developers were really interested to experiment with how their team got stuff done. It breaks my heart that in the ensuing decade it has tu…
Rather than teaching people processes, they should help foster better ways of actually thinking about the code itself. E.g., learning new programming languages and frameworks gives one a variety of perspectives to think about code from.
Earlier quoted context omitted.
The only people that screwed it up are the ones that monetized it. They made it a) rigid based on their definition b) defined themselves as experts in making teams agile based on their rigid definition c) charged for it PS. These same guys, once they couldn't squeeze anymore blood out of the Agile stone, moved onto a new marketing term, "craftsmanship". They now charge the same clients, even more money, to teach them…
Depends on who you're talking about here. Bob Martin one of the craftsmanship people, is very sincere in his desire to make the field better. I'm not sure about who's cropped up lately, though. Also, it's very, very rare for somebody to make a mint on a software book. I've talked with a number of authors, and their universal view is that writing code pays much better than writing a book. You do it because you have so…
And let me just leave this here... http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.htm...