Hindsight is always 20/20, but it was clear something wasn’t right.  For months, a small ‘specialist’ team spent many hours a day, for weeks/months, architecting, designing, thinking, debating, and controlling the scope of work.  To the point that only a trickle of information ever escaped to the larger community, and that info that did escape was simply to provide something for them to work on.  The goal was to create ‘The Backlog’ for all to consume.

Agile Principles?

Many of the decisions that led to this approach and actions were not decisions that went through the lens of lean/agile principles.   #2 Welcome changing requirements,  #4 Business and Dev must work together, #6 Face-to-Face is most effective, #10 Simplicity – the art of maximizing the amount of work not done,  #11 The best architectures, requirements, and design emerge from self organizing teams, etc.

Visibility?

So, when this backlog and vision actually got in front of some of the senior leadership, they questioned why we were turning back towards the legacy solution instead of the chartered ‘Next Gen’ type of architecture?  For the elite team defining the backlog it was clear.  In order to hit the date, we have to rely on what we know which is the legacy approach.  But this was not the longer term vision of the program.  A classic case of not optimizing the whole, but local architectural optimization.

Uh Oh – Tech Stories

OK – but we are ‘agile’, all we have to do is take a more modern design approach to achieve the value identified in the backlog.  Not so fast… turns out the backlog items are not user value focused, but technical implementation focused.  The backlog has to be re-done.  Let’s pause for another month so the special backlog team can rebuild the backlog to account for the new approach.

Red flags should be flying high.

The backlog should reflect the features, stories, value items that represent the functional aspects of the solution.  Think about it, the Customer just wants certain capabilities to work.  They want to do their job.  How the solution manifests to enable this capability is not too much of their concern.  So the core backlog should have been stable and remained unchanged.  The technical approach and details should live in the technical design and architecture documentation/wiki.  Sure, there are technical stories or ‘Enablers’ that will need revisiting.  But probably not at the cost of a month delay.

Don’t let it happen on your project.

Help that backlog escape from the backroom where only a few are in control and get more eyes looking at it.  Consider Story Mapping!  We don’t have to create a giant ‘backlog’ committee and fear that we will never get consensus.  Create workshops that can collaborate and work together to reflect the story of the end user on the story map wall.  You can even include technical enabler type stories on the wall showing how customer features are dependent on certain technical capabilities.