How our SAP BW team uses Kanban

We implemented Kanban a few months ago to manage our maintenance and support work on our SAP BW system. This blog explains how we implemented and use Kanban.

What is Kanban?

Kanban is a lean approach to agile software development. The approach is the following (from http://www.crisp.se/kanban):

• Visualize the workflow
  • Split the work into pieces, write each item on a card and put on the wall
  • Use named columns to illustrate where each item is in the workflow
• Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state
• Measure the lead time (average time to complete one item, sometimes called “cycle time”) and optimise the process to make lead time as small and predictable as possible

For a quick introduction to Kanban and its benefits, see http://www.crisp.se/kanban. For an example of a complex project (60+ persons), see Lean from the Trenches – An example of Kanban in a large software project at http://www.crisp.se/henrik.kniberg/Lean-from-the-trenches.pdf. If you want a comparison between Scrum and Kanban, see http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf.

Introduction

Here is our Kanban board. We use it to manage maintenance and support work. Today, the board is only used by two developers. We will expand its use gradually to the rest of the team at some later stage.

The board is not filled to its maximum capacity because we just released a whole bunch of stories to Production and we’re about to pull work from the backlog.

Backlog management

When we received a new request, we add a Post-It in the Created column (no WIP limit). A request could be a feature or a simple story (as in Scrum). Requests come from the business or from the team itself (i.e. internal work). If there is fixed delivery date, we write it on the Post-It.

If a feature/story is accepted, we move it to the Accepted column (no WIP limit). This is where features are broken down into stories. We try to break down stories so that it takes less than 5 man-days of development to complete them.

Pulling work

We then have a pull mechanism to fill in the Planned column. When the number of stories falls below a predefined level in this column, we start to replenish the column until we reach the WIP limit. This is easily achieved as we have a daily stand-up meeting in front of the board with the team. Obviously, we need to groom the backlog (Created and Accepted columns) in order to have stories ready.

Stories then move through the Development, Tests, Deployment and Done stages. We have WIP limit on all of those except Deployment.

Blocked Story

If a story is blocked, we add a pink Post-It next to it with a brief description.

Tasks

If needed, we add additional Post-Its next to a story with tasks (this is very rare and happens usually in development when more than one person needs to work on a story).

Defects

If defects are found during testing, we add a pink Post-It next to the story with a brief description of the defect.

Definition of Done (DoD)

DoD is described above each column. This is very important to ensure quality. For example, the DoD for Accepted is:

• Business objective is clear
• Teams are synchronised (if external team involved)
• Feature is broken down into stories
• Feasibility confirmed

Swimlane

We also have a swimlane (at the bottom) for support work (no WIP limit).

Implementation

Kanban is very easy to put in place because you start from your existing process and you gradually improve it. First, we identified all the steps in our workflow (e.g. Analysis, Development, Test, Deployment and Done). We then added all our work in progress on the Kanban board.

We immediately visualised the bottlenecks and took actions to keep things moving (that’s the beauty of limiting WIP). We then talked about retrospective (to optimise the process) and decided to have it every month (we actually improve the process on a daily basis but taking one hour every month is good to have a “higher” perspective).

We had discussion about the way we release to Production and decided to keep things the way they were i.e. release to Production as soon as ready (except during critical period e.g. monthly financial closing).

Finally, we met our internal clients to see how they wanted to plan work i.e. define priorities and schedule work. Basically, they were happy about the way we handled priorities. We thought about having a weekly or bi-weekly meeting but they rejected the idea. The pull mechanism we put in place (i.e. fill in the Planned column when the number of stories falls below a predefined level) seems to work well so far.

Benefits

Here are the main benefits:

• This is not linked to Kanban as such, but mapping our workflow was a good opportunity to review our processes and make things explicit. This led to interesting discussion and decisions.
• Bottlenecks become clearly visible. This led to immediate actions. We also made some decisions about the way we synchronise our work with other teams. This made the process smoother.
• Pulling work into a Planned column makes the process smoother (the team had a tendency to start working on requests as soon as they arrived).
• The Kanban board gives instantaneously a global vision of all our work, including impediments.
• The daily stand-up is a very good way to synchronise the work of the team. You may think that people know what their teammates are doing because they sit next to each other. This is not the case. Interesting exchanges take place every morning.
• Having retrospectives is a good way to improve the process. For instance, we simplified the workflow this morning.

Resources

Kanban by David J. Anderson

Afterword

Should you have any questions on Agile/Scrum/Lean, do not hesitate to contact the Agile+ community on Google+ at http://plus.google.com/u/0/104017139996657183972/posts. Your questions will be forwared to the community if needed.