Combining Kanban and Scrum – lessons from a team of sysadmins

Lately, Ken Schwaber’s post about Kanban, strongly stating that it’s not a good way to follow, stirred up Scrum, Kanban and lean worlds. Let’s not take any side here and take a closer look at these two approaches collaborating.

Kanban itself is ultra light. You can pretty much enclose it in one statement: visibility & limiting work in progress. Sounds nice and lean. I see a huge problem here – this is not enough. Kanban is so light, that it does not provide sufficient guidance for teams adopting something different than cascaded development or guerrilla-style support. I have teams not able to cope with coming up with the whole process themselves. Because in this case, the team has to come up with:

• A way of gathering requirements
• Guarding the process
• Solving problems with team growth
• Conveying business value
• Reporting future projections
• Handling finance issues
• and so on …

Coming up with all of this would take huge amount of time & effort which then is wasted, since the team is not productive. And we cannot introduce a manager, since then self-organization will not occur. This is asking for waterfall-like top-down process control. I guess I can understand Ken Schwaber’s doubts about Kanban now.

But what about teams that do support work? They are unable to plan their sprints. Like for example system administrators, infrastructure providers and so on. It’s good if the development team is supporting their own tools, but there has to be someone that provides rack space for this team. There are also teams that are supporting sunsetting products, so they are only fixing most critical bugs, before the product will be forgotten or replaced. They are also unable to use Scrum, since they are unable to plan for a week (but they tried).

Some time ago, we tried to combine Scrum and Kanban. I always oppose when someone uses the word Scrum when they are not using Scrum, so this approach was named Kate-Ban :). We took what we needed from the Kanban approach and dragged everything else from Scrum. Let’s see how it worked out.

There were a few initial issues – the team was not cross-functional. There were Windows sysadmins that supported laboratory network and Linux sysadmins that supported working network and connections between sites. Due to security policies, these two sub-competencies would never fully mix. Windows guys had some basic knowledge about Linux environments, but did not have access to all parts of them and vice versa. In addition, there were around 1700 customers for this team, so determining order in the backlog was no easy task. This also made it very difficult to track ad-hoc work, which was later estimated for 50% of the total capacity. Of course ad-hoc work in this case meant 10 minute problems, like creating an account, not bugs to be solved in under a day – that was solid work.

The board was designed like this:

Queues (green lines on top)
There were two queues – the Linux and the Windows one. People were pulling elements from queues according to their order – the ones in the bottom-right corner were most important. Whoever was able to take a task, could take it. Mainly Linux admins were taking Linux tasks, same with Windows, but it wasn’t a rule. Who could complete a task from front of each line, pulled it. Both queues were limited to 10 elements, rest was kept in a Product Backlog.

Competency groups (yellow lines)
Each group had a limit of 4 tasks to be taken in total (having three people) and in addition there was a QR task in each group. QR was pretty much being a firefighter and taking the smallest stuff. It was critical – based on what the QR was doing, new tasks were added to the line, helping automate this role as much as possible. There is also an on hold zone, for tasks that got stuck due to external interference.

Done & rejected (red lines)
Done was cleaned up whenever it filled up. Rejected were those tasks, that suddenly were not needed, or after little investigation did not make sense.

So, this was all there was from Kanban. Now, it was Scrumified.
There was a Product Owner, who was taking care of the Product Backlog, and producing tasks for the board. It was his job to make sure there is always enough to do on the board, but not more than 10 in each queue.
There was a Kanban Master (me 😉 ), who was taking care of the process, making sure that the board looks neat, takes care of the team development etc.
There was a Definition of Done for few types of tasks, that had to be followed.
Every week there was a Grooming session – one very technical, one customer-oriented.
Every two weeks there was a Retrospective, unless called for earlier.
There was a Review, called by the Product Owner whenever a logical part of functionality was completed, maximum every two weeks.
There were Daily Plannings – a combination of Sprint Planning and Daily Scrum – a two-tier half hour meetings by the board, where the team accepted new elements in queues, planned their next 24 hours and briefly reviewed completed work.

Pitfalls:
No Deadlines. In Scrum, Sprints were providing the heartbeat, the moment when the work was inspected, certain feedback – there was nothing like this in this setup, so after some time, for most critical tasks and the ones that were on the board for too long, the team started adding deadlines.

Having no regular feedback loop also enabled some people to slack off, start doing something else in the meantime and it went through undetected for quite some time.

In this case, this team had an excellent Product Owner, but it would be easy to change this from pull approach to push in an instant.

Surprises:
Since it was too hard to estimate in this environment, tasks were not estimated. Product Owner was projecting from the amount of tasks alone, not from their size. It was working surprisingly well with such a various environment. I guess that Jim Highsmith is darn right, calling for forgetting velocity. Let’s look at it later though.

The story of this team was unfortunately abruptly terminated due to a series of unfortunate events. It was later replaced with some people that decided only to follow some of those rules, but it’s not working very well.

Conclusion:

A team that used Scrum before, or at least tried and gets all its benefits and drawbacks is able to adopt Kanban on the Scrum canvas. A team that is supposed to be self-improving only by being given a statement with three rules in it has vague chances of success. Kanban is an excellent toolbox, but it needs a well-composed set of tools to be really useful.