A note on electronic agile tools
Friend: “You’re dead against agile tools, aren’t you?”
Me (confused): “Erm...not exactly....”
Friend: “But didn’t you persuade several teams in <major co> to throw out <agile tool vendor> the other year?”
Me: “Not me. The team simply decided that the tools were not providing value to the way they worked...”
My view is that many teams prematurely select an “agile tool” before they know what they need. Teams (and departments, and companies) are like kids in a sweetshop when it comes to new toys, and want to buy the glossiest, most feature-rich application. This is mostly because they want the mythical Silver Bullet that will allow them to “do Agile” painlessly and with minimal disruption.
So what happens when this shiny piece of software gets installed? After all, that nice salesman said it will kick-start your agility...
Feature Frenzy. That’s what happens. You can imagine the thought processes:
“We must use every single thing in this software package. We’re paying a pretty penny for the licensing after all. And it’s there for a reason, right? Oh look, there is an ‘Estimate’ field on the Story entry page, and it says ‘days’. So let’s ask developers to estimate in real days (after all, that’s the same as MS Project does).
“Wait a minute...we can put in Actual Time as well. Wouldn’t it be great if we knew how well we were estimating, and feed that back so we get better and better until we know exactly when a project will be delivered.
“Oooh...even better. It gives us ‘Percentage Complete’, so we can tell how far from finished Stories are! Cool!”...then when things start to slip from these “Estimate” fields...
“But you said that would take 1 day, but it’s taken 5 days....AND it’s been at 90% Complete for 4 of those days...that makes you a Bad Person”This scenario is based on real behaviours I have seen more than once in teams who have asked me for help, and I have no doubt that I shall see them again. You get the idea - the process and behaviours begin to map to the tool, not the other way around. Or to put it another way, the tail is wagging the dog. The team didn’t know what they wanted, so they used the tool as their process model.
I suspect this is why some may think I am anti-tools (or manically pro-pen-and-paper?).To put the record straight, I am anti-inappropriate-tools. I am against prematurely selecting a tool before allowing your process to bed-in. All agile and lean teams end up doing things slightly differently - estimation, swim lane mapping of the current process and so on. The most efficient application of these proven techniques relies on flexibility. And yes, I have helped some teams to realise how some electronic tools were hindering them rather than helping.
So select your electronic tools to match your mature process, or at very least ensure that it is flexible enough to cope with anything you throw at it (products with this level of flexibility are starting to appear).
Also, never adopt any feature in an existing tool until you see a concrete, real-world and evidence-based reason that you need it.
If you are not using many of the facilities in a particular tool you have purchased, save your cash and look for a cheaper (free?) version that does less.
Finally, if you are using an electronic tool make it visible in the same way as a whiteboard would be or you will lose most of the benefits - bite the bullet and invest in a touch screen TV/monitor for each team at each location it is used. If this is too expensive, then I see a trip to a stationers for pens and cards in your future....