Thursday, January 21, 2010

New to Agile? Want to know which tool to use?

There is a re-occuring question I am asked from time to time, and I see on discussion forums. It again appeared last week:

“We are new to Agile and are looking to adopt a tool for managing the process... which tool would you recommend?”

There are variations on this question (replace Agile with Scrum/XP/Kanban/whatever, or replace “managing the process” with requirements/development/testing) or maybe its put as “Does TFS work with Scrum?” or “Is Target Process the right tool for XP?” but its the same basic question.

Anyway, I try not to take the bait on these but last week I couldn’t resist and answered it. My answer solicited a positive response from several people so I thought I’d share my answer with more of you and expand on it a little:

For anyone new to Agile (all flavours, Scrum, XP, etc.) I strongly advise avoiding all software tools for managing the process until you get the hang of working in the new manner manually. You will have a faster and more fulfilling learning experience if you do it by hand - pens, cards and white board - for a few weeks before you look at a tool.

There are several dangers with tools:
  • You may mistake the tool for the process: e.g. using Rally doesn’t make you Agile
  • The tool might not work quite the way you need to work: in your company the tool might not do something you need to do
  • The tool might be too strict: when your learning you need a bit of slack
  • People may communicate through the tool rather than face-to-face
  • You may spend time customizing the tool when you should be focusing on the actual work
  • And, when you find things don't work quite the way you want them to it is much easier to change a card or a board than change the software.
Something magical happens when people work with cards. Abstract “work” becomes real. We relate to it in different ways when it has a physical presence and you can move it about. You don’t get that with a tool.

Once you have a tool the tool easily becomes an impediment to further change:
  • To change you need to change the tool
  • You need time to reconfigure the tool (if you can)
  • You need time to move your data to another tool (if you can)
  • You need to justify the change of tool to those who paid for it: “We paid $10,000 for these licenses 6 months ago, what do you mean you aren’t using it any more?”
  • You need to justify spending money on another tool: “And you want me to spend another $5,000 on another tool? Will you use it this time?”
  • And you have invested yourself in the tool, you don’t want to admit you got it “wrong”.
Nobody ever got fired for spending too much on index cards, or for throwing a pack away.

Yes I know there are genuine reasons people want to use a tool to help with their work. But choosing the tool before you change is putting the cart before the horse. In my opinion people and teams which spend time evaluating and deciding on their tool are resisting change.

Damn the torpedos just do it!

Do it by hand to start with, give it about 3 months like then then look at some free tools, don't waste time on customizing anything. Give it another 3 months then you should have the experience to find the best tool for your team.

Don’t be scared to change tools - and don’t invest so much in one tool that you can’t change in a few months when you realise its not right.

I’m not saying “Don’t use tools”. To be honest my preference is not to use them, stick to paper, pens and boards. However, I recognise that on some occasions they can help (remote working springs to mind.) But, before you start using one be clear what you need to get from it.

The thing is: Agile is about learning, and you have a much better learning experience when you are manually managing the tasks. If you need a tool to manage them you probably have an over complicated process. When you insert a tool between you and the process you loose sight of what is happening. The tool is a box labelled “magic happens here” and complexity can set in.

There is a story. Its about Jack Kilby - not heard of him? You should have done, he was co-inventor of the Silicon chip. A few years after inventing the chip he helped Texas Instruments develop the calculator. But he regretted the passing of the slide rule.

He said: the slide rule gave engineers the numbers but they needed their intuition to know were the decimal point went. Was the answer 123,456,78 or 123.45678? The calculator took that away and he thought that made for poorer engineering.

Using an tool to manage your Agile process is like that. It removes part of your intuition, part of your understanding.

8 comments:

  1. Excellent post!

    One more thing why pens, cards and white board is better at first is because it makes process adaptation more fascinating for the team. It is something non-typical and new, thus provoke curiosity. As a result even members who are apathetic to the change start to change their opinion.

    ReplyDelete
  2. Thanks for bringing up this important topic.
    I think that many people associate "a tool" with formality and seriousness of "the process" and don't pay attention to the difference between information communication and its preservation.

    The tendency to focus on the mechanical aspect of agile or lean often overcome the essential need to balance between the mental aspect and it's mechanical counterpart. Good agile/lean trainers and coaches starts with building a sound mindset for agility and continuously nurture that along the way of teaching "a" process or helping to build a process.

    The choice of and adoption of a tool requires maturity that comes with practice and continuous improvement; and this comes gradually.
    "what is the best agile tool to use?" reminds me of the bad notion of "best practices" that mistakenly portrays "this certain is the holly Grail for sw Dev".

    Again thank you for the excellent post.

    ReplyDelete
  3. Nice post and great writing. Enjoyed your comparisons to slide rule and not getting fired because you used cards.

    I am a tool guy but have always appreciated that the real work was done outside of the toolset. Always fought to get Engineering to Gemba in lieu of behind the computer.

    ReplyDelete
  4. Good points, one caveat - I think we are doing Agile a disservice by implying that index cards and flip charts aren't tools: http://iljapreuss.blogspot.com/2009/11/index-cards-are-tools-too.html

    ReplyDelete
  5. Allan,

    I completely agree. Have you noticed that most people don't appear to regard low-tech tools as "tools" at all? When they say "tools," they only mean electronic ones.

    ReplyDelete
  6. u are sooo right! cards, a whiteboard and excel is all u ever need!

    if not, something is wrong with your process!

    ReplyDelete
  7. Online collaborating and teaching can work, If you have trust and the right tools.
    I recently tried http://www.showdocument.com - good app for uploading documents and working on them in real-time.
    Most file types are supported and it needs no installation. - andy

    ReplyDelete
  8. Good post! There is a lot of useful information information in there to help someone get started. When I first started getting into Agile a long time ago I used XPlanner and found it all a bit baffling. Once I had done more reading around the subject it all started to fit into place. I think if I had first approached XP with cards it would have been a lot easier.

    I find that a lot of the time it is the developers who lead the march into the Agile methodology rather than PMs. Most of the time this has come about as a result of frustration with their own code and hearing about this magical Agile way that will transform their day to day lives. Unfortunately, when they try to apply the various techniques it all goes wrong because of technical debt in their codebase.

    If anyone is interested, I wrote a short introduction about my experiences.

    http://gary-rowe.com/agilestack/2010/01/09/how-to-be-agile-when-all-about-you-are-not-part-1/

    ReplyDelete

Note: only a member of this blog may post a comment.