Agile Project Management with Kanban

Corey Ladas is not very active on social media (like Twitter, where he is @corey_ladas). So the joy is even greater when he writes something, like this tweet where he recommended ”Agile Project Management with Kanban” written by Eric Brechner sharing his experiences from using Kanban in Xbox development at Microsoft. I bought the book immediately after I saw the tweet since I’m both into project management and Kanban! The book was released in March 2015, and describes Eric Brechner’s four years of using Kanban. The question is, did the book fit me like a glove?



Looking in the table of content, the book has nine chapters and they are:

  1. Getting management consent
  2. Kanban quick-start guide
  3. Hitting deadlines
  4. Adapting from Waterfall
  5. Evolving from Scrum
  6. Deploying components, apps, and services
  7. Using Kanban within large organizations
  8. Sustained engineering
  9. Further resources and beyond

The first chapter describes an open letter to your manager that you can use to get your team started with Kanban to manage its project work. Next chapter is a quick-start guide how you get the kanban board up and running. For example ”completion rules” are mentioned, a check-list on what needs to be done before moving a sticky to the next column on the board. However, as mentioned ”The rules work only when team members hold each other accountable for following them”. A formula on how to calculate WIP and how to run good daily standup meetings are also present in this chapter.

Chapter 3, ”Hitting deadlines” starts with talking about MVP (Minimum Viable Product). It’s described as ”MVP is the set of work items (note cards) in your backlog that must be completed before release”. Here is how the backlog should be prioritized:

  • Must have – MVP, sometimes called ”pri 0”
  • Should have – Priority 1
  • Like to have – Priority 2
  • Nice ideas – Priority 3

Now it starts to get interesting, to be able to give expected completion dates the following things are tracked:

  • Task Completion Rate (TCR) – Track tasks completed per day
  • Current Task Estimate (CTE) – Total number of active and pending tasks (i.e. represents remaining work)
  • Task Add Rate (TAR) – Tasks added per day

Needless to say, if your TAR is constantly higher than your TCR you will never complete your project.

Chapter 4 is relevant if you are adapting to Kanban and are coming from Waterfall. Since this was not the case for us, I didn’t pay special attention to this chapter. However, if you need it, there is a ”Rude Q & A”-section at the end that shall arm you with answers to tricky questions from waterfall team members 🙂

Next chapter, ”Evolving from Scrum” was more appealing to me. Here it is described how to conduct the much easier transition from Scrum to Kanban. Mappings of roles and events (meetings) are suggested. Also this chapter, ends with an ”Rude Q & A”-section.

Chapter 6 covers deploying (among other things continuous integration and continuous deployment) and chapter 7 is about using Kanban in large organizations (upfront planning, status communication and handling dependencies). A particular interest concept of creating fakes is described to handle late dependencies. A fake is ”intentionally incomplete and unsophisticated – it contains just enough functionality for you to validate your key scenarios and components and unblock the teams that depend on you”.

”Sustained engineering” (SE) is a special contribution chapter from James Waletzky and how Kanban fits into SE is described. Last chapter provides references to litteratur to go further with Kanban. I’d like to end with a quote from the author on why Kanban works:

”Why does Kanban work so well? It’s a combination of visualization, minimalism, Little’s Law, single-piece flow, the theory of constraints, and drum-buffer-rope.” – Eric Brechner


Yes, the glove fit to a perfect match! This book was really spot on for me. If you are into project management and Kanban this is a true gem! The length is perfect for an agile book, 160 pages.

All the best,
 Tomas from TheAgileist

WIP limits

In a previous blog post I mentioned that we are in a transition from Scrum to Kanban. Or to be more precise, we have been using Kanban for almost a year, but some of the ”Scrum thinking” is still present in our teams. This doesn’t necessarily have to be a bad thing, but one thing we are really struggling with, is putting limits on WIP (work in process).


Can you see, there is something missing in the picture above?

Yes, you are correct, there are no explicit WIP limits present. Putting limits on work in process is essential to achieve flow through your work process and it also ”high-lights” problems that are candidates to be fixed in the name of kaizen (continuous improvements to your process). The WIP limits were there initially, but the teams didn’t see ”the meaning” with them, and removed them (after all, the teams are autonomous). In trying to put the WIP limit ”back” on the Kanban boards, I seek help from some fellows in the Kanban community. Their answers to my question ”How do you get the teams to use WIP limits?” are found below.

Mike Burrows

Mike seems to be a really nice guy and he is also the author of ”Kanban from the Inside”, find my review of this book here.

I tend to approach the question of limits rather indirectly, and (as you’ll know from my book) I’m interested in more than just column limits, being open to limiting WIP in multiple, cross-cutting ways. Tips?

1) I tend to start from the right hand side of the board, looking at the flow of work through (say) validation, deployment, acceptance etc. Not much point in optimizing the flow through development if the work is only going to pile up somewhere else.

2) I’m careful not to celebrate partially-done work (eg in status reports) and to report cycle times that go beyond development.

3) I like to organize work horizontally also and to explore the allocation of effort across those. In my current situation I’m seeing an interesting difference in performance between two workstreams that could be explained by a lack of discipline with regard to WIP.

Marcus Hammarberg

Marcus has helped us a lot. We are even reading the book that he co-authored, ”Kanban in Action”, as a book circle at work. I’ve also made a review of this book.

Hmm, I’ve seen this myself also. I think the most important thing is not to enforce anything: ”DO LIKE THIS! NOW!! This will only lead to alienation and the team will not feel that they ’own’ their Kanban board.

Ask the team – this is simplest, and hardest way; why is it that we always have more things to do than our WIP limit states? Is it too low? Why? I think it is also important to understand that WIP limits is not a law or a ”correct number”. It is a tool to find improvements. Breaching a WIP limit shall trigger a discussion; ”fine we are beaching the WIP limit now, but we do it on purpose”. Some teams that I heard about had a mini-retrospective each time it happened.


So how did we actually solve the problem? I leave you with a ”cliff hanger” for next week, when I present our approach in limiting WIP 🙂

All the best,
 Tomas from TheAgileist

Control room

We have a ”control room” where the teams perform all of their important meetings, like the daily standup and retrospectives (we call them Kaizen-meetings). This is how the room looks like.


I’ve put in some circles in the picture to be able to better describe to you what you see. Here it goes:

  • The green circle to the right – This is a priority pyramid that we use for visualizing our backlog. You can read more about how that is done here.
  • The yellow circles – Team kanban boards. We are in a transition from Scrum to Kanban so the boards are not perfect yet (to my opinion), but we are slowly getting there.
  • The red circle to the left – This is the Kaizen-board. Here we track long term continuous improvements with a simple ”To do, Doing, Done”-board. All stickies get a date on them when they enter the board, to be able to spot ”oldies”.
  • The white/grey circle to the right – This is a empty whiteboard. We use it to write down quick ideas on meetings etc.
  • The blue circle in the middle of the room – This is our gem! A 4K TV that currently shows status from our automated tests and our bug tracking system. Here we can always see the current situation. Basically green means ”good” and normal, and everything else is deviances that we need to act upon. All information is present to be able to build a SW-GPS for navigating our projects. The graphs are made with gnuplot. An extra HDMI cable is connected to the TV to be able to plugin a laptop for quick demos and other discussions.

In total we have eight whiteboards in the room (not all of them are shown in the picture). Also present in the room is a sofa (for coziness), chairs and and a small table to place a laptop on. Meetings in the ”control room” tends to be more informal than in a ordinary meeting room with a projector.

What does your ”control room” look like?

All the best,
 Tomas from TheAgileist

Kanban in Action

In just a moment this will be a book review of ”Kanban in Action” by Marcus Hammarberg and Joakim Sundén, but first I must tell you a story.



I’ve been working with Agile methods since 2008, starting out with Scrum, and sometimes I think that I’ve got a pretty good hang of it during the years. I’ve got some recognition for my increasing knowledge in the area by my co-workers, but nothing whatsoever from my boss. I’ve struggled along for sure, but that one piece of recognition have been missing…

I’ve read books about Kanban before I started to read ”Kanban in Action”, but with this book my knowledge took a gigantic step! I was sitting in a meeting with my boss and some other colleagues, talking about Kanban versus other methods for software development, when all of a sudden my manager turned to me and said: ”What are your thoughts on this, Tomas? You are our expert in this area!”. Yes, what a feeling, my boss had never mentioned my name and the word expert in the same sentence before :).


The book was released March 17, 2014, and it’s divided into three sections:

  • Part 1 – Learning Kanban
  • Part 2 – Understanding Kanban
  • Part 3 – Advanced Kanban

The first part, Learning Kanban, includes only one chapter, but what a chapter it is! It is 44 pages jam packed with just about everything you need to know to get started with Kanban. In fact you can stop reading the book just after this and still be very satisfied. The idea of explaining Kanban by using the fictive story about the Kanbaneros team is nothing but brilliant! There is no way I will go about and spoil this future reading for you, but I will give you my personal best take way from this part and that is: ”Stop starting, start finishing”. To me those four words sums it all up, to constantly think about flow through your process, to complete things before you start new to not clog the system.

”What now, didn’t you say that the reading could end after the first chapter?”, you might ask. Hold on, now comes the beauty of it, if you hunger for more there is plenty left to learn in part 2 and 3 (if you want to become an expert, remember 🙂 ).

Part 2 – Understanding Kanban, rewinds back to the beginning once more and goes through the cornerstones of Kanban, they are:

  • Kanban principles
  • Visualizing your work
  • Work items
  • Work in process
  • Limiting work in process (WIP)
  • Managing flow

One very specific text in this part is ”How to remove a sticky note from the pack”. It’s exactly what is sounds like! This really tells you how serious Joakim and Marcus are in their pursuit to explain Kanban in this book!

Advanced Kanban, the final part, goes even deeper into the kingdom of Kanban. Here you find things like:

  • Classes of service
  • Planning and estimating
  • Process improvement
  • Using metrics to guide improvements
  • Kanban pitfalls
  • Teaching kanban through games

A lot of good stuff, in which I can really recommend the last chapter about games. We have played both ”Pass the pennies” and ”The number multitasking game”. Those games will give all participants a deeper understanding in Kanban principles (in this case ”limiting WIP” and ”avoid multitasking” to be specific).


Today when I searched for ”kanban” on amazon.com and the list was sorted by relevance,  ”Kanban in Action” was the second book that came up. Only beaten by ”Kanban” (or ”the blue book” as it’s also called) written by David J. Anderson, the ”father” of Kanban. This itself tells you how important this book is.

I can truly recommend ”Kanban in Action” to anyone that wants to know just the slightest bit about managing knowledge work. From the first moment I started reading it, this has been my holy bible of Kanban!

All the best,
 Tomas from TheAgileist

Kanban from the Inside

I was home sick, lying in bed with a bad cold. I started to read ”Kanban from the Inside” by Mike Burrows (@asplake on Twitter). The under title of the book is ”Understand the Kanban Method, connect it to what you already know, introduce it with impact”.


The book is divided into three parts:

  • Part I – Kanban Through Its Values
  • Part II – Models
  • Part III – Implementation

Mike kicks off the book with an introduction to Kanban by nine values, rather than starting with the more obvious Kanban Foundational Principles (FP:s) or Kanban Core Practices (CP:s). The nine values are: Transparency, Balance, Collaboration, Customer focus, Flow, Leadership, Understanding, Agreement and Respect. Each value is presented in its own chapter, and are mapped to the FP:s and CP:s.

Kanban – Foundational Principles

  • FP1: Start with what you do know.
  • FP2: Agree to pursue evolutionary change.
  • FP3: Initially, respect current processes, roles, responsibilities, and job titles.
  • FP4: Encourage acts of leadership at every level in your organization – from individual contributor to senior management.

Kanban – Core Practices

  • CP1: Visualize.
  • CP2: Limit Work-in-Progress (WIP).
  • CP3: Manage flow.
  • CP4: Make policies explicit.
  • CP5: Implement feedback loops.
  • CP6: Improve collaboratively, evolve experimentally (using models and the scientific method).

I like this a bit more theoretical introduction as a complement to the more ”hands on”-approaches that are present in other books about Kanban.

The second part gives some taste on Models. The ones being presented are: System Thinking, Theory of Constraints (TOC), Agile, TPS (Toyota Production System) and Lean, together with some smaller models. As it’s not in scope of the book, the models are briefly introduced but with lists of further reading for each and one of them. I find this section very interesting.

Ok, Mike have really saved the best thing for last! In part III – Implementation, STATIK (Systems Thinking Approach to Introducing Kanban) is presented. STATIK consists of six steps, and they are:

  1. Understand sources of dissatisfaction.
  2. Analyze demand and capability.
  3. Model workflow.
  4. Discover classes of service.
  5. Design Kanban systems.
  6. Roll out.

The book ends going back to the values with a check-list to understand (measure) where you are in your Kanban journey.


”Kanban from the Inside” is the most recent book about Kanban (to my knowledge). It was released on September 1, 2014. If you’re into Kanban you should definitely buy this book! I wish I’ve had it (and especially the knowledge from part III) when I implemented my first Kanban system. Not convinced? Listen to this podcast where you can here Mike Burrows talk about the book (the interview is 26:45 minutes long).

P.S. Yes I got rid of the cold, the book must have had a healing effect! 🙂 D.S.


I stumbled across this book after I’ve learnt about Kanban, and coming in from the Scrum ”horizon”. This is a pretty common scenario, I think. Since Scrum is older and more spread, it has been the starting point for many development organizations when Waterfall was abandoned. Running Scrum for a while and have seen the problems with time-boxing, teams have moved to Kanban. But is there anything in between? Well, Scrumban 🙂


The structure of this book isn’t perfect, but it holds some great content! It really gave me an in-depth knowledge! Some highlights for me:

I can really recommend this book if you want to get a deeper understanding of Kanban. Hats off to Corey Ladas!

Theory of constraints

This theory (more information can be found here) basically says that any manageable system is being limited in achieving more of its goals by a very small number of constraints (bottlenecks). Or if you want to simplify and put it into other words, ”A chain is not stronger than it’s weakest link”.


The theory holds five focusing steps to address constraints:

  1. Identify the system’s constraint(s).
  2. Decide how to exploit the system’s constraint(s).
  3. Subordinate everything else to the above decision(s).
  4. Elevate the system’s constraint(s).
  5. Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system’s constraint.

How do you solve a bottleneck then?

Short term

You need to maximize utilization of the bottleneck. Let’s say that the bottleneck in your work process lies in analysis. You have one analyst in the team and he or she is sometimes forced to work up to 50% with other tasks. If you can find other persons within the organization that can handle those other tasks the flow through the work process will be doubled.

Long term

Invest to remove the bottleneck. To continue on the example above, a second analyst is hired and starts to work in the team.

What will happen then? Will you have an unlimited flow through your work process?

The answer is no, the bottleneck will only move to some other place in your work process. This is where kaizen (continuous improvements) come into place.