In a volatile world, how do we maintain focus?
One challenge to any organization scaling out of start-up is the level of “informal” work and how we move to ensuring that work aligns with business value.
One version of the truth
Each developer may be receiving many independent requests from different sources.
Often people have learned that the way to get work done is to find an individual engineer and ask them to do the work. In small organizations this becomes a core skill. Many people are successful due to knowing the right people and how to influence them by persuasion or threats.
Many organizations will find that there is an information gap between what people believe is being done, and what is actually being done. There is a strategy for what we wish to create. There should be a roadmap of prioritised value items. But that strategy may be more an intent than a reality.
Communication of the strategy beyond its creators may be very limited. To the teams working on the product, that strategy is not always clear. It may even be wholly invisible because it is never communicated with the team. To maximise value, we must align the work of each team and individual to the value stream and to the strategy.
The first step is to ensure that everyone has the same understanding of what the plans are. This means that the value streams, the planning and the prioritization must be visible to all. There must be “one version of the truth”.
This ties into several of our other Plays. Being focussed on the plan needs us to be ruthless about backlog refinement. Backlog is our “one version of the truth”. Which means that it must be the only record used by everyone. It must contain all of the work. The teams must use this as their reference.
Startup to repeatable delivery
It sounds easy, almost trivial. Implement a list of work and then use that list to move through the work.
However, this is a cultural shift. In a start-up environment, people get things done by talking to the right people. Teams are rewarded for jumping on the latest problem. Informal approaches are used to deal with a fast moving environment. Response speed is more important than consistency.
These informal approaches reduce focus and increase parallelism. As the organization scales, it needs to build more rigour. Increased Work in Progress becomes a problem. Unmanaged Technical Debt can build from poorly planned work.
Work needs to be clearly delegated to teams. Teams need autonomy and focus to get that work done.
An important first step is to ensure that we have prioritised the work and created an ordered backlog. This will allow us to see what is currently defined as important.
Focussing
Just writing the work down in order is not enough. Delivery of business value requires that the prioritisation is used when the work is being completed. We need to make sure the strategy feeds through the organisation to the implementation and ensure that people are not working on other items. Every item which is not at (or near) the top of the list but is still being worked on will divert energy from the value stream items which would most benefit the business.
We can view a development group as an engine to deliver business value. A high powered engine cannot function alone. It needs steering to head in the right direction. We need to ensure that people are working on the items of high value. That requires us to prioritise the work. It also needs us to be clear and open to the teams about those priorities. Our engine also needs wheels to make progress. We need to ensure that the team are delivering that value. That means ensuring that work is not just started but completed and delivered.
A key measure here is Work in Progress. If teams work as individuals, picking and choosing items and working independently on them, progress will be slow. A highly tuned team will focus on a piece of work to complete it and deliver it. Everyone in the team knows what the most important work is. And everyone is contributing to making that happen.
Teams can lose that focus. Instead they are working on multiple features in parallel. This may seem harmless. There is a tendency to think that all work is good work and that being busy is sufficient. But parallelism and unfocussed work can be expensive.
Of course this isn’t a call to focus only on customer facing features. The backlog contains defect fixes and spikes and technical debt reduction items for good reason. However, when a developer starts a piece of work they should know why they are doing it and be confident that it is delivering the best value.
Good practices
As an Agile leader you will need to ensure that there is a clear backlog available for each team. Critically you need to be sure that everyone in the organisation has the same view of priorities. They don’t all need to see the detail, but we can use Features to summarise the data.
All work needs to be included in the backlog, and work is taken from the backlog using Sprint Planning. Of course there may be a need for escalation and critical defect processes, but there should be no “backdoors” to individual developers.
There are two key metrics mentioned here, which you can introduce as part of your corporate language. You need to assess how smoothly the work flows using FlowMetrics, especially what level of Work in Progress each team has.
You also need to understand ValueMetrics, especially how much time each team is spending on advancing the strategic roadmap. We do not measure this because we want to unrealistically push the team to create more features. But you need to know that the balance of features, defects, technical debt reduction etc. is realistic and sustainable.
Leave a Reply