Stop Starting, Start Finishing!
Is your team working on four, five or even six or more projects at the same time? If so, you’re not alone. And it’s no surprise why it takes five or six times as long to deliver value in this scenario.
Over and over again, at small companies and huge corporations, one of the biggest roadblocks to successful Agile outcomes is overloading teams with too much concurrent work - or failing to Limit WIP (work in process). At one client I worked with (the IT department for a global company) we heard from teams that they were all working on five or more projects, so we took an inventory of all the concurrent projects. The company’s executives were shocked to learn that the IT department of about 40 people was attempting to run 80 projects at the same time. They had no idea the number was this large, and they could clearly see that it wasn’t reasonable.
The solution: Prioritize or sequence the projects, and implement an organizational WIP limit.
The mantra and mindset: “Stop starting, start finishing.”
Two of the fundamental Lean principles are (1) limiting work-in-process (WIP) and (2) implementing a pull system for starting new work. If you want to deliver value faster, this is the key. And what organization doesn’t want to deliver faster???
So here is how we solved the problem.
The executive team meets together quarterly to consider all the requested projects (initiatives, or Epics, if you prefer those terms).
The leadership team reaches a consensus on the priority (or sequence, if you prefer) for the requested projects. The decision is communicated transparently across the whole organization.
The delivery teams establish a collective Project WIP Limit. This limit is usually close to the number of Scrum-sized teams in the organization. If you have 8 teams, the project WIP limit should be around 8-10 concurrent projects.
Teams pull projects from the prioritized/sequenced list, only until the WIP limit is reached.
When a team finishes a project, they now have capacity to start the next project from the prioritized list, thus respecting the WIP limit.
In the scenario described above, the organization determined that a reasonable Project WIP limit was 10 concurrent projects — quite a bit fewer than the 80 they were attempting before! The executive team identified the top 10 — after considerable haggling and debate, using the Business Value Game (think: Planning Poker using value points instead of size points).
The outcome: The company’s business stakeholders no longer viewed IT as “too slow” and a bottleneck for the company. Instead, IT started delivering solutions faster than the business stakeholders were capable of consuming them. The bottleneck shifted to other parts of the company.
Powerful question of the week: “If you had to say ‘no’ just one request, which one should it be?”