Skip to Content

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

image

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.

image

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.

image

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).

image

Defects

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

image

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.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

    1. François Gyöngyösi Post author
      Hey Marc,

      Wie Geht’s? Good to hear from you. I’ve seen you moved to Toronto.

      Agree that Kanban boards are really useful to get an overall status quickly. 

      Had a look at InnoBoard. Impressive stuff! Is it only available in the Labs or do you use it internally at SAP? I understand SAP moved to Agile/Lean. I guess this kind of technology could be useful.

      All the best.
      François.

      (0) 
  1. Martin Fischer

    Hi Francois,

    Great blog! Do you also have a ticket system in place like incident management on the SAP Solution Manager? If yes, do you maintain status data in the ticket system and on the post its?

    We are also implementing Kanban and I’m looking for a way how to visualize Solution Manager tickets on an electronic Kanban board.

    Thanks and regards,

    martin

    (0) 
    1. François Gyöngyösi Post author

      Hi Martin,

      Sorry I missed your post. Yes, we have electronic system to track incidents and changes. We simply add the change number on Post-Its. We track the status on the Kanban board and in the electronic system.

      Regards.

      François.

      (0) 
  2. Dorota Zaremba

    Hi Francois,

    I like your blog very much! Found some nice inspirations for the future 🙂

    I use something like Kanban as well, but for me and my team it’s easier to work with a colorful spreadsheet in Google Docs instead of Post-Its. We have a separate spreadsheet for every customer we work for, so it’s easy to find out what is the current status.

    Regards,

    Dorota

    (0) 
    1. François Gyöngyösi Post author

      Dorota,

      There is a lot of discussion about physical versus electronic task board (just google physical versus electronic task board and you’ll get the pros and cons). For me, a physical task board has several benefits:

      1) It’s always visible to everybody. No need to open a document.

      2) It promotes interactions between team members during the daily standup (in front of the board where people physically move Post-Its around and discuss). You really need to experience it to realise how effective this is.

      3) You have an “holistic” view of what’s going on (not always easy with a spreadsheet). Again, difficult to explain until you experience it.

      Now, electronic board can be useful, for exemple if you have a distributed team. It’s also easier to produce statistics.

      At the end of the day, the best is to try and use what works for you given your context.

      Regards.

      François.

      (0) 

Leave a Reply