Organizations that are scaling up with scrum often find that Everyone Is Busy But Delivery Is Slow. This syndrome is usually caused by a lack of visibility into what people are working on, poor prioritization, and too much work in progress. The more work in progress we have, the more overhead we incur. We have meetings about the work. We create and read dashboards, reports, emails, and chat messages about about the work. People are doing all this work in order to achieve goals. Where are the goals coming from? Which ones are most important? Getting control of work in progress requires effective management of the goals.
Effective Goal Management
Scrum has an elegant solution for this problem of goal management: the sprint backlog and the product backlog. These backlogs are open and transparent artifacts – everyone involved can easily inspect them to know what is being worked on now, and what will be worked on next.
The sprint backlog describes the limited set of goals that the team is currently working on. The goals in the sprint backlog are expected to be completed by the end of the current sprint. The team focuses their work on accomplishing these goals.
The product backlog is the single ordered list of future goals for the scrum team. The product backlog supports medium and long-term planning. The product backlog is constantly evolving. New requests for work (goals) go to the team’s product owner, and then into the product backlog. Occasionally, emergencies come up and can be managed using The Emergency Protocol.
Poor Goal Management – A Case Study
When requests for work bypass the product owner and product backlog, things get out of hand pretty quickly. Evil Empire Soft was a typical command and control organization. Executives set strategy, directors broke the strategy into smaller goals and assigned those goals to middle managers. Middle managers broke their goals down and assigned them to lower level managers and so on, until line managers assigned tasks to workers.
The classic approach works well when the goals don’t change and the work is clear, or merely complicated. This approach isn’t so great for complex work, such as software product development. In the complex domain, goals shift as new information emerges. Unexpected dependencies and impediments arise and the solutions require coordinated adaptation across multiple groups.
To address the challenges of working in the complex domain, Evil Empire Soft adopted scrum. They sent people to training and started to form teams. In their workshops, they learned that things get done faster when teams have fully dedicated team members and no individual is on more than one team. It is more efficient to move work to teams, than to move people to work.
But old habits die hard. When the leaders at Evil Empire Soft saw that they didn’t have enough teams to address all of their goals, they decided to double the number of teams by assigning each person to two teams. Like magic, they had enough teams! Of course, this did not increase the organization’s capacity to do work. It did add overhead by doubling the number of scrum meetings. Everyone got busier, and delivery got slower.
When Evil Empire Soft created scrum teams, they didn’t stop assigning goals to managers. This created a dysfunctional hybrid situation where people work on goals from their teams’ backlogs as well as goals from their managers. Everyone got busier, and delivery got slower.
The response time for high-priority bugs got longer and longer. The customer support department was overwhelmed and demanded that something be done. A priority queue for bugs was created, and a regular “bug scrub” meeting was scheduled. At the bug scrub, defects and support issues are reviewed, prioritized, and assigned to developers. This created an additional source of requests raining down on the people doing the work. Everyone got busier, and delivery got slower.
Because of time pressure, developers resorted to taking short-cuts in their work. This quick-and-dirty approach to getting things done created technical debt. The debt led to lower quality and slower delivery. Eventually, technical leaders recognized the problem and created a special queue of technical debt work. They setup a regular meeting to refine, prioritize, and assign technical debt issues to developers. Yet another source of work. Everyone got busier, and delivery got slower.
Besides these formal channels, there are requests flowing through unofficial back channels as well. For example, an influential salesperson will go directly to a favorite developer and ask them to implement something right away. Pet projects get worked on under the radar. The slower the system is going, the more people subvert the system. This makes people even busier and delivery even slower.
The leaders see that things are going too slow and so they want to hire more people to increase capacity. But the problem isn’t how much they’re doing; the problem is how little they are getting done. These are different issues, with different solutions. Throwing more people at an out of control system leads to more chaos and very little increase in delivery.
I assure you I didn’t write this case study based on any one company. It’s a pattern that shows up frequently as organizations start scaling up with scrum. If the situation at Evil Empire Soft feels familiar, congratulations: recognizing the problem is the first step in fixing it.
Further Reading
Source link