Monday, July 30, 2007

Come and join our agile team...yeah, right

I have recently been invited to join a(nother) "Agile Team" as a senior developer rather than coach. You might have already gathered that I am becoming increasingly sceptical about these claims having been caught out before.

I have no idea whether the latest offer is truly agile, or faux agile, but it got me thinking. What am I looking for in an Agile Team before I can join it while feeling safe enough to leave my coaching hat at home? Here are my initial thoughts:
  • fixed, short iterations with regular retrospectives
  • story based scope specification with a suitable Customer involved with the Team
  • regular replanning based on real, measurable progress
  • full integration of QA within the team
  • test coverage greater than 80%
  • regular (ie multiple times per day) automated integration testing
I'm sure there are more but these seem to be the essentials that are most often missing.

If you can't check these basic boxes then please have the courage and wisdom to recognise that something is wrong and get help!





Friday, July 20, 2007

Teaching pigs to sing....

"Never try to teach a pig to sing. It wastes your time and annoys the pig" (Robert Heinlein, Time Enough for Love)

When trying to become agile, Team members
quickly tend to fall into three main categories (the percentages are purely based on my empirical observations and should not be seen as set in stone or based on scientific study!).

10-20% will "get it". These are the guys and girls who will be able to use the techniques to learn from their mistakes, spread their wings and perform. They are the future of the new, agile Company.

60-80% don't "get it", but are willing to try, or at least toe the line. They need more guidance about how to work efficiently, and that things are OK. They need more reassurance that the Team does not need this, that and the other supporting items (eg the massive Big Up Front Design documents, or a full specification signed in triplicate). With careful nurturing some people in this bracket will "get agile" (and trust me, the lightbulb moment when they do is one of the most satisfying moments of any Coach's career...). However those that don't really understand the principles do follow the basic ground rules and are not actively damaging to the agile process or the Team as a whole. In fact gentle pushback and respectful challenge from people who don't fully understand is healthy and productive.

10-20% of the Team don't "get it", will never "get it", and in fact really, truly don't want to "get it". These people are the biggest danger to any agile transition since they are not always obvious but will actively undermine changes to the status quo. More obvious behaviours that I have witnessed have included aggressive, disrespectful and/or unecessary challenge, refusal to adopt new working practices agreed by their Team (including themselves!), continuing to use old heavyweight processes in addition to the lightweight replacements, refusal to engage with the Team as an equal member and so on.

Anyone falling into this final group can cause huge amounts of damage to any agile Team but this damage is multiplied in a fledgling agile environment since the result will be bad decision making in order to placate someone who has no interest in working smarter.

So what to do? A difficult decision needs to be made but ultimately the damaging disruption has to be neutralised as quickly as possible - usually the easiest remedy is to transfer them from the agile Team to one more suited to their skills and temperament. 

Alternatively you can keep trying to educate...how are you at giving singing lessons?

Friday, July 06, 2007

"I wouldn't start from here"

There’s an old joke that goes something like this:

“A driver is lost in the darkest depths of the countryside trying to find his way back to the hotel where he is staying. In desperation he pulls over to ask directions from one of the locals. “Excuse me”, he says, “Can you direct me to the Hotel please?”. The local looks at him for a moment, sucks his teeth and says “I wouldn’t start from ‘ere, Bor’”.

When switching to agile processes there is a temptation to not “start from here”, but to try and create a sort of alternative reality before you start where it will be easier to migrate to the new process. This misses the point.

To “be agile” you need to
  • Have the honesty to recognise where you are right now
  • Have the courage to admit where you are, warts’n’all
  • Now fix it one step at a time
  • Repeat...