Guerrilla Kanban

After speaking to a few local Kanban practitioners (and aspiring practitioners), I thought it would be helpful to demonstrate how you can use Kanban to improve your software development process in small, incremental ways.  So much of what we learn about Kanban and Lean software online are implementations in relatively open and conducive work environments.  Or at least they are implemented by people with the authority or influence to make the change.  We see photos of large, gorgeous Kanban boards and we read about profound accounts of successful Kanban projects.

If you work in a corporate structure that seems too dysfunctional or too rigid to adopt agile processes, you may feel helpless in your current role to affect change.  Maybe you work on a small team in a command-and-control environment.  Maybe you work as a single developer in your own project silo with more work assigned every week than you have the capacity to complete.

This blog post is to challenge your assumptions about your ability to affect change, and hopefully give you the tools you need introduce positive change in your organization.

Background
Project X is currently in production, but has some significant challenges. It has suffered from the lack of developer availability since it went live.  Bugs were discovered in production and often there were no developers available to fix them.  This later caused the product owner and users to overload development staff when they were available for support work.  The code was originally developed in project silos, with no automated test support.  The code base is only 2 years old, but is effectively a legacy code base.

Making Improvements
David Anderson, a leader in the Kanban community, has recently talked about Kanban as a “change management” system.  Since Kanban has a low barrier to entry compared to other popular Agile methods, your goal should not be to make grand, sweeping changes in your environment.  Allow Kanban to show you and the other stakeholders where you need to make changes.

Mechanics of Kanban
Your immediate goal is to visualize the value stream.  This can be on a white board, but any wall with appropriate fasteners will do.  The value stream for Project X (bug fixing) is:

Needs Prioritized –> Prioritized –> Dev –> Ready for Test –> User Testing –> User Accepted –> Released

Represent the value stream on your board and track every work item (figure 1).

Figure 1. 


Next, start limiting work in progress where possible.  At the time of the board photo, there was one developer fixing bugs, so the WIP limit for development is 1 (yellow highlight).  Notice the two large batches of bug tickets at either end of the board.  We'll explore what that means a bit later in the post.

As soon as you can track work items on a board, keep an electronic copy in a spreadsheet or tool of your choice.  The critical piece of data to track is the actual cycle time per work item (figure 2).  You will notice this sheet shows "Dev Cycle Time".  Since the code base doesn't have automated tests, large numbers of code changes are typically batched up for user acceptance testing and manual regression testing.  Given the technical and testing limitations, the project has very little end-to-end flow.  So, to help with project planning in the near term, development cycle time becomes more useful.  It allows the product owner to plan when a full regression test and subsequent release can occur.  In Lean terms, this is not ideal, but in the context of Project X, there is value in measuring a subset of the full cycle time.

Figure 2.


Once your work items are captured, and cycle times are recorded, you will need to capture that data on a regular basis.  For most projects, a daily project "position" is adequate.  At the end of each day, record the total number of work items in each state (figure 3).  Unless you have a very busy Kanban board, this should only take a few minutes each day.

Figure 3.
 

This historical data can be used to generate a simple Kanban dashboard in excel (figure 4).  At a minimum you should include information to answer two basic and related questions: how fast are we going, and when will we be done?

Once again, in the short term, Project X is primarily concerned with calculating cycle and lead time values for the development stage.  

1. Average cycle time is easy:  (sum of cycle times  / count of cycle times).
2. Lead time measures the backlog and average cycle time:  (backlog count * average cycle time).

For Project X, this simple dashboard is posted beside the Kanban board (figure 1 red highlight) and emailed to stakeholders every week. 

Figure 4.


The Goal
We have two immediate goals with our Guerrilla Kanban implementation: 

1. Generate useful metrics to assist with immediate project planning needs.
2. Provide visibility to make observations and improvements to the process over the short and long term. 

For Project X, providing metrics around development effort helped the product owner make more informed decisions about release cycles and project coordination with other systems in the portfolio.  Questions about developer estimates diminished quickly, and were ultimately replaced completely by cycle and lead time metrics.  A byproduct of this change was a significant increase in trust from the customer.

The Kanban board (figure 1) and cumulative flow diagram (figure 4) both serve as conversation starters with project stakeholders.  The only “good” aspect of the cumulative flow is the thin yellow ribbon of development work.  The WIP limits for dev work are effectively enforced.  The rest of the diagram exposes a large backlog and high counts in the testing states.  Work is batched up before and after development work.  Even though items are moving through development at a steady pace, there is very little flow of value since bug fixes are only tested and released to production in large, infrequent batches.

To further make the point, we could contrast the average development cycle time (2-3 days) with the average end-to-end cycle time (2 – 3 months).  If we desire a healthy software product and project, 3 month cycle times for bug fixes are unacceptable.

One of the top software project killers is lengthy feedback cycles.  The conversation around improvements for Project X could center around ways to reduce the feedback cycle between development and testing.  A potential solution would be to explore methods of automated testing.  The ultimate goal for our testing phases would be an enforceable WIP limit that would ensure flow of value to the customer.

Reflection
You may be wondering why Project X uses such low fidelity tools (white board and spreadsheet).  There are very capable digital Kanban boards available.  Use whatever works for you!  White boards and Excel spreadsheets have a unique advantage, almost everyone has access to both in the workplace.

If you decide to try your own Guerrilla Kanban, realize that your effort is simply to create an environment where stakeholders have the tools to observe and make improvements.  As you begin to replace developer estimates with actual metrics, you will begin to build trust.  Once you have project visibility through the board and cumulative flow diagrams, you have catalysts for future process improvement conversations.

I hope this inspires you to start your own Guerrilla Kanban!