Perverting Agile

Long, long time ago I bought myself a book about taekwondo: to my disappointment, the book clearly stated that unfortunately it is not possible to teach yourself a martial art just by reading a book. It is probably true for any sort of human activity that it helps to practice it with others, and better yet with people who actually know what they are doing. Agile is no different in this respect and it seems to me that way too many people picked agile from a book or the internet in the process somehow missing the small print. Here are some examples from the last couple of weeks…

An hour long stand-up

As the name implies, daily morning team meeting should be done while standing, and the reason to do it this way is to prevent the meeting to take too long. If there are issues which need to be discussed, they are raised during stand-up and the follow up happens later. It is also important that only “pigs” have a right of to say anything during stand-up. Chickens, management etc may by all means participate but they should remain silent. Stand-up is not a management  report meeting!

Marriage programming

Pair programming is an extremely valuable tool in agile toolkit, but it has to be used when and as required. And when it is used, the idea is that pairs change over the course of the project, day or whatever. Putting people in pairs which never change completely misses the idea of cross-pollination of skills! So if you do want your team to do pair programming, do not force your developers into contractual marriages.

Roll-call retrospective

The purpose of the retrospective is to gather feedback from the team as to what went well and what needs improvement. If the retrospective changes into a roll-call type meeting where everyone says what he thinks in predetermined order, I doubt it will inspire anyone. Retrospectives have to be a bit chaotic and cause discussion (or event better an argument) to be productive in any sense. Teams paralyzed by fear and disciplined like a small army have little chance of coming up with any genuinely interesting insight.

“We don’t do design ‘cause we’re agile”

Complete nonsense if you ask me. If you can get away with a bit of scribbling on the back of an envelope or whiteboard, by all means do so. But just because simple problems can be tackled this way it does not mean that when you come across problem/requirement substantially more complex, you should not use more formal design approaches.  Inspect and adapt: agile is among other things about using the right tools at the right times. Back of an envelope is good “tool” but sadly not one suitable for all classes of problems.

March 16 2010
blog comments powered by Disqus