I’ve been through quite a few delivery teams practicing Agile methods in my last 6 years in the Agile software development field, and I often get the question which Agile story tool should we use. Which is the best one? I can already see some of you shaking your head and thinking:
“No no no… We don’t need a tool”.
“Its anti-Agile, the cards are supposed to be placeholders for a conversation, tools promote the opposite.”
“Its waste… it will create extra work for little extra value.”
“I have a physical wall right here, if you want to know what is going on, come and look at it, and talk to us.”
“You’re pushing a tool on us just so you can micromanage us from your ivory tower, we are managing just fine, Agile teams need to be self-managing.”
I can sympathise with you, I’ve had exactly the same reaction over the years whenever a Project or Development Manager approached me about implementing an Agile tool on one of my projects.
On the other side of the fence are the managers:
“What happens if the cleaner comes by and takes down all the story cards, or what if a card falls off the wall and gets swept away.” (my personal favourite… and hard to answer without the rolling of eyes)
“I have teams in different buildings, on different floors, I’d like to go to one place to see all the story walls, and keep up to date of what is going on.”
“What happens to the story cards after we are finished with them? Where is all the documentation?”
And the ones that they may be thinking but not verbalising:
“How do we ensure traceability and accountability?”
“How can we track our projects?”
“How do we get cross team metrics?”
Why you need Agile tools
Documentation
As most Agile devs will tell you code is self documenting, but the reasons behind certain design or implementation decisions may not always be clear. These decisions probably occurred a while back, and your memory is a bit hazy on the details, or the people involved are no longer with the team.
If, like me, you’ve ever tried to sort through boxes and boxes of old story cards, to try and find the card in question, and then try and piece things back together again without the sticky notes, you will know how time consuming and painful this can be, and answers are not always available.
A tool can help you find that old story quickly and get all the decisions around it. Memories can be very fickle at times, and this can help prevent some arguments, and a-lot of angst.
You could always try and put the meta-data such as who worked on the story, decisions, comments, code version, build number, onto the physical card but as with any house-keeping this can be a little difficult to maintain. A project tool (through integrations with source code systems, build servers, etc.) can automatically pull this information together for you in a seamless way and make it available against the story.
Backlog Management / Planning / Review
Many teams like to maintain a physical backlog, and there is nothing wrong with that at all. It makes it easy to visualise the scope, to group things, to change priority and generally move things around.
If you have ever been a Product Owner/Customer though, you will know that as soon as you walk over to start looking at the wall people naturally walk over to “help” you, to explain the stories, to get an understanding of your priorities.
Sometimes its nice to have some peace and quiet to look through the backlog and think. To let it sync in, and have a think about what is important to you and the product, or to share it with your manager or peers, before getting into any discussions on priority and planning.
A tool can give you that arms length space, to have a look at the backlog without having to have a discussion about it immediately. Of course the danger with having the backlog available via a tool, is that there may be the temptation by some product owners to use it as a way to direct from a-far without much interaction.
A tool also provides an easy way to extract groups of stories, backlogs, iteration, or release plans to use for planning meetings, reviews or showcases that are away from the project area, as are required from time to time.
If you don’t have a tool, you’ll end up wasting time by either moving the whole wall, or sitting in front of it with a laptop and putting it in another document that you use for your presentation.
Release Management
Once everything has been built, tested, accepted by the customer, and its time to push it into production we typically walk over to the Operations guys and say “So how do I get this into production?”. This is where the fun begins.
If your system is small and self contained then the conversation is short and simple. If on the other hand, your system is made up of multiple deployed components that have dependencies on each other and potentially other systems, then your Ops team is going to want to know what changed and what didn’t.
A tool can help by identifying which components of your system were touched by the stories in the release, which can help facilitate the deployment conversation with the Operations team.
So back to the question at hand, our clients keep asking us which is the best Agile tool to use? We thought it might be useful to use our experience to try and answer this question and being business analysts, we did what was natural, we started listing all the requirements we expect of an Agile story tool and ranking each tool against it.
We didn’t get too far down this path before we realised that approach wasn’t very Agile as it required a large up-front investment before delivering any value.
What we hope to do is to build up a framework that we can use to help compare Agile story tools, but we will do this by reviewing the tools one at a time, and will publish these reviews so you can learn more about these Agile tools as we do.
Come back next week for our first review in the series which will be on the old favourite Jira, with Rally and Trello to follow. We will assess the level of interest after this point to determine whether to continue further, so please let us know if you find the reviews interesting and useful.
