The three “D”s of disconnected work

Throughout these plays we continually come back to the idea of a single, well understood source of prioritised work, conceptually an ordered backlog maanged through backlog refinement.

Physical cards

Historically teams have managed work by using a physical display.  A Kanban Board would consist of a card for each work item and these are fixed to a wall.  As with many people who have worked with such systems, I admit to some level of nostalgia for this approach.  It can be a very effective way to build team involvement to have everyone standing with the physical cards. 

However the organization aims to scale and physical cards do not scale well, even with good glue.  In the current development world, teams are less likely to be co-located.  With even a minimum level of remote working, a work management system needs to be online.  It needs to be a shared system which is accessible to all.

Work Management data

Each work item needs to have a unique identifier.  Without this, there is constant potential for confusion. 

“The feature about adding a button” is not enough to discuss work reliably. Without a unique identifier, people refer to the same work with different names, and different work with the same name. 

Every team works from an ordered backlog.  Therefore we need to link each work item to a team backlog.  This needs to include a way to order the backlog.  A numerical field is not enough.  Ordinals allow multiple items to have the same rank.  We need to ensure the whole backlog is placed in order.

We need to know the exact status of each item.  As a minimum, this needs three states. 

• Yet to start and awaiting any work. 
• Currently in progress and assigned to a Sprint. 
• Completed to the quality level of the Definition of Done. 

We can only track the work if we track each item through these stages.  Organizations may choose to use more stages, but these are the minimum.

Finally every item should have an estimate.  This allows us to keep track of how much work we have in the backlog.  We can then start planning with Velocity to think about what may be possible in a timebox.

Work management requirements

For the team to self-manage, they must be able to see all of their planned work in one place.  For Agile development, this means that the team (not just an individual) must be able to see the full backlog as an ordered list.  This visibility is going to be critical for ongoing backlog refinement. Backlog refinement operates on the whole backlog, reordering, splitting and adding backlog items. 

The team also need to be able to see all of their current work.  If we are working in iterations, current work relates to the Sprint Backlog.  This is the work agreed to be done in the current Sprint, which represents the short-term plan.

Agile Boards (sometimes called “Kanban boards”) are a popular and effective tool for visualising current work.  They represent the state of the items which are currently being worked on by the team (the Sprint Backlog) in a visual form.  The “board” format with columns to represent issue status has proved a widely-used and accessible concept. It is not a requirement, but it is an effective tool.

Work management and reporting

The work management system helps us to keep track of the high level of development detail.  This empowers the team by giving them access and visibility of all the work. As we have seen we need a single source of truth of this data.

• Priorities of future work are clear. 
• Status of current work is visible. 
• Completion of work to quality standards is well managed. 

Many organizations largely stop at this point.  They see a work management system only as a repository for individual work items used by individual engineers.  However, we would be missing an opportunity. The system becomes much more valuable as its use increases. 

There is an opportunity to join up the organization.  We can ensure that the live data which is created and managed by the developers is used in reporting across the organization. This gives us a true “one version of the truth”.

Disconnected flow of value

A separate Play looks at value streams and the way the work flows through the organization.  In particular we define a “value stream item” or Feature which tracks the flow of value through the organization.  Too often the reporting around backlog work items and value stream items are separated.  Ideally we should integrate the two.

In most organizations the work data is held within the development group.  However the value stream data is managed by the Product team.  Reports about Features and roadmap are generated from this separate data and delivered to senior management. Status report generation is generally a manual process.  An engineering manager reviews the data in the work management system.  They then transfer this and summarise the data at a Feature level to report on the value stream. 

This disconnect generates three forms of failure – “the three Ds”

Delay

Introducing manual steps into reporting always adds a level of delay.  The data no longer flows live.  The report reader will have access only to the latest version of the report.  This will based on data generated at a previous point.  It could be a week since it was circulated.  It would have been collected prior to that.  Depending on the processes involved, manual reporting could mean that senior management is looking at data weeks out of date.

Detail

Every level of manual reporting removes a degree of detail from the data.  The loss of detail is why lowest viable level decision making is preferred to escalation. 

Abstraction is necessary, even desirable, in reporting to people increasingly far from the immediate problem.  However, manually removing data can introduce subjective bias.  What we choose to remove is no longer accessible to the report readers.  Removing detail in manual reports can also introduce errors which can persist and be copied from report to report.

Denial

There is a fine line between explaining the data and biasing the data.  The intermediate management level often has an interest in promoting data which presents themselves in a favourable light. 

Frequently a team or manager might commit to delivering a feature.  They are perhaps confident that it will deliver.  This means they downplay any issues, hoping that these will be resolved.  Underlying problems are hidden until the problems become so clear they cannot be denied.  This leads to very late feedback on issues.

Fear invites wrong figures. Bearers of bad news fare badly. To keep his job, anyone may present to his boss only good news.

“The New Economics” – W.E. Deming

Joining up work management

Every task the team complete, every backlog refinement they perform, should be linked to and part of the value streams tracked by the organization.  Too often these two are separated – the teams execute tasks, but managers plan and report roadmaps.  This replicates the worker/manager separation of Scientific Management. We cannot have empowered teams unless the team input is directly involved in the value stream reports.

What should we be aiming for as an alternative to this disjoint system?  The best answer is that the backlog data flows into the value stream data and into corporate reporting.  This is not trivial to implement but building this into the approach early will pay dividends. 

Joined up data through the organization is a key part of empowering self-managing teams

Good practices

As a leader you need to ensure that everyone has the same picture of the status and priority of work. This applies both across backlogs and value streams.

You need to make sure that the work that the team does and the information they hold flows seamlessly into reports. This means we should not be manually reporting feature data separately from team work.

We should instead integrate all of the backlog work which relates to the feature and use that data.  When a team completes a piece of work relating to that feature, it should feed through to the value stream without manual intervention.  When the team adds more work or re-estimates work in backlog refinement, it should directly integrate into the roadmaps and value stream timeline. 

Integration of team data empowers the team and puts them at the heart of the information flow.