Standardising is Standing in the Way

Increasingly there seems to be a shift to try and standardise Agile, tools and processes that teams use to deliver all in an aim to try and have a consistent level of delivery. Let’s face it, no two projects are the same and no two teams are the same, so immediately you have a potential conflict. And instead of being more agile or nimble, teams are pulled under by process and locked into systems and tools that slow them down.

So why do organisations do this? Well in most cases they believe that by standardising this will remove uncertainty and give teams a tried and tested model to deliver to every time. Also, organisations struggle with reporting and believe that by controlling how teams run, they can measure each team the same way.

One example of locking down that seems innocent enough is forcing teams to work from a standard workflow. One of the main value propositions of Scrum and especially Kanban is the ability to visualise the work on a card wall. This allows teams and key stakeholders to easily see where all the work is and at what state the work is in (workflow). By locking down the flow to have a limited number of status’s the teams are not properly showing the work and bottlenecks and issues with process or people are hidden.

The below demonstrates the point:

These three statuses in the work-flow appear to show normal activity with 6 items in the backlog, 9 In Progress and two done. The team appear to be very busy and the project looks healthy.

This is the same project with five status’s. What is interesting to note is the Development team appear to have almost no work going, which could be cause for concern. Next there is a bottleneck in the Verified column, this can be a sign that the Product Owner is not available to sign off on completed items.

So what happens if we expand this further to give even more visibility?

So, we can see that the next Sprint 2 is not ready, there are only 2 items, this could be a symptom of lack of planning or it could be that the Product Backlog is not prioritised, and refined ready for planning, which is just as important to visualise as the current Sprint.

A simple act of allowing this team to customise their work-flow has put power back into their hands to quickly visualise the project with it’s true workflow, but also it allows them to quickly see problems and call them out creating a continuous improvement mechanism. And with WIP limits in each status, you can better control and manage a more sustainable pace for the team.

So what needs to change? Well organisations need to stop locking down tools and process and allow teams to be properly self-managed. Organisations need to have the maturity to first trust their people, but next let the teams provide the info management needs in the format that is easy and natural for that team and preferably in a way that management and the organisation can pull the info direct from the team’s card wall without any involvement from the team. The tool features need to be opened up, not restricted. This is like having a box of tools, locking it and only letting a person use the hammer for everything.