Now that you are completely distracted with the Herculean effort it will take to get that song out of your head, let’s talk about Work in Progress, also known as WIP. Just the term alone can be misleading – after all, on the surface it seems like the more work we have in progress, the more work we should be getting done. So, in terms of Agile software development, why does WIP matter? Why do we want to limit work in progress?
Once upon a time there was a team that appeared disjointed in their focus and skill sets. They were working on many disparate items and did not appear united in their goals. They were functioning, but they could be better. One of the indications of their need to improve was their cumulative flow showed a large number of stories in progress. So we played a game with them—GetKanban. This game simulates software development work using Kanban mechanics and processes. There are many reasons to encourage a team to play GetKanban. Our focus for this particular team was to show them that swarming a few stories was more efficient, effective and productive than distributing a lot of work across the team. We played GetKanban at the beginning of their iteration. The metrics in the cumulative flow diagram below are telling. A cumulative flow diagram is a tool used in queuing theory. It is an area graph that depicts the quantity of work in a given state, showing arrivals, time in queue, quantity in queue, and departure. In this chart the blue/grey section represents work that is complete, the yellow represents work in progress and the red is work that has been committed to and ready to work.
Looking at the trajectory at the beginning of this chart, you can see how unlikely the team is to complete the work. This assumption is based on the graph trends at the beginning of the iteration and the additional work added (indicated by the upswing in the red section) early in the sprint. The team actually reduced their focus at the same time additional work was added; this is shown by the yellow section (representing work in progress) narrowing and the red section expanding.
Oftentimes, the concept of doing less work is difficult for people to grasp, particularly when we work in an industry rewarding those that do the most work. Through playing a game of GetKanban, the team saw that while at any given moment they were focusing on less work, they were also getting more work to final completion and ready for production. This up-tick in completed tasks is attributed to multiple people working on a limited amount of work. Work was not only produced faster, but it was produced with a higher level of quality. This was due to the freeing up of a wider talent pool to pull from with specific knowledge of the processes needed to complete the work. Who wouldn’t want to get value through the pipeline quicker and start earning a return sooner?
Furthermore, like any productive team, this one is comprised of talented individuals with a wide variety of skill sets, personalities and background. While playing GetKanban, each team member felt the limiting impacts of having people on their team who were restricted to just one function in addition to feeling the frustration with too much work happening at the same time.
So, what did the team do? They swarmed and paired. They started using and acting on those words, enforced those practices, encouraged team members to start evangelizing this practice, and the team internalized their blockers rather than blaming others for them. The collaborative group also become more united because they had overcome their obstacles and were making tangible progress together.
The team also realized the advantage of having multiple eyes on code, which increased their code quality and knowledge base while growing the pool of people who could provide on-call support. More eyes on code meant more people were accountable for what gets pushed to production and the whole team was familiar with the code being pushed. I saw the benefits of this as they planned for their next sprint; they planned stories with the intent of making sure that all team members would learn, instead of just leaving certain types of work to the people who are comfortable in that particular domain.
One comment that was made while we were playing the game that stuck out for me was, “There are too many cards in flight on the board.” The follow-on discussion led to team members expressing that they felt it was too hard to make a decision with all those cards; there was too much noise. The conclusion was to reduce the noise for the people doing the work, thereby keeping the task focused and relevant.
Product Owners, you have a responsibility here:
Don't clutter the team’s working board with features that are distant wishes. The team also started caring about how long the work was in progress from start to finish, or “cycle time.” This isn't something we've been actively pushing, (it's just a pleasant side effect) but it concerned the team that cards were “stale.” Stale can mean the work items are obsolete, potentially introducing the risk that the team is working on something that is no longer a priority. Product Owners need to step in here to evaluate the priority of the work and provide direction.
At the end of this iteration we of course had a retrospective. We went with Start/Stop/Keep.
This is what individuals came up with for “Keep”
- WIP low
- WIP should stay small
- Swarming stories
All of these items are consistent with practices and benefits of limiting WIP. The team voted on items and agreed they wanted to keep focused on this practice. They went on to decide they wanted to put a firm limit on WIP. The team committed to a WIP limit of three because they understood the value!
Summary of why WIP matters:
- Encourages pair programming, code quality, knowledge share, team collaboration and accountability.
- Reduces context/task switching.
- Cycle time is reduced due the team swarming on a few stories together rather than taking on many separately.
- If the team encounters a blocker they will not just pull in another story (assuming they have agreed to a pre-defined WIP limit); they will swarm the blocker instead.
While we know our processes are still evolving, the progress made by understanding WIP is tremendous. The team is working on identifying the skills and access needed to be on-call support and developing a strategy around getting their team to a workable solution. After all, they are responsible for their results.
To date, they have earned the most amount of money playing GetKanban than any other team. They are committed to continuous improvement and will continue to deliver.
It’s not too late, to WIP it.