The Complexity Trap, Part 1

I presented this topic at Mile High Agile 2012 under the title: Great Teams Keep It Simple.

“Simplicity–the art of maximizing the amount of work not done–is essential.”

– Agile Manifesto Principles

Agile teams and leaders tend to think of this principle in terms of reducing the complexity of the product being developed, from UI/UX flows to the back-end code. There is another area in which it is vital to focus on simplicity, however: the way we use various agile artifacts. Areas of complexity include:

• Backlogs
• Task boards
• Burndowns
• Individual “Velocities”
• Utilization tracking/measurement

Backlogs
The most obvious way backlogs become complex is when they contain too many detailed stories. I have seen backlogs that contained thousands and tens-of-thousands of stories. Such backlogs are unworkable, unmanageable, and wasteful.

Another, less obvious but more insidious way backlogs become complex is when they are sliced along functional layers, rather than across those layers. Like a cake made of wood, stories written within functional layers make the Product Backlog rigid and impenetrable. Functionally layered backlogs are rife with irreconcilable dependencies and integration nightmares.

Task Boards
Task boards generally become complex in two dimensions: work states and team assignment. In the former case, the task board develops many columns, each depicting an intermediate state of doneness for tasks or even stories. In the latter case, the task board gets cut into sections, one for each team member, with tasks and even stories falling into individual team-member domains, often during Sprint Planning. In extreme cases, I've seen both of these dimensions of complexity expressed on the same task board.












The usual result of complex task boards is unfinished work at the end of the Sprint, as depicted below:











Sprint Burndowns
The Sprint Burndown is an element of transparency, showing the inner workings of the Sprint for all the world to see - and for the team to use as an input to daily decisions. Sprint Burndowns also frequently become so complex that they are essentially unreadable, as in the example that follows, which tracks, among other things, actual hours expended, an inherently damaging metric.













Tracking Individual Velocities
One of the most insidious artifacts I've seen in use is the tracking of individual "velocities" within a team, the implication being that stories are written in such a way that only one person works on any given story. The damage this type of metric inflicts on a team is incredible and often difficult or even impossible to repair.











Symptoms of Complexity
Some of the symptoms of complex work structures, as indicated by complex artifacts include:

• People with nothing to do the last couple of days of each Sprint – usually “developers”
• People with nothing to do until the last couple of days of each Sprint – usually “testers”
• Gold-plated code
• Poor quality code
• Unfinished work most Sprints
• “We’ll test later”
• Internal team stovepipes that require hand offs
• Morale and motivation problems
• Lack of Teamwork

Complexity in agile artifacts creeps in, uninvited or intentionally, for a variety of reasons.

• Lack of team cross-functionality
• Lack of a dedicated team – resource pooling and matrixing people across teams
  
• Artifacts of thinking – habit
• Fear
• Lack of trust, both within the team and between the team and the broader organization
  

I often find that complexity results from teams' and organizations' attempts to find ways to adapt agile to their existing project management and organizational assumptions. Agile is all about changing the way people and organizations work, to move beyond organizational structures and assumptions that arose to serve a different purpose and way of working. Clinging those structures and assumptions, long after they have ceased to be effective, is a major impediment to improvement at every level, from individual teams to the organization as a whole.

Next time, let's look at the opposite of complexity - simplicity - and apply the Agile Manifesto principle that started us off in practice.

All for now....

...-.-