Alexander Vanwynsberghe

"There is nothing impossible to him who will try"

How we use Kanban in our development team

A while ago I wrote a blogpost about why scrum didn’t work for us. Some of you did suggest me to use the Kanban methodology instead. This would be a much better suit for our team. I did a lot of research of what Kanban really is, what the best practices are and how to implement this in our team. I will tell you in a few steps how we did this..

First of all, what is Kanban? Well, Kanban is a method to visualize the development work flow and the work in progress. Kanban has 5 principles:

  • Visualize the workflow
  • Limit WIP
  • Manage the flow of work
  • Make process policies explicit
  • Improve collaboration 

Using these aspects, you can highlight any bottlenecks in the development process. You have a visual overview of the things which are happening in your team, so you can guide it. Perhaps change the process, change the WIP limits, ..  

Kanban is an approach to change management. It isn’t a software development or project management lifecycle or process.

A kanban system is often designed on a big white-board used to reflect the workflow. Different color cards are used to show different types of work. This could be a task, a user story, a bug. There is a more detailed description of the task written on each card.

The first thing I had to do is reflect the development cycle to columns on the whiteboard. Pawel Brodzinski made a very interesting blogpost about that. Using his guide, I created my first-ever Kanban bord. This is how our ‘version 1’ board looks like:


Note that the columns seem to reflect some kind of waterfall style process mapping. Well it isn’t. The Kanban board reflects all phases an item must go through in the development cycle. It encourages small independent user stories to be developed in little pieces. The columns on the Kanban board don’t represent hand-offs between team members but more or less the state of what’s the feature in during that time in its development lifecycle.

As you can see, we also use some Kanban queues. Those are a small inventories between two processes to create the appearance of instant availability. 


Some notes on our board

  • How did we define the WIP limits? Trial and error.. There is no science which will tell you what’s the best WIP limit number. It depends on your process, your team capacity, ..
  • We will not continiously deploy. We keep a list of features/bugfixes in the ‘ready’ column, and the PO decides when there is enough ‘buzz’ to make a commercial feature release/bugfix release.
  • High priority is a special ‘swimlane’. If there is an item there, mostly a bug, the developer is obliged to pull that item when he is ready for some new work.
  • There will be a montly retrospective meeting. In this meeting we will discuss the board, check if the colums are still good and if there are other remarks.
  • The queue will (mostly) be fed by our weekly prioritization meeting.


Why is Kanban better than Scrum (for us)

  • First of all, they are both process tools. They both help us to work more effectively.
  • The biggest difference is that Scrum is iterative based and Kanban not. This was a problem for us as with Scrum, we never released what was planned in our sprint.
  • We went from PO driven development to a combination of PO driven and sales/client driven development.
  • We handle critical issues much faster that we used Scrum, where you have to wait till the start of the new sprint.
  • We can prioritize our items so important things go first.
  • Developers have more motivation (maybe because Kanban is less prescriptive?)
  • It’s easier to work on multiple products. If we want, we can even use a different swimlane for each product.


What will change?

  • Other (bigger) post-it’s with more information to visualize. The current post-it’s only have a brief description of the ‘todo’, but I want more information on it. 
  • I also want the start/end date and the time spent on the task visualized. I would like to make some stats to define average lead time (starts when the request is made and ends at delivery) and cycle time (clock starts when work begins on the request and ends when the item is ready for delivery)
  • Investigate the possibility of using swimlanes for user stories and the linked user story tasks.
  • Kanban cards are now colored by type. Like: a feature, a bug, a task, .. Perhaps we can use the colors tho define which type of work. Like: core development, configuration, design, marketing, .. ? (any suggestions on that are welcome!)
  • The outline of the sub-columns needs to be smaller, or maybe dot-lined. Now it’s hard to see the general ‘flow’.


Some interesting links


Thanks for reading and I’ll keep you posted when something changes in our Kanban story!

Why scrum doesn’t work for us

In this blog post I’ll try to explain why using Scrum didn’t fit our needs. I’ll talk about the main reasons, my personal opinion and what the alternatives are for our team.

First of all, let me explain the team situation, the products we make and how we used to work.

As mentioned in my first blog post, I work as a development team manager at a software company. We develop a collaborative framework which is the base of some main products. The team working on the applications consists out of some developers, configurators and designers. They all work on our framework and the various products.

You get something like this:



We did already work on an agile way of software development, but we needed a better way to manage the process, to create structure and overview. All this using a time-boxed iterative approach. So we did some research on Scrum. From what we’ve read and learned about it, this was the way to go. 

Scrum its use has focused on the management of software development projects, and it can be used to run software maintenance teams or as a general project/program management approach.


On the exact moment that we wanted to implement Scrum, Visual Studio 2010 (our development software) released a Scrum process template, perfect! This process template is a great way to define a product backlog, create sprints, work-items, test cases, a burn down chart ..

So we had a decent tool, we had a great product backlog with lots of amazing new features to be implemented, we had a good team, we did standup-meetings in the morning, sprints were defined.. Off we were…  


But after a while, things did not work out as planned. That’s why:

  1. There are too many projects and custom client-solutions
  2. Our team is too small to focus on the sprint for each project
  3. Sprints take much more time to complete than planned.
  4. Every team member is working on all projects at random, it’s hard to ‘focus’ on the defined sprints.
  5. Sprints are influenced by clients. Client requests have a higher priority than the sprints
  6. There was not enough discipline for the daily standup-meetings
  7. In general, time boxed iterations do not work for our -type- of work
  8. Our sprints are mostly event driven, instead of time driven

My personal opinions:

  1. It’s definitely not the fault of the tool, which is awesome
  2. We have to combine big feature development with custom client-development, support and maintenance
  3. There are too many Work In Progress items at a time
  4. The best solution is to stop using Scrum


We’re currently looking into another solution which will suit us better. I’m talking about Kanban, but more about that in a later blogpost.

Any suggestions and experiences are welcome, just post a comment!