December 2010 Archives

Review of: "Kanban" by David Anderson

Review posted on

I was looking forward to David Anderson's book. While I wasn't enthusiastic about his previous book: Agile Management, I liked his new work and the balanced view on change he is promoting. It all made me curious.

I've not been disappointed. Kanban is a readable and balanced book which introduces the Kanban method of bringing improvement and change to organizations. It is well written (better than his previous book, IMHO) and well-argued with many cases from David's own experience and from other people in the growing Kanban community. It is and will probably stay the definitive reference for the SW Kanban method.

The book consists of four parts. The first part is a short introduction to the subject. The second part is called "benefits of Kanban," but it better describes its history (from David's perspective). The third part is more of less a description of the Kanban method itself (called "implementing Kanban") and the last part contains several background improvement theories which the reader ought to know about when implementing Kanban.

Part two is called "benefits of Kanban" and is more or less a history of how Kanban has evolved. Chapter three is what the author calls "the recipe of success" and its David's opinion on what you need to do in order to build good and predictable software. I didn't like this chapter too much as it had a "just do this and everything will be ok" tone which I also found in his previous book. Chapter 4 introduces the work David has been done at Microsoft and how he improved a team without changing the process but by managing the WIP, an interesting story. Chapter 5 described David's work at Corbis where he continued his earlier Microsoft experiences and extended (or actually created) SW Kanban.

Part three describes the different aspects of Kanban. It starts with analyzing the existing processes, visualize it and then decide the boundaries of what is inside the Kanban scope and what is considered the outside world. The "outside world" works with the Kanban team based on SLA and releases based on a steady cadence (chapter 8 and 9). From chapter 12 the book covers less known Kanban topics such as classes of service, different reporting, scaling and operational reviews. Chapter 15 is then the actual "implementing Kanban" that suggests how you can move forward and implement these ideas in practice.

Part four covers broadly said three different improvement models: Theory of Constraints, Lean, and Deming. Each chapter provides a minimum introduction into the subject and suggests the reader to use these different models for making the gradual improvements in their processes. Chapter 20, the last chapter, discusses handling obstacles that need to be resolved quickly in order to make improvements.

There were a couple of things I liked a lot about this book... and a couple of things I didn't like and disagreed with the author. One of the things I disagreed with was the hidden suggestion that the problem of building quality software has been a solved problem. I got this feeling from the way he mentions things like professional testers, CMMi as obvious and barely covers e.g. integration. The book contains very little (nothing) about the actual development of software. But, as this isn't the main topic of the book, it doesn't matter that much... The thing that did bothered me was the suggestion that all works flows sequentially and that one activity has one purpose. I got this feeling from the way e.g. analysis topics were handled or how the last chapters talked about an activity being waste or not... for example estimation. Though, I agree that estimation might/might not be waste, during the process of estimating there is often requirement discovery ongoing, which is very valuable. However the side-effect of activities wasn't covered well and, I felt, it was assume that activities have one purpose and flow sequentially. That said, it might not have been the author's intention and just my sensitivity to this.

Then, the things I liked a lot about the book. One thing I really liked is how David positioned Kanban not as a SW development method but as an incremental (evolutionary) improvement paradigm. This book definitively challenged my own assumptions about change and how change ought to happen. Kanban tries to avoid change resistance by not making the change, visualizing the current processes and then making the change obvious to the people involved. I do think it has some drawbacks, but definitively like the approach. This message isn't given at one particular point, but it is the common theme of the book and of the Kanban method. Well thought of and also... well written. Another things I liked about the book is how David constantly refers back to his own experiences. This is not a book that says "hey, I got an idea, lets try this", but its a book where the author reflects on his history (together with the reader) and uses that to explain how he got to certain conclusions. Well done.

All in all, this book will definitively be the standard reference for Kanban. I was thinking between a four and a five star rating. I decided to go with four stars for the couple of things I didn't like. Anyways, definitively recommended for anyone who wants to know more about SW Kanban.

Specialization and generalization in a team


Below is a draft of an article I've been working on. Any comments are welcome!


Specialization in Scrum is a hot topic for already many years. It pops up at every Scrum course I do. It is an important topic and is relevant for a new team in their first Sprint.

Specialization comes up when I explain to people that by the definition of Scrum, a team must be cross-functional. I also recommend the members to be 100% dedicated to the team (they are not a member of multiple teams). Most people who are new to Scrum accept it without considering the implications. Sometimes someone will ask: "But what will the QA person do at the beginning of the Sprint?"

There are a couple of assumptions behind this question. The first assumption: test can only start after development is done. This common assumption is just not true. When adopting modern practices such as Acceptance Test-Driven Development, the test starts before the development has started. The second assumptions is that a QA specialist can only do QA. I personally found that one of the greatest skills of humans is: they can learn new things! So, I don't believe this assumption to be true either.

The question can be generalized to:"What does a person with blue-specialization do when there is no blue-work". Blue could be testing, front-end development, Java, component C, database changes, writing documentation or whatever. This happens nearly always in a team using Scrum. Why? Let's look at the scenario in the picture below.

shared responsibility.jpg

In this team with the team members are specialized -- red, green, blue, purple and black. All members are dedicated to this team and have a shared responsibility for all the work on the Sprint Backlog. The Product Owner selects the work based on the customer value. If the number one priority for selecting work is customer value, then how likely would it be that that work balances out over the skills in the team? For most teams I've worked with, the likelihood is probably near 0%. Thus, in most teams (especially in larger organizations), there is a mismatch between the work and the skills of the team. It is this mismatch that causes people to say:

"Scrum needs generalists!"

This conclusion is unfortunate. If there is a mismatch between skills and requirements then that does not mean that everyone in the team needs to be able to do everything. This is a typical thinking mistake which is that the world is binary -- there are only two choices: specialist or generalist.

The truth is that specialist-in-exactly-one-subject and generalist are the extremes on the scale of specialization. There is a lot in between them! For example, I can be mainly a blue-specialist, but I can also do purple and black. I might not be as efficient as the uber-purple-specialist, but I'll manage.

Balancing specialization

When a team truly takes a shared responsibility of all the work in a sprint then that causes the need for balancing specialization. People in the team have to learn a little bit of each others specialization. This does not mean that all team members must be generalists but that members move away from the other extreme -- being a specialist in exactly one area. Team members learn multiple-specializations but probably never all.

Balancing specialization results in the following team dynamic:

  • Specialization is used when that is the fastest way to generate value.
  • There is an opportunity for team members to have multiple specializations.
  • There is an opportunity for team members to focus on their specialization as long as it generates value.
  • A mismatch between current and needed skills 'automatically' creates learning in the team

Let's look at these one at the time:

Maximize specialization when possible

If a team consist of two blue-specialists and two red-specialists and blue-work is selected, then the blue-specialist will probably do this work. Most teams realize there is value in specialization, so when we can use people's specialized knowledge then they do so. Also team members actively become specialist on particular areas because that increases the productivity of the team.

Opportunity for multiple specialization

"I've been a blue-specialist for many years. The next Sprint some blue and some red work is selected. My team members are able to take the blue work so that I can learn a new red-specialization." Many people want to actively learn new areas. It keeps the work interesting and their knowledge fresh. In a team balancing specialization the opportunity to expand my specialization should exist.

Opportunity to focus on one specialization

"I've been diving in blue for the last Sprints. I've always wanted to be a blue-specialist. So therefore, the next Sprints, as long as there is blue work, I would like to do that." People inside a team shouldn't be forced to learn a new specialization. As long as their knowledge creates value for the customer, they can keep focusing on their specialization. The team will need to deal with the situation when there is absolutely no work in a specialist area -- usually by breaking the specialization.

Automatic learning

If the team consists of mainly blue-specialists and the next Sprint has mainly purple-requirements, the team has to break their specialization and learn purple. If the next Sprint is mainly green requirements, they will need to break the specialization again and learn green. The more the skills area in the requirements change the more generalized the team becomes. If the skills area in the requirements don't change much then the team becomes more specialized.

Impact on organization

The balancing specialization happened in every Scrum team I've worked with. It often causes conflict in the early Sprints where the fresh team members scream "I've been blue for years! I won't do purple!" The team will need to resolve this conflict by learning how to work as a team. A good ScrumMaster facilitates this conflict in the team so they resolve it.

The structures and policies in many organizations make balancing specialization more difficult. For example, if I'm the blue-specialist and on a blue-career-path and reporting to a blue-functional-manager, then would I want to learn purple? Probably not as this would be harmful for my status and my career. Similarly, if I get a performance target to become blue-er, then the breaking of specialization area won't happen.

Another common obstacle is when organization "manage around the specialization bottleneck" by partially allocating people to multiple teams. This makes it even worst as there will be no incentive whatsoever to break the specialization bottlenecks in organizations.

ScrumMasters need to identify these organizational dynamics and try to remove them. This is hard work as it requires to change the organization. When the organizational obstacles are broken the balancing of specialization will happen 'automatically' in the teams.

An interesting closing observation is that the same team-dynamics is true on organizational level: the needed skills always mismatch the required skills. This means that organizations that optimize their specialized human resources will never deliver based on customer value.

Refactoring Manifesto

| 1 Comment
Last weeks, I've been able to spend time with my good friend Lasse Koskela. He was in Singapore for three weeks to work together on a new "Scrum Developer" training. During the creation of the training, we came across the "repair manifesto" which inspired us to device the "refactoring manifesto" from it. It was an enormous amount of fun and turned out to be pretty good.

You can find the refactoring manifesto over here. Please sign it :)

About this Archive

This page is an archive of entries from December 2010 listed from newest to oldest.

September 2010 is the previous archive.

January 2011 is the next archive.

Find recent content on the main index or look in the archives to find all content.