If a problem comes along, you must WIP it!

I say WIP it, WIP it good!

WIP it!

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 knows 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 would 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 set. 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 this was that their cumulative flow showed a large number of stories in progress.  So we played a game with them, the game was getKanban.  The 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 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.

Screenshot 2015-07-17 22.56.29

If you look at the trajectory at the beginning of this chart you will see that is unlikely that the team would have completed the work based on how the graph is trending at the beginning of the iteration, especially taking in to consideration that there was 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.

The concept of doing less work is sometimes hard for people to grasp, particularly since when we work in an industry that rewards 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, ready for production, because they had multiple people working on a limited amount of work.  The work produced was faster, better quality and now had a wider pool to pull from that had knowledge of that work. Who wouldn’t want to get value through the pipe quicker and start earning a return sooner?

This team is comprised of talented individuals with a wide variety of skill sets, personalities and background.  While playing getKanban they all felt how limiting it was to have people on their team that were restricted to just one function. They felt frustration with too much work happening at the same time.

What did the team do?  They swarmed,  paired, they started using and acting on those words, they enforced those practices, they had team members evangelizing this practice, they internalized their blocks rather than blaming others for them.  They also united as a team because they had overcome their obstacles and were making tangible progress.

The team also realized the advantage of having multiple eyes on code which increased their code quality and knowledge base, growing the pool of people that could provide on call support.  More eyes on code meant they were all accountable for what gets pushed to production and they were also all familiar with it. I have seen the benefits of this as they planned for their next sprint; they planned stories with the intent of making sure that all team members learn, not just leaving certain types of work to people who are comfortable in that particular domain.

One comment 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 saying 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 that do the work, keeping it focused and relevant.  Product Owners, you have a responsibility here: Do not 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 is not something that we have been actively pushing (just a pleasant side effect) but it concerned the team that cards were “stale.”  Stale can mean the work items are obsolete, and introduces 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
  • Pairing

All of these items are consistent with practices and benefits of limiting WIP. The team voted on items and agreed that they wanted to keep focused on this practice and further defined that they wanted to put a firm limit on WIP.  They committed to a WIP limit of 3.  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 hits a block 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 that 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.  They are responsible for their destiny.

To date, they have earned the most amount of money playing getKanban than any other team. They are committed to continuous improvement and they will continue to deliver.

It’s not too late, to WIP it.

Why fight it?


Around the time I became involved with Agile I also became completely addicted to World Of Warcraft.   I started to realize that Agile methodologies are what people will naturally turn to (in the absence of dictated process) when working as a team with a common objective, without even knowing there is a movement out there trying to define what it is and to make money from it.

This may seem a little over the top to some agile practitioners that believe they have the “secret sauce” that will help those less unenlightened see the way, but being agile is what many people would call common sense.

A raid is a series of bosses that you must kill in order to complete the raid. Think of a raid as an iteration or sprint, each boss is time boxed because the boss will go in to “Beserk” mode that will instantly kill everyone.

Here is what I have observed.


The Beginning of the Raid (forming)

This can be looking for raid or a guild group, I have participated in both and see the same dynamic. People get together with the best of intentions and everyone goes “gung ho” to kill the first boss.  Often everyone dies, failing fast.  You often see stronger more experienced players step to lead and guide the team at this time.

Trash Talk and Blame Game (storming)

Once everyone is resurrected from their epic failure of not killing the first and easiest boss we get the people that blame rather than be constructive.  In the storming phase of an agile team this is often seen most prominently in Retrospectives where some team members are passive-aggressive, will complain but have nothing to suggest to change, . Generally those individuals get kicked from group which is a critical step in both gaming and software development.  One person can destroy a team,  if coaching, support or guidance have no positive impact on their behavior it is time to part ways.  Those committed to success start to move in the next phase….

Before moving on I also want to note that metrics are used.  Poor performers that are not doing enough damage, healing, mitigation or holding “aggro” of the boss if they are a tank can  be kicked from the group.  There are tools that most players use to monitor these on their screen. However there is also a human element.  If a raid member is providing value outside of the traditional Tank, DPS (damage), Heals they will not be kicked.   But if you have a trash talking DPS that is nerd-raging, kick ’em!


We can do this! Collaborating (norming)

Talk, communicate, share, coach, encourage, support, just to name a few.  This is where the raid group starts to provide feedback to others to help them succeed, where that feedback is received and acted on.  We will start to see planning  and estimation sessions of the team be conducted as if they were of one mind. They are in sync with each other and have a common understanding.  Some key elements here are:

  • The team is a aware of strength and weaknesses of each other and can accommodate.
  • The team is familiar with the objective due to previous failure and are better equipped to face the challenges.  They have learned through some failures.
  • They have developed trust in their raid group members ability to perform.


We Rock! (performing)

The raid has now come together.  They are constantly communicating and remember lessons learned from previous attempts at the same objective to kill the next boss.  They have learned and improved from their collective experience in conquering this boss.

At any time when the team makeup is changed, the whole team can go back to forming. The speed with which they can cycle through these phases  significantly less when you have “mostly” unified group but there is still a setback.