“Simplicity–the art of maximizing the amount of work not done–is essential.”
– Agile Manifesto Principles
The first part of this post examined the complexity trap agile teams frequently fall into. Underlying complexity in team and work structures are reflected in equally complex artifacts that teams and leaders adopt in an effort to understand the problems they are encountering. Unfortunately, complex artifacts including backlogs, burndowns, and task boards, only serve to perpetuate or even enhance the underlying dysfunctions.
The only effective way out of the complexity trap - in my experience - is to work deliberately to apply the Agile Manifesto Principle of simplicity quoted above. The use of simple artifacts provides feedback that allows teams, leaders, and organizations as a whole to identify complexity and address it appropriately.
Here are a few questions to ponder:
- How could the simplest thing that could possibly work be the best solution?
- What should information radiators tell us?
- Are we likely to finish everything we committed to this Sprint?
- Which stories are at risk?
- How much WIP (Work in Progress)?
- What do we need to do today – as a team?
- How many blockers are there?
- How can I help?
- How can simple tools foster and enhance teamwork?
Single-dimensional Backlog
This backlog is a single-dimensional, force-ranked list of all the items you have thought of for the product, but are not yet being developed. If you are practicing Scrum, the Product Owner sets the order of the items, whether User Stories or whatever. There can only ever be one item at the top, one item in the second slot, and so forth all the way down. In keeping with the backlog iceberg metaphor, items are more detailed at the top, less detailed as one descends through the list. When continuously groomed, a simple backlog like this ensures that the most valuable, important items are always available for a team to pull in and work on at any given time.
Minimalist Task Board
In contrast to the complex, multi-state task board depicted in Part 1 of this post, this task board is the model of simplicity. It contains a column for planned User Stories. It contains a column for planned tasks as they are currently understood. It contains a column for tasks in progress. Anything in these three columns comes under the heading of "not done" - either planned or in progress, with both of these categories clearly and instantly visible, but equally clearly not done. The fourth column holds tasks in a new state - done. The fifth and final column is for accepted User Stories, that is, stories whose Acceptance Criteria are satisfied - these stories are done.
Notice what's going on here. First there are really only two states reflected on this task board for any work item: not done and done. There are containers for planned work, mostly so that the team doesn't forget the results of conversations held during planning. Tasks in progress are instantly visible. Since work in progress (WIP) is by definition waste, this task board helps everyone focus on limiting WIP. Completed tasks move to the Done column - these tasks meet the team's definition of done and should not need to be revisited unless something out of the ordinary occurs. And finally, stories whose Acceptance Criteria the team has met - and in the Scrum world that the Product Owner has accepted - move to the Story Accepted column. These stories are done, finished, ready for customer/stakeholder review.
A minimalist task board like this one focuses the team on teamwork instead of individual work. Stories belong to no one team member, but to the team as a whole. Individuals, pairs, or groups may (and should) sign up for tasks, but the focus remains on pushing stories across the board, from top to bottom. The tasks take their proper place as a means to an end, and a highly malleable, flexible means at that.
A few additional rules that I recommend for using a minimalist task board effectively:
- Each team member's name appears on only one unblocked task in the In Progress column at a time. This rule does wonders for WIP and also helps the team focus on team goals rather than individual preferences or expertise.
- Work the stories from top to bottom - tasks deliver no value, stories do, so focus on stories regardless of individual task preference or expertise. Every team member does whatever it takes to help the team achieve its goal.
- The team's definition of done must extend as close to "potentially shippable" as possible. Using a simple task board with the binary "not done-done" dichotomy of states pushes teams in this direction.
Burndown charts are somewhat controversial these days, but I still like them, especially for new or struggling agile teams. As with most other practitioners, I don't like task-hour burndowns for a whole variety of reasons that I won't go into here. Again, new or struggling agile teams - in my experience - need to break out the relevant tasks to deliver stories effectively. The tasks themselves aren't the key - the whole-team engagement and discussion is the vital aspect here. Whole-team ownership of every aspect of every story is what we're getting at and tasks are a good lever.
Back to the burndown, we could simply burn down the raw number of tasks. I'm fine with that if the team is able to break tasks down into roughly equal chunks. Most new or struggling agile teams lack the experience needed to achieve this goal. Moreover, unless team members estimate the tasks, they don't really even know how big the tasks are. So here's a simple rule I generally recommend teams adopt: Estimate tasks in half-day/day increments. Any task larger than a day is on the block to be chopped down to size. It's just another feedback loop I want teams to build into their work. It takes tremendous discipline to keep tasks small. Estimates provide feedback on task size, which empowers the team to take appropriate action when things get out of whack.
Now that you have tasks estimated in half-day/day sizes, simply burn down the total number of half-day increments: a half-day task counts 1, a full-day task counts 2. Add them up, plot a point, and you're done! And don't worry about precision. Half-day and day gradations are plenty good enough. Breaking tasks down further than this level of granularity is an exercise in false precision and begins to engage optimism bias. Think about it this way: over the course of a year and thousands of tasks, the estimates normalize around the median, which is all one can ask of an estimate.
Half-day/day task sizes also foster meaningful conversation and collaboration in the Daily Scrum (stand-up, or whatever you are calling it). Everyone can always talk about at least one task completed since the last meeting if tasks don't exceed one day in duration.
Story Point Burndown
Stories deliver value. We want to know how we're doing on that. So burn down Story Points to reflect and radiate value delivered as the team delivers accepted stories. Enough said.
Team Working Agreements
Finally, team agreements foster team growth and strength. Remember that these are team agreements, not exhortations posted by management! When coaching agile teams, I suggest agreements that I think would be helpful, but no one can force a team to adopt a team working agreement - it must be a consensus team commitment. Here are a few examples:
- We agree to pair-program at least two hours during each day of every Sprint.
- We agree that each of us will work on at least one task per Sprint, either paired or individually, that is outside our area of specialist knowledge.
- We agree that collaboration and collective, consensus-based decisions always produce better results than individual, even expert, opinion.
I hope you've found this a thought-provoking and useful discussion on the merits of simplicity and simple solutions. In our hyper-complex world, we tend to disregard simplicity as being simplistic. Nothing could be further from the truth. When you encounter a complex problem, reflect on the Agile Manifesto Principle that started this post and look for a simple solution!
All for now....
...-.-
