Steve Fenton

<< July | August | September >>

Wednesday, 1st August 2012

Following on to some extent from my article The Methodology Philosopher, I wanted to add some further clarity and context. This is in effect the second half of the article as the first one described a problem, but not the solution.

The first article was triggered by a discussion on a forum about measuring cycle times. Most of the discussion was healthy - different people adding different perspectives and interpretation of what cycle time meant, and the reasons you would measure it.

The part of the thread that wasn't healthy was that a very noise contributor who was very clearly a methodology philosopher, was spending an inordinate amount of time telling everyone that they were wrong. The techniques used were not unusual and exhibited typical troll-like patterns:

• undermine the author of a response
• publish a mis-interpretation of the response that makes it sound wrong
• argue about the use of particular words or their meaning
• use words out of context to make judgements about unspoken meaning
  
• make back-handed statements about the author
• quote from respected sources and tell people it is the one true way

I was, unfortunately, dragged into an exchange because I naively believed at first that my response had been genuinely mis-understood. When I realised I was being gamed by a pro-troll I attempted to exit gracefully and did penance by writing a blog to remind myself to be more careful in the future.

After having reflected on events for a day, I realised that the real damage being done is that the person who asked the original question may not know the difference between someone who is right, and someone who is noisy and many discussion forums make a much bigger deal of someone who is noisy, either by listing them as influential or by awarding badges that reward volume, not quality. I also realised that I had, perhaps, suggested that there was an "ideal way" and a "practical way", which may be true - but in no way means that the "practical way" is a compromise or cheapened version of agile.

So I would like to set the record straight.

Whether you are adopting agile or running a mature agile process, I sincerely hope that you aren't doing it "by the book" in an idealistic way. One of the strongest arguments in favour of agile is the fact that the methods you use are part of a short feedback loop, just the same as any features that are being created using agile. If the "ideal way" says that you should have yellow sticky notes, but you decide to use yellow sticky notes for bugs and green sticky notes for features - that is perfectly valid. If the "ideal way" tells you to measure the time it takes to get a feature from original idea all the way through to delivery, but you think there is value in measuring the entire cycle time and the "in progress" cycle time - that is perfectly valid.

Whatever adjustments and changes you make to the process is absolutely valid, just as long as you measure and improve constantly. Make a change, see if it makes things better and re-adjust constantly. These changes are normally discovered and discussed in agile retrospectives, but can sometimes just be light-bulb moments discovered at any point.

This is why a question on an agile forum may get several different answers that aren't automatically wrong just because it isn't the Agile Certified way to do things.

If you are asking questions about agile, don't be afraid to try out more than one of the suggestions you are given to see what works for you. Don't get steam-rolled by the white-noise of narrow-minded trolls - keep an open mind and do what's right for your organisation.