Skip to content
August 29, 2011 / KaTe

Why do I hate “agile tools”?

When I joined my current place of employment, I learned a new term: Version One (or V1). Take a moment to hear what emotion does that trigger in you. If you don’t know what it is, you probably are a happy human being… ignorance is bliss. Agile tools are just another example of team’s demons.

I don’t mean to blame V1 as a product for anything – Rally and others are just as bad. No offence – they are decent tools, but their usage is just plain bad. And I know it’s not only in my current organization.

The common understanding of agile tools is that they will bring agile to your company. That they will induce the correct mindset, just push the install button …. As a friend of mine once said – “People can go around security system of space shuttles if needed, so how on earth (different expression was used here, but I’m not brave enough to write it here) is a simple online tool supposed to install agile in an organization?” Exactly.

In this whole flashy world of Scrum, XP, Crystal, Version One, Rally, Mingle, Ice Scrum and other brands, we are forgetting about what are they supposed to support. They are not complete products themselves – they are supposed to support values and principles. We are forgetting that there is something inside of the book’s cover. Agile frameworks wouldn’t exist if everyone read The Agile Manifesto only once with understanding!

Think about this – a team starting with Agile, would be trying to find an application for functions available in the tool, usually twisting it without help. A proficient agile team on the other hand would be limited by the tool when bending the rules to inspect and adapt.

The best tool you can give your team is the one they built themselves.



Leave a Comment
  1. John Quincy / Nov 12 2011 3:27 am

    I am still amazed at how some CIOs are fooled by the lure of ‘agile’. They have absolutely no clue as to the permanent wounds that will be left in an organization once the genie is unleashed. Fantastic developers become disgruntled coders. Lazy coders become… well actually they stay the same. And mediocre programmers become lazy coders.

    Check out this hilarious video as to why a CIO would even consider agile in the first place.


    • KaTe / Nov 12 2011 12:38 pm

      Agile/Scrum is misused. I fear the fact that it became a fashionable word without understanding it. Videos like these only prove that more and more people only want the “flash” of agile but they are not willing to change the whole organization to take advantage of it. I cannot agree that agile is degenerative. It can be misused – just like any tool, and when implemented properly, with values and ethics behind it helps organizations improve and adapt to changing markets quickly.
      Don’t misunderstand me – I’m not saying that agile is a cure for everything, because it’s not. There are companies using different approaches and succeeding with them. Agile is trying to rehumanize software development, which is viewed as engineering,while it fact it is not.

  2. chuck suscheck / Oct 1 2012 9:09 pm

    I must say, I don’t think a tool should be used at first, but the team I was working with had a lot of cards and didn’t understand sprint/release/backlog nor the flow. They also didn’t have a way to say story A is broken down into B, C, and D. Nor a good way to understand burndowns. And the stories were in 4+ documents in different forms. It was a requirements mess. I got the community version of Rally and imported all of their requirements into stories and sorted them in order. Then I made releases and we put the stories into releases. Then during planning we used the tool to pull work in. At this point we could go back to a board but having the stories typed out is much easier to update them during sprint planning. A tool actually helped to teach them agile in this case. They just couldn’t grok what I was saying until they visualized it and with 150+ stories nobody could follow what to do. Yes a fool with a tool is still a fool, but sometimes a tool is just the right answer.

    • KaTe / Oct 2 2012 3:25 pm

      Oh, I agree completetly with the tool usage especially for the product Backlog. There are many great tools for organizing PBs and they make team’s and PO’s life way easier. What I really hate is adopting a tool for a Sprint Babklog, while teams still have no idea what each element is for. Defaut settings are too complex or set to work with the process of team who created it. It drives the wrong one. What I recommend is picking a good tool for the Product Backlog and keeping the Sprint Backlog on the wall.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: