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.

Using Kanban in retrospectives

I remember reading about the Lean Coffee movement. Inspired by their totally open meeting format, I figured this could be an excellent alternative for our retrospectives. Lean Coffee meetings use Kanban to structure their meetings, they democratize their meetings to learn and discover things about what they don’t know – as well as exploring further what they already know. Sounds like a good fit for retrospectives to me!

I decided to try this out in our weekly retrospectives. After some research I ended up using Kanban similar to what Benjamin Mitchell described in this post a while back.

Here’s our meeting board.

Gather information

We fill the ToDo column with different types of tasks.

1) Ticket (user story)
An important step for improvement is to analyze the tickets we have completed. We measure our subjective well-being of a particular ticket, simply by adding a smiley (also mentioned in an earlier post). There are no rules to what this smiley actually means, it’s just a personal way of expressing how we feel about a particular task.

Actually, there are two potential smileys on every ticket; the person developing the feature, and the person testing it (and this is not the same person according to our project policies).

Completed tickets are taken into the backlog for the weekly retrospectives. A ticket may look something like this:

2) Actions from last retrospective
Follow-ups, that we have finished since the previous retrospectives, are also put in the meeting backlog. Orange post-its for actions items (as we call them).

3) General topic (idea, problem, etc.)
To capture other topics that might be worth dealing with in the retrospective, each of us use a couple of minutes on our own, brainstorming, writing down ideas or problems that have occurred last week. We use blue post-its for this.

4) Time constraints
In addition, if any time constraints applies during the meeting (such as when a person has to leave early), we put that up in a time constraint column – pink post-its. This might affect the order in which we decide to go through the topics. Completed time constraints are moved to “done” when time has passed.

Running through the topics

With all the topics and time constraints available, each of them are given a brief introduction and put up on the wall. Overlapping topics are grouped together. We prioritize them using dot-voting.

We start off with the highest priority topic, and move on, one topic at the time, until time is up (which is 30 minutes). After a while the Kanban board might look like this.

Every topic is time boxed to eight minutes, but if we’re not finished discussing it by then, we might continue discussing it in a new time box – if that’s what the majority wants. Reordering the topics is allowed as we go along!

At the end of the timeboxed meeting this could be the result.
- Two old (and completed) action items debriefed
- One time-constraint passed
- One ticked discussed and completed
- Two general topics discussed and completed
- Two new action items created

Some topics lead to concrete actions. These post-its are put up on the project’s Kanban wall when the meeting ends. If it’s a small task, we usually fix it right away, if not it’s prioritized along with other normal tickets. We take completed action items back into the next retrospective, at least to give an update on what happened, but maybe also discuss them further.

We have been using this approach for a couple of months now, and it seems to work quite well. The structure is fairly easy to grasp, so that all team members can run the retrospective if necessary. We gather data for the meeting backlog in several different ways; finished user stories, previous action items and general topics. All participants prioritize the meeting backlog together, and we move on, highest priority first, until time is up.

Until now, this method has given us new and valuable input in every retrospective. Nevertheless, we will probably spice things up occasionally by using a different technique, just to get a different perspective on things.

Have you tried using Kanban to structure your meetings? Or are you thinking of it? Please share your experiences or ideas below.

(…and the next natural step would be to start Lean Coffee meetings in Oslo now, right? Give me a hint if you’re interested!)

Update 18/10:
After a twitter conversation with Benjamin Mitchell yesterday, I’ll nuance the picture a bit.

1) Our meetings are very effective, actually almost close to stressful. It takes time to prepare and prioritize the backlog, so 30 minutes every week might be too often – or too short. I guess this depends on the team and the situation, but we consider running the meetings 1 hour biweekly. Or maybe you have other ideas on how we might reduce the time it takes setting the stage?

2) The link between the project’s Kanban and the meeting backlog, lets us delve into more details on completed action items and tickets – and find new ways to improve. Vice versa, new action items from the meeting are followed up in the project. These links, both ways, are probably the best things about this approach. Even though it might be valuable also to discuss items in progress (those are fresh in mind), we wait until they are completed. Reason? Simple. We use a manual board, and if we move ongoing items off the board, we risk messing things up. Keeping track of this should be simple, but we skip it to avoid complexity.

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.

Estimating software projects

My Twitter stream flooded with estimation related topics yesterday. We’re currently starting up a new project, so the timing was perfect and the topic highly relevant. Here are some recommended blog posts from yesterday on the topic:

Estimation is at the root of most software project failures
In this blog post Rob Bowley explains why we’ll never be very good at estimation, especially the long range high level estimates – mostly for reasons outside of our control. Still many people in the Agile community talks about estimation as if it’s a problem we can solve. The discussion after the post is also highly recommended:
http://blog.robbowley.net/2011/09/21/estimation-is-at-the-root-of-most-software-project-failures/

You Mean I Can’t Even Estimate? The Planning Fallacy in Action
A post by Jim Benson, down the same alley as Rob Bowley. Explains how we might deal with the fact that there will be a variation in every activity, and that we tend to underestimate a given task even if we’ve done that task many times before:
http://ourfounder.typepad.com/leblog/2011/09/you-mean-i-cant-even-estimate-the-planning-fallacy-in-action.html

Estimate the total cost of Agile projects
Kane Mar first describes why estimating the cost of software is, at best, an educated guess. Then he explains how to deal with this when estimating the total cost of Agile projects: 
http://www.scrumology.com/2011/agility/estimate-the-total-cost-of-agile-projects/

Story estimation on Agile teams
A comprehensive Q&A by Praful Todkar. Who should be involved in estimation? Should we time-box estimation? Is pre-analysis necessary before estimating a task? What should we include in our estimates?
http://computellect.com/2011/09/12/story-estimation-on-agile-teams/

On the previous project we started off estimating stories before taking them into the sprint. When we gradually moved into the maintenance phase, we discovered that we only selected stories by priority – not size. Also, the stories were quite small, so estimating them seemed like a major overhead.

Not giving any real value anymore, we decided to stop estimating stories. Later, when we applied Kanban, we removed the iterations as well. We’ve managed well without estimation for about eight months now, instead focusing on the flow and maximizing throughput.

So here we are, about to start a new project. I think the time is right for us to reflect on why we estimate stories, and why we (try to) estimate the total size of the project. After all, for this particular customer, Scrum is the “company standard” – they’re used to estimating stories before prioritizing and starting them. Therefore, I think this is where we will start, this is what the company knows. But who knows where we will end up?

Do we still need estimates, or do we eventually get into trouble anyway when using them? Do you know other relevant blog posts on this topic?

Kanban and Scrum after 500 tweets

I joined Twitter June 22, 2010, so, needless to say, I was not an early adaptor. Nevertheless, I just passed 500 tweets, and most of my tweets are somehow related to agile development, so did I come across something useful? The answer is yes, and I believe it’s an appropriate time to reflect – focusing on Kanban and Scrum this time.

During this period I’ve learned to enjoy Lean thinking, and Kanban in particular. The difference, you may ask? David Anderson puts it well:
“People ask me what is the diff between Lean & Kanban? Answer: Lean is a destination, Kanban is a means to get there.”

If you don’t know Kanban, here is a clean and to the point overview:
http://reaktor.fi/en/our_expertise/kanban/

And here is a first hand experience on what you can expect if you introduce it:
http://www.agilecoach.ca/2011/07/07/kanban-reboot-pt1

It’s not always easy to map a process to the Kanban board, so you might need some tips when you are stuck: http://blog.brodzinski.com/2011/08/map-process-to-kanban-board.html

After a while, you will know that keeping an inventory is not free of charge, and there might be an upside if you manage to keep it down:
”In 1987, while GM held 2 weeks of parts in inventory, Toyota held 2 hours.” (Jeremy Lightsmith)

By then you should know that you need to pull work items, not push them. This strategy, if you see the analogy, might even affect your leadership:
“Management is push, leadership is pull.” (Jim Benson)
…and what’s really the difference between a project leader and a project manager?
http://www.projectsmart.co.uk/project-leader-or-project-manager.html

Kanban takes an evolutionary approach, so big changes won’t happen overnight, but you should still be prepared for resistance in the organization. Here are 5 arguments against Kanban – and how to respond to them:
http://noostvog.wordpress.com/2011/06/29/5-arguments-against-kanban/

Even though I find Kanban very appealing, I still like Scrum. Recently, Scrum even got a major update to the Scrum guide! I found it really interesting that they now had removed release planning, cause it might compensate for poor development practices:
http://www.scrum.org/scrum-guide-updates
This doesn’t mean you have to stop all release planning, it’s just not mandatory anymore, and you should use it with care. This is an example of one small step you can take to improve the quality.

And quality, that’s what you need to focus on, no matter what agile process you are using. If you shorten down the feedback cycles, that would help you on the way. To get fast feedback, there’s a number of things you might consider:
…shorten the iterations:
http://www.itjoblog.co.uk/2011/06/the-iteration-is-too-long.html
…keep the releases small and deploy to production often.
http://kenschwaber.wordpress.com/2011/03/23/major-releases-are-a-failure/
…but maybe not 50 times per day?
http://www.thehackerchickblog.com/2011/02/continuous-deployment-for-continuous-learning.html

If you want to go fast, you need to move with a sustainable pace. You need to stay clean so you can keep going fast:
http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot

So, to be able to shorten the feedback cycles, you need to focus on getting working software at the end of each sprint. And if you don’t, you’re definitely not alone. Over 50% of Scrum teams can’t get shippable code at the end of each sprint. Research shows that this will slow you down between 2 and 24 times:
http://scrum.jeffsutherland.com/2011/01/optimized-scrum-getting-to-done-done.html

There are many topics I didn’t cover this time, so maybe there is room for another post?

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.

Who’s your safety valve?

I love what I’m doing, I can actually be pretty passionate about things, and if I really believe in something my first instinct would be to let others know how this can make their lives, jobs, projects – you name it – better. But if you ask people I have worked with over the years, I guess they would characterize me as quite calm and diplomatic.

So how does these traits go along? In the beginning of my career I could burst out with things every now and then. Luckily no irreversible mistakes were made, but occasionally it was a bumpy ride. Now, even though my face might turn red, verbal and written outbursts are far less frequent – actually almost completely absent. I’m still passionate about things, but the difference is that now I have a safety valve.Outburst

My safety valve is a trusted person I can share my thoughts and ideas with. Even more important, I can share my frustrations openly with this person. When heated I use my safety valve to read through e-mails and documents before I fire off something I will later regret. The safety valve is most likely sitting somewhere nearby, and sometimes, depending on the situation, several people can act as my safety valve – maybe covering different areas.

Even though I have my safety valve right next to me, I always reflect a few seconds, on my own, before sharing my frustrations. I work with different customers and need to take confidentiality issues into consideration, so it’s not a given that everything can be shared with everyone. As the relationship with my safety valve develops there is room for discussing almost everything. To build a safety valve relationship, get comfortable sharing thoughts and ideas, before moving on to frustrations.

One last thing, the safety valve system works better if it’s bidirectional, so make sure both get the opportunity to vent. Call it bidirectional coaching, if you like.

Do you have a safety valve?

Kanban workshop with David Anderson

By using a Kanban board game, David Anderson demonstrated Kanban in an engaging and fun way when he visited BEKK last week.

I’ve publised some of my notes on the company blog, so read on if you’d like to know more.

Improve team performance – seek inspiration elsewhere

As a teacher, my wife had to step in to avoid a conflict among sixth graders at school. She told me that she would let her students come up with different solutions on how to solve this conflict the following day. I mentioned briefly that she, in this particular case, could use a retrospective technique I have used in several occasions, prioritizing with dots, and let her students vote for the solution they would prefer. 

It slipped my mind for a while, I didn’t even go into details when I mentioned it, but a couple of days later she told me she actually had tried this technique out on her students. Some minor adjustments was necessary to make it more suitable for sixth graders and a chalkboard, but in essence it was the same technique.

She found the results surprising. While she expected the majority to vote for asking an adult for help, and at lower age they probably would, the majority voted for a certain way of solving this on their own – without adult intervention.

Instead of taking the answer for granted she generated new valuable insight of how her students think – and she only spent a few minutes totally. In addition she might have found the tipping point when children start behaving like adults in terms of conflict resolution.

For those of us who embrace agile development, we might find some inspiration in this to bring back to your workplace.

Retrospective can be successfully applied at any age and with all kinds of people, just remember to adapt it to your audience. Even the smallest effort can generate valuable feedback, and you might be surprised of what you find. This can help you improve your team.

My wife tested a new retrospective technique amazingly fast – with almost no preparation. It seems to me that they have a great environment allowing them to experiment. If they make a mistake, they get immediate feedback from theirs students and take a different approach next time. This is an important agile principle, find a faster way to fail, recover, and try again.

Create a climate in your organization that allow people to experiment and innovate, make sure there’s time to do this. Break a few rules. Take a step outside your normal boundaries and seek inspiration elsewhere, for instance see how they use visualization in a first grade classroom – the prototype for a creative learning environment. Some elements might be useful for your agile wall.

Question: Have you ever been inspired by something you have discovered elsewhere, outside your normal domain, and brought it back into your team? And how did it go?

Further reading: