MMMM…Pliancy
Google pedestal aside, Steve Yegge’s post last week (Good Agile, Bad Agile) has a lot of choice pliant leaning remarks. Here’s a few of them and my comments.
Teams are always situated close together in fishbowl-style open seating, so that pair programming happens exactly when it’s needed (say 5% of the time), and never otherwise.
This has been exactly my experience with pair programming. It is good when it is needed but it is not needed 100% of the time. Now maybe your company likes 100% pair programming and it works for you, and that is fine, but if it isn’t working for you, it would seem others (myself included) have had success just doing it when it made sense. Our suggestion is you spend a bit of time figuring out if it makes sense and go from there. On a more general note, using a technique when it makes sense is what pliant is all about.
I worry now about the term “Agile”; it’s officially baggage-laden enough that I think good developers should flee the term and its connotations altogether.
I’ve gotten several comments from people asking why we’ve insisted on creating a new term to describe how we develop software. Essentially what we are doing is small-a agile, but because of the baggage that comes with “Agile” and the difficulty with discussing “Agile” vs “agile”, a new term was needed. It was needed if for no other reason than to make _talking_ about it easier to do.
In the real world, every single participant on a project is, as it turns out, a human being.
This is something that “Bad Agile” (as Steve calls it) doesn’t handle well in his opinion. I agree with him. It seems to me that productivity in many Agile methodologies is assumed to be constant, hence the insistance on pair programming, for example. If it were the case that all programmers were consistantly productive, had no personal issues to deal with, didn’t have a baby that wouldn’t go to sleep the night before, didn’t have problems with their love life, were best buds with all their co-workers and generally didn’t have any emotions at all, then many “Bad Agile” practices would work all the time. But, like Steve said, programmers are human and however an organization develops software the fact that the programmers are human has to be taken into account.
So if I were you, I’d take Agile off your resume. I’d quietly close the SCRUM and XP books and lock them away. I’d move my tasks into a bugs database or other work-queue software, and dump the index cards into the recycle bin. I’d work as fast as I can to eliminate Agile from my organization.
And then I’d focus on being agile.
Exactly. Focus on being agile and to hell with all the -isms.
Think. Evaluate. Change.