How do you jump into the middle of a tornado and ask the winds to politely stop at a red light? That’s what it feels like when organizations commit to starting throttling work. “There’s so much going on!” “We’ve made promises!” “Everyone is very busy!”
Hopefully, our last post convinced you of the benefits of Throttling Work/Limiting WIP. You may still be wondering how exactly to implement it. The Lean-Agile world brings us 2 great practices and we’ll pull another one from the PMO world.
First, let’s talk about how having too much Work in Progress (WIP) can cause your Agile Transformation to fail. When an organization spins up an Agile team and then proceeds to push them too much work at the same time the Transformation can become a pressure cooker. If too much work is forced on a new team too soon they won’t exercise empowerment. If work is being pushed down from the top, it becomes very difficult for teams not to overcommit. If the team is overcommitting, they have no room to learn and no room to try out process improvements. You end up with teams that hate Agile, and never get past a small initial bump in productivity.
How do you know what level to set your Throttle point? One way is to keep cutting your WIP (work in progress) in half until you see diminishing returns. The second way is to use Little’s Law.
Suppose your situation is 12 month cycle time with 120 projects in process, and you are releasing 10 projects per month.
12 month = 120 projects / 10 projects per month
Your goal is to reduce the cycle time to 3 months. What do you need to do? You are going to need to set your WIP to 30 projects!
3 months = 30 projects / 10 projects per month
Here are some mechanisms to implement throttling:
Portfolio. Let’s start with Portfolio management. Good portfolio management gets the executives aligned on which outcomes they want to invest dollars in. Outcome investment sounds something like this, “I want to invest $2M this year to double our sales in home products.” The “home products team” can go figure out how to make that happen. The portfolio team is not pushing work onto the teams. You may be saying “well the home products team is a portfolio of its own.” Ok fair enough, if the team is working at scale they may have many teams within the group, and require their own portfolio. Let’s say the home products team defines products and features to meet the outcome. They will have to prioritize and sequence this work in the portfolio. The Kanban board is a great mechanism to manage this.
The Kanban Board. The Kanban Board, pictured below, is simply a list of work to be done in the rightmost column. As work progresses, it moves through the columns. This might remind you of a stage-gate process, but it’s very different for a few reasons. a) There is a strict limit on how many items can be in each column. This is the throttle! The throttle forces people to finish what has been started, push past obstacles, get creative, instead of simply moving onto the next item. b) It’s shared, transparent and open source. Anyone can go look at it or update it. With the old stage gate documents, you were waiting for updates to be “published”, the Kanban board is always up to date and alive. Everyone updates their own stuff. How many times have you voiced concern that was ignored? With a big transparent “NO” sign, obstacles cannot be ignored. The “NO” sign on the “Thermal Scan” indicates that the item is critically blocked. This psychologically prompts everyone to participate in helping unblock the item. c) It’s a discussion board. The Kanban board is designed to drive discussions about priorities, obstacles, and dependencies. It’s not a “presentation”.
Backlog. The Backlog is really a simple list. A list without columns, just a list. How can something so simple be so powerful? Like with the Kanban board, the Backlog is transparent and shared. The team aligns with the priority of the backlog, and only works on a fixed number of items at a time (or enough to fill a sprint).
The Backlog really shines when new work comes in. A new super-important item comes in from a super-important executive. Without a backlog, the team might just drop what they are doing and work on it. But what work is being impacted? Do we need to go perform an impact analysis? With a backlog, the team points the executive to the backlog and says “Here’s our priority list, where does this new item fit?” Ahhhh, I get chills just thinking about how effective those discussions can be.
How have you throttled work? We’d love to hear from you in the comments!
コメント