Talking with carpenters

We are currently renovating an entire floor at home, and yesterday I tweeted about a Kanban board I put up for my carpenters. This was only meant as a “joke”, of course, but it generated some feedback and therefore, upon request, I share the board with you:

image

The intention was not to create a complete work list for them, but I wanted to visualize where their work and my work meet. A couple of examples are; “Pick up new kitchen from [vendor]”, “Tiles will be delivered between 0800 and 1400”. For now I use the columns Later -> Tomorrow -> Today -> OK!

And how did they respond to this? They seemed to understand the concept right away. They even pulled me over to the board today, pointed at a note to discuss possible changes for this particular item. That’s a good sign, if you ask me. They might never move a note on their own, but I think we communicate better this way. Luckily, the carpenters are early birds, so we even have time for daily standup before I leave for work.

To be honest I’m not sure if this goes under the definition of a Kanban board, but once again I see that a visual representation of how we work is powerful.

Exploring WIP limits

A few months back I was involved in a highly developer centric project (very unlike my current project). Non-developers were basically only involved and available upon request, so most of the time the team was not very cross-functional.

The team was using Scrum at the time, but the flow obviously had a few glitches and user stories had a tendency to pile in the test column, until very late in the sprint. A huge team effort at the end of the sprint made us finish most of the user stories just in time for demo, but the hurry was at the expense of quality.

It seems to me that most developers prefer starting on a new user story, rather than truly test and complete the ongoing user story. There’s really nothing strange about this, because often the fun part is gone as soon as the problem is solved. In the good old waterfall days, as a consequence to this “law of nature”, none of the features in an entire release might have been tested properly until very late in the project. Needless to say, this didn’t work out very well, and agile emerged to address these problems.

To fully complete ongoing tasks faster, we need to build in mechanisms in the process that enforces us to finish tasks before starting new ones. Iterations (sprints) do this by limiting the number of tasks we can have ongoing during a shorter period of time.

In our case, this didn’t do the trick alone. We shortened the sprints to only one week, and admittedly things got better, but the symptoms were still present. We decided to apply Kanban. First we put a WIP limit of 3 in the test column, later we added WIP limits to other columns as well, to be able to regulate the flow better. To improve the quality on the deliverables, we introduced a rule stating that the person testing a feature must be different from the person developing a feature.

In the beginning, the limits worked more as a guidance than actual rules – just to start changing the mindset from “push” to “pull”. After a while we paid more attention to the WIP limits, and lowered the limit in the test column even more (WIP = 2) to amplify the importance of finishing tasks. This turned out to be artificially low, but it was a great “pull” lesson for the team.

After a while the flow improved and the team effort was more evenly distributed over time. Initially, I thought we might have to “force” people into testing, but our board made it clear what had to be done, and the developers were eager to contribute wherever necessary (an indication of the power of visualization). As a bonus, the number problems we had earlier in the demos went down.

I should probably add that some of the developers took more than their fair share of testing. Over time that could have been an issue we might have had to deal with, but for the short period of time the project was ongoing, it didn’t turn into a problem.

Still, these small changes made a huge difference to us. We no longer had to rush into demos with poorly tested features, and the “boring” parts of process were no longer only at the end of a sprint.

Customizing your Kanban board

Lately, I have seen several blog posts and twitter chats emphasizing the importance of customizing your Kanban board. This applies everywhere, no matter if you use a straightforward linear Kanban board, networked Kanban or even your own personal Kanbanyou need visualize the flow so that it fits the way you work.

This is quite obvious. After all, it’s one of the key elements in Kanban. Still, it’s easy to get stuck in old habits, and soon you end up with a Kanban board that does not support the way you work (or even worse, you change your flow unintentionally to make it fit your board).

Pawel Brodzinski shed some light on the importance of this in a recent post: “We are told to visualize workflow, not to use a specific Kanban board design.”

Pawel also mentioned that he likes working on visualization with people from different industries than software development, as they don’t have the same constraints as the rest of us. I fully agree, we need to look outside the software industry to take a leap forward. As a matter of fact, I wrote a blog post about the abilities needed to do this a few months back – seek inspiration elsewhere. So, if you got a cross-functional team, pay extra attention to people from outside the software industry when creating a new Kanban board.

In Kanban you start off visualizing your process, the way it is right now. Then you move on from there, taking deliberate decisions, improving your process – step by step. Is this the way you start off as well, or do you start with a board design you already know, and adapt the process to fit the board? Maybe it’s a gap between the way the board is designed and the way you work?

Creating a board so that it fits your process, is not always easy, but if we think in new ways there’s a chance end up creating a better board. Here are some ideas, with different strength and weaknesses, that might inspire you to think differently.

Mattias Skarin described 10 different Kanban boards at Crisp blog. I’ve picked three examples, but I highly recommend reading the full paper.

System administration team supporting development and production (note the direction of flow and priority):

Development team with completion prediction:
First line support:
Pawel Brodzinski provided a different example using yellow stickies on tickets to limit the WIP:
Arne Roock showed an example of how to illustrate WIP limits using clips. Whenever a clip is free there’s capacity in the column. When a ticket is finished you can rotate it 45 degrees.
A great example from Kanban School illustrating multiple values streams.
Finally, an example of a personal Kanban board from Vasco Duarte, almost looking like a flow diagram:

The bottom line: Don’t be colored by the examples you see all the time. For many, these examples can be a great place to start, but these are not the only way to visualize your workflow.

Read the following posts, and get inspired to discover the true potential of your Kanban board!

10 Kanban boards and their context:
http://blog.crisp.se/mattiasskarin/files/pdf/10different_kanban_boards_and_their_context_mskarin.pdf

Alternative Kanban Board Design:
http://blog.brodzinski.com/2011/11/alternative-kanban-board.html

What‘s the kanban in Kanban?
http://www.software-kanban.de/2011/11/whats-kanban-in-kanban.html

Kanban and Multiple Value Streams
http://www.kanbanschool.com/10/kanban-and-multiple-value-streams/

Kanban in a networked process — Visualise the network!
http://softwaredevelopmenttoday.blogspot.com/2011/11/kanban-in-networked-process-visualise.html

I would love to collect some new ideas, so please share your Kanban board by sending me a picture on Twitter?

Kanban in a non-linear flow

A Kanban board is supposed to represent the current process, the way it is right now. Representing the way we work on a simple, linear, Kanban board, is not always easy. In fact, it’s not always possible. Sometimes, the way we work is more complex than that. Jurgen Appelo described how to deal with more complex systems in his recent post on networked Kanban, and that’s what inspired me to write this post.

When first reading about it I was intrigued by the thought of modeling more complex structures as well. As it sunk in on me, however, I realized this also could mean letting go of one of the major advantages in Kanban – the way we improve our flow from start to finish.

I ended up conversing this with Jurgen Appelo and David Anderson on Twitter, and they both helped me understand this better.

Visualizing the current flow, and then continue to improve over and over again, is a key element in Kanban. So what happens if the current flow is too complex to visualize it linearly? Jurgen Appelo suggests using a networked Kanban, a collection of small Kanban models interconnected. The different teams only look at their local Kanban models and improve their local flow.

If there are several local Kanban models in a workflow, how do we improve the flow in the network as a whole? In the end, that’s what we want, right?

In a Kanban representing a linear flow we improve the flow from start to finish. In a non-linear Kanban, if the interdependencies are complex enough, only a few people will understand the entire flow – from start to finish. For local Kanban models it’s business as usual. It might even lead to reduced complexity for them, as they now only need to deal with a simple flow.

What’s bothering me a bit, at first sight, is that if we do this wrong we risk that local Kanban implementations are sub-optimized against the best possible global performance, only because they don’t see the bigger picture. Also, if we start off with a complex structure like this, it will make Kanban “harder” to introduce. If we have too many project policies regarding entry/exit criterion between different Kanban models, people might start treating Kanban as process – not a method.

The clear and to the point linear Kanban board is easy to grasp. People walk by and understand the current process and the status right away. The team itself understands the entire flow and optimize it continuously. Will this be harder with a networked Kanban?

I believe the answer to the question above is yes, but that doesn’t mean it’s a bad idea. Forcing a non-linear flow into a linear Kanban is not a good idea, so we need to look for new ways of representing, visualizing and improving more complex flows.

More research on this topic is necessary, so we get a better understanding on how this can be applied. How can it be visualized, who should be responsible of improving the entire flow, how will different teams interact? And most important, how do we do all this stuff without turning it into a rigid process?

Personally, I would like to see several different examples on this. The backside with examples are that they might set the standard on how this should be implemented. Therefore, it will be important to view this from different perspectives. We need to appreciate the fact that all have different needs, and that there should be as many ways of doing this as there is networked Kanban implementations – just as regular Kanban implementations today.

Here’s a couple of ingredients to keep in mind when you apply this:
1) Let the independent Kanban systems optimize their own flow. Treat dependent systems as “customers”. (David Anderson)
2) Scale out and not scale up. It’s better with 10 simple models instead of one complicated model with 30 columns. (Jurgen Appelo)

To me, this approach is new, but it has actually been brewing for a while. As it turns out, David Anderson presented a similar approach to what Jurgen Appelo described in his post at LESS 2010 in Helsinki, and Reaktor has been coaching this approach with clients for a while.

A final remark: Even though we now have the tools we need for modelling a complex flow, try to keep it as simple as possible!

If you have any experiences or thoughts on this, I would love to hear from you! Use the comment field below, or drop me a note on Twitter.

Note: David Anderson will cover this topic in his next book on advanced Kanban, which I’m really looking forward to reading.

Kanban for portfolio management

Yesterday, I published a blog post about using Kanban for portfolio management on my company’s blog.
http://open.bekk.no/kanban-pa-portefoljeniva/

It’s in Norwegian, so here’s a brief summary for my English speaking audience.

I work closely with my customer’s project department, and I believe they could benefit from using Kanban for project portfolio management. Here’s an example of a project portfolio board.

They could start by adding two simple steps (in addition to what they’re already doing):
1) Map current process to a Kanban board
2) Meet regularily for stand-ups

By visualizing the process and meet face-to-face more often, all people involved get a deeper understanding of how their process works. Bottlenecks gets exposed more easily, and this could plant a seed, nurturing continuous improvement.

I also suggest adding a WIP limit for ongoing projects, based on their current capacity. This could be a tool to manage individual workload and reduce stress, and could be used as an input for overall staffing questions.

Anyhow, I stress the fact that this is an evolutionary process, don’t try changing all at once. Start by visualizing the process and introducing stand-ups.

Visualizing project policies in Kanban

When David Anderson visited us last month, he mentioned that we must make sure project policies are explicit by writing them down. Recently, I had a some sort of epiphany that some of these policies could be visualized as well – directly up on the wall.

I prefer a whiteboard and post-its for our Kanban wall, at least as long as the team is co-located. This gives us an instant overview of the flow, and we gather around it to discuss how to optimize the throughput. It’s simple, but flexible.

To keep track of lead time and cycle time we update the tickets with important dates as we move the tickets across the board. However, I noticed that tickets weren’t always updated with necessary information for my statistics, so we needed a better approach.

First we standardized the way the tickets look, with fixed places for different items, but routine glitches still happened every now and then. Then we started to visualize the criteria for moving a ticket to a new state.

First arrow in the image above shows the transition when the ticket is prepared and moved into the backlog. The person moving the ticket fills in the current date in the upper left corner (the red square). Similar happens in the next transition from backlog to analysis.

When moving from development to test, another person must test the new feature (or defect).

When tickets are done, the completed date is added, accompanied by a subjective well-being using :-), 😐 or :-(. The latter is later used in the retrospective.

Most of these visual elements were added just a couple a weeks ago, but so far the notation seems to be easily understood and effective.

Are you visualizing any of your project policies?

 

P.S.: Thanks to Jim Benson for a great tip on how to measure the subjective well-being, as an input to the retrospective.