Once upon a time I did a six month contract working on a new web development project at a large corporate. There were about 25 people on the newly formed team – a very large team by modern standards. As with any other “agile” team, we would walk the card wall each morning at standup. There would be around 20 cards in the Doing column at any one time which caused standup to run for longer than was comfortable for either our feet or our attention spans.
It took just under 6 months to get to the first release of the software. During that period the wall was always completely covered with cards. By the time we made it to production, hundreds of cards had moved across the wall.
What did our team of 25 people deliver in that first release?
A login screen with four hyperlinks. That’s it. Six months of work and hundreds of cards amounted to a user being able to sign up, login, and click one of four hyperlinks.
If you were to capture the functionality we delivered on that project on traditional agile User Stories, you would need only three cards. Card 1 – I want to sign up. Card 2 – I want to log in. Card 3 – I want to click on a hyperlink. If you really wanted to pad it out you could have a separate User Story for each hyperlink.
I like to imagine what it would have looked like for 25 people to stand around a card wall with just those three User Stories on it. I like to imagine the CEO popping by for standup one morning and being presented with a wall which demonstrated the actual value that project was delivering. I like to imagine the CEO mentally calculating the salary of the 25 people who were building a login screen which showed hyperlinks. Instead, we had hundreds of cards on our wall and on each card was a Task.
Task cards have been a bugbear of mine for some time now and not just on obviously dysfunctional projects like the one I have described. There are several reasons for this:-
1. Clarity
As the above story demonstrates, task cards add noise to a wall. There are always going to be many more task cards than user stories. If you put each task on a card and each task card on the wall they will dominate the space, especially in the Done column. Task cards make it more difficult to see what value has been delivered to the user.
2. Focus
Part of the original motivation of User Stories was to foreground the needs of the users. The old waterfall documentation was full of technical jargon making it very hard to know what the real underlying needs were. User Stories were a way to redress that. Task cards reintroduce technical jargon to the card wall. They bring the focus back to technical tasks, something the original agilists were trying to avoid.
3. Feature Factories
The desire for task cards seems to be closely correlated with the Feature Factory mindset. Seeing lots of (task) cards go across a wall is a natural fit with a way of thinking which prioritises output over outcomes. It is hard enough to focus on outcomes as it is. By filling up the card wall and the team’s attention with tasks, we make it even harder. We promote a culture of getting cards across the wall.
4. Visibility
The primary reason given for task cards is that we want visibility of what other team members are doing. This is a worthwhile goal. However, we already have a forum for that. It’s called standup. Given that tasks are fleeting in nature, briefly discussing them at standup seems to be about the right amount of attention to give them. Use standups to discuss tasks for the day and the card wall to represent when those tasks add up to real value delivered.
5. Relevance
Modern agile teams often have several non-technical people who are also stakeholders in the card wall. Task cards are not relevant to these people. User Stories are. Filling up the wall with task cards makes the wall less relevant for non-technical team members.
Task cards are not responsible for the ills in modern software development. They are a symptom of those ills. What most agile teams need these days is less focus on the technical aspects of delivery and more on verifying the business value of the software. On a team that is co-located and has high levels of trust, visibility into the minutiae of development is not required. And on teams which have good flow, the flow is of value to the users and not task cards to the Done column.
P.S. Although I believe that task cards on a wall are not a good way to manage the work of an agile team, I am firmly in favour of tracking tasks as a way for individuals to manage their work. I use task lists all the time to manage both my work and personal life and I highly recommend them. The Checklist Manifesto is a great read on that subject.