I'm unable to post these roundups everyday so they aren't always as timely as would be ideal. A couple of these blog posts appeared within two hours of me posting the last roundup on June 30th.

Karl Scotland stirred up a lot of debate with his Fifth Primary Practice of Kanban that a goal is to reduce the number of kanban tokens and reduce the overall WIP and cycle time as a result. I agree with Karl though others have stimulated a healthy debate with some dissenting opinions.

David Draper looks at Managing WIP with Scrum and manages to get to pretty much where I'd got to when I published MSF for CMMI Process Improvement in 2006. He's right adding Lean techniques like cumulative flow diagrams and managing the WIP will make Scrum better. And in my opinion, will lead people to go the whole way and adopt a Kanban style approach.

Luminis switched from Scrum to Kanban for a Week at the end of their product cycle as budget ran out and Scrum sprints no longer made sense for the tail end of the project. Sounds like the transition went well. They did the right thing - kept all the engineering practices the same - dismantled the Scrum Sprint bureaucracy and switched to single kanban prioritization scheme and kept the product in a shippable state awaiting the final deadline.

Check out the arrival of Simple-Kanban - another one of the new tools. The guy behind this Stephan Schmidt has been highly critical of me from Scrum-bashing. He seems to struggle with the idea of discussing Scrum's appropriateness. There are too many people with a vested interest in Scrum being appropriate even when it's not. The Scrum philosophy seems to be rooted in the idea, Scrum works, so change your context and adapt to Scrum. That's fine! No one disputes that Scrum works. What many of us dispute is how easy it is to change a context. Kanban is rooted in the opposite philosophy. That changing a context is very difficult and it is easier to adapt incrementally. The mechanism for kickstarting that gradual change is to limit WIP and institute a pull system. The method for taking this approach to change has come to be known as Kanban (with a capital "K"). Apparently, saying this is Scrum-bashing! :-S

Kelly at All About Agile blog seems to be having success with Scrum but reports that Sprint Planning is onerous at times. A fascination with Kanban is building, they the explanation of cycle time left me baffled, Kanban Applied to Software Development: from Agile to Lean. The conclusion that Kanban is easier to adopt on "business as usual" maintenance is clearly correct. When you switch to a full blown Kanban approach on major projects you have to change the whole approach to governance. The traditional project and portfolio paradigm requires estimates and costs to drive plans, commitments and business cases. Kanban takes a whole new approach to risk using option theory. This is a relatively new area and one I'll be presenting on at Agile 2009.

Sylvain St. Germain seems to have received the Kanban and Collaboration message I've been promoting more and more recently and it seems to be resonating with him. Good! We need more people that see this sociological benefit of Kanban and recognize the softer people-centric benefits to what seems like a purely mechanical approach to process. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

For some time now (at least since May 24th) Alistair Cockburn has been expressing a dissenting view about Kanban and the value of imposing WIP limits. I'd like to quote a number of his tweets on the topic. These are quotes from May 24th to 28th. You can follow Alistair on Twitter @totheralistair.

in reply to @ponderings Agreed - might call w limits "Kanban for Kindergardners" vs w/o limits "Kanban for Grownups". Why not treat them as adults?

in reply to @bellware What I'm saying is that WIP limits enforce (read: replace thinking) what simply observing would give you, but triggers stoppages.

continuing... @bellware Indeed - and you don't need to back up the assembly line to get that. WIP limits are muda.

in reply to @bellware @davengeo WIP limits are training wheels --- I say this in part to provoke thinking, partly cuz it may be true

and again @bellware I suggest you try removing WIP limits and use your eyes and brain instead of backed-up Q to notice bottlenecks

While Alistair's dissenting voice is welcomed and I believe healthy as a challenge to the emerging Kanban community, these tweets can't go unanswered. Alistair carries a considerable stature in the industry and snappy soundbites such as these tend to get repeated without depth of understanding.

I like to give Alistair the credit for being the first person to observe that Agile Software Development is a Collaborative (or Cooperative) Game. A game in which the outcome isn't zero sum and in which the players muct cooperate rather than compete to maximize the outcome. It's interesting then that Alistair doesn't appear to have recognized that introducing WIP limits is introducing a new rule (or set of rules) to that collaborative game.

What we've come to recognize is that the introduction of WIP limits forces conversations to happen that were not happening before, and the derivative mechanisms resulting from WIP limits such as prioritization meetings and selection mechanisms, impediment escalation and a focus on flow to both shorten cycle time and improve predictability encourage collaboration and cultural change for the better, that was not present even with first generation Agile methods.

Alistair suggests that WIP limits are waste. The facts are that we started with no limits. Then we introduced the concept of managing WIP and controling it so it doesn't spiral to infinity. Several people who tried this seriously in the mid-naughties (circa 2004-2006) soon realized that managing WIP helps and if managing it helps wouldn't limiting it be both simpler and create greater freedom. [For example, Sterling Mortensen at HP.] Limiting WIP eliminates the coordination costs (management overhead) or "waste" of having to manage WIP. Limiting WIP enabled work-in-progress to become self-organizing. So WIP limits don't add waste they remove waste. They free managers to worry about more value-added activities.

Alistair also suggests that WIP limits are for children while adults can do just fine without them. Again, this is in denial of the reality and history. Traditionally, we haven't limited WIP. In fact, the concept of WIP wasn't even in the paradigm of project management or software development until this decade. So plenty of adults have been struggling with managing WIP without limits for a long time. [In the HP case study they discovered they had almost 5 years worth of WIP before they started to manage it.] Alistair suggests that we don't need WIP limits to see bottlenecks or other stoppages (impediments, blocking issues). And while this is true, we need to look at the facts and how well we as an Agile Software Development community are doing with that.

The reality is that most Agile Project Management tools struggle to show blocked work and do not treat blocking issues as first class objects. There are no features for escalation and no features for reporting quantity of work blocked, time blocked, who the issue is assigned to or what they are doing about it. The tools vendors are only just catching up with this kind of functionality. There has been little emphasis on prioritizing the removal of blocking issues or resolving stoppages. Why? Because before Kanban they weren't treated as stoppages. They were treated as work that could be put aside while something else was started. Adding WIP limits has helped the adults change their focus onto issue management and resolution to keep things flowing, rather than keeping busy. I blogged at great length on this topic last month Managing WIP isn't the Same as Limiting WIP Part 1.

What about bottlenecks? Well the introduction of cumulative flow diagrams (later called burn up charts by some of the Scrum community, and also known as finger charts) in 2002 was slow to catch on. Some tools vendors did provide limited support for CFDs but guidance on how to read them and use them was limited pretty much to anything I published until very recently. One developer at a major Agile project management tool vendor only recently tweeted that his product was finally "all pimped out with a CFD." So what about simply walking the floor and asking "where is the bottleneck?" Well generally that wasn't happening either. If teams were managing bottlenecks then lots of people in our profession would have slack time because they aren't working in the bottleneck station. As a result the 40 hour week or sustainable pace would be commonplace among Agile teams and across our industry, but it isn't! The guidance on Lean and flow and how to see bottlenecks with CFDs and what to do about them with TOC has been widely available since 2003. The reality is that it hasn't been happening. When we introduce WIP limits and adjust them correctly, bottlenecks manifest themselves and the effects are felt immediately. The organization recognizes the bottleneck for its true impact and something gets done about it. This behavior is becoming much more commonplace with Kanban.

WIP limits are for adults! They are for adults that care about sustainable pace, flow, throughput, and process improvement. They are for adults that care about increased collaboration and cooperation and a higher trust more empowered workforce and culture in the workplace. WIP limits are surprisingly empowering! It's interesting that a constraint can be something that makes you free! WIP limits are a new rule in the collaborative game that is Agile Software Development. Its a rule that empowers people, treats them with respect, increases social capital and collaboration in the workplace and focuses organizations on improving their process for long term benefit. WIP limits enable "stop the line." They enable the Lean concept of the pursuit of perfection by encouraging a focus on process improvement.

When asking whether WIP limits are for beginners or experts ask those who are actually using the technique whether they could imagine going back to merely managing WIP or worse not bothering at all? In my kindergarten example from yesterday, could you imagine the chaos that would be introduced by removing the WIP limits? Even if it wasn't chaos how much wasted time would be spent negotiating and agreeing acceptable limits of children at each workstation? How much effort would be wasted resolving disputes with arbitration?

WIP Limits are a new rule in the collaborative game of Agile Software Development. Adults use them to eliminate waste! Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management, Alistair+Cockburn

My younger daughter's pre-school uses a kanban system. I'd been staring at it for months without realizing it was a kanban system and after I did I was troubled by the fact that it wasn't a pull system. So I had to think about it a bit.

First an explanation

The board is laid out into a series of sections with slots in purple for a station (or type) and a fixed number of slots in red for children. The concept is simple. Different types of activities have different limits on the ideal number of children should participate. There are many more activities possible than available on any one day. So the teacher wants to be able to assign activities to slots on the board - and then physically lay out the activity within the room - for example the train table or the doll house. The children (typically 3 to 5 years of age) are empowered with "Free Choice" and can choose the activity they want to participate in. They are also free to move from one activity to another. The cards with their picture are kept in an index card case. When arriving at school at 9am they take their picture out of the case and decide which activity they'd like to start with. They stick their picture into an open red slot using a velcro fastener. If there is no open slot free on the activity they want, they have to choose something else. When they decide to change activities they return to the board and move their picture to the new activity and place it in an open slot. At any time, they can walk past the board to see if a slot has become free. At the end of the day, they move their pictures to the Going Home buffer off the board, and later the teacher returns the photos to the index card box.

It's not a pull system

While this is clearly a kanban system, as it both limits WIP and uses cards to signal availability, it is not a pull system. This troubled me until I realized that goal is not flow. There is no concept of flowing children from one activity to another and no need for each child to visit each station. There is no flow, so there is no need for pull.

So why limit WIP?

Limiting WIP introduces a rule (or constraint) and the system to enforce and enable it, the kanban system, introduces concepts that 3 year olds have to learn. It introduces some overhead for them to enjoy pre-school. So why do it? Well the rules of kanban enhance collaboration amongst the children. The experience of playing at any one station is enhanced because only the appropriate number of children are at any one station at a time. No station is ever over-crowded.

The kanban system also empowers the children to have "Free Choice" even though they are only 3 or 4 years old. The rules of their kanban system mean that the teacher does not need to manage the number of children at each station, free'ing the manager (err, teacher) to do other things, and the rules insure a collaborative environment and avoid disputes, negotiatiation, arbitration and reconcilliation that would be needed otherwise. The kanban system enhances the experience for the children, shows them greater respect as individuals, empowers them, while giving back the teacher more time to perform value-added activities rather than waste time resolving disputes over resources.

Kanban embraces and enables the People half of the Toyota Way

For me this example truly highlights how kanban embraces and enables the softer people aspects of the Toyota Way and Lean. Kanban respects people by empowering them and free'ing them from managerial supervision. It respects managers by giving them more time to perform value-added activities in this case child development. And kanban systems enable teamwork and collaboration by puting rules and constraints around what is acceptable behavior.

Recently Alistair Cockburn tweeted that Kanban with WIP limits was for Kindergarteners while Kanban without WIP limits was for adults! I'll blog more about that thought another time. Meanwhile, isn't it interesting just how much we can learn from kindergarteners and what they can teach us about empowerment and collaboration in the workplace? Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

It's been a week since I posted one of these summaries. I've been busy on other stuff and haven't had much time for blogging. Meanwhile, Kanban is generating on average 2 tweets per hour on Twitter and there has been some active new blogging and meetings in the past week. Agile Denver has a good crowd (30+) for Brad Swanson and Frank Vega presenting their experience moving to Kanban from Scrum and why Kanban worked better for his team. Tonight the Limited WIP Society London chapter will be meeting at XtC. And...

Getting Started with Kanban

David Joyce had over 100 people at the BBC last week for his Kanban presentation in London. Skillsmatter have made the video available. I'm told that David used a lot of material from me and Karl Scotland and I'm sure this is a very comprehensive introduction on how to get started with Kanban. The BBC is one of the largest adopters of Kanban and has taken a lead in the media industry which is generally an early adopter of the technique. It seems that media schedules don't fit nicely into time-boxed iterations and first generation Agile approaches are at best a forced fit. Kanban seems to be gaining traction because it decouples prioritization, cycle time and delivery and allows them to fit naturally into media cycles.

Kanban and People

Last week Henrik Kniberg posted this education cartoon, One Day In Kanban Land. This is a stop frame of part of his animated story from his Kanban versus Scrum presentation that you can see at QCon in San Francisco this coming November.

The Toyota Half Way is a nice piece from Bob Emiliani explaining that TPS has two halves - the continuous improvement half made up of Challenge, Kaizen and Genchi Gembutsu and the Respect for People half made up of Respect and Teamwork.

One or two folks on Twitter jumped on this and suggested that Kanban belongs the in the first half and that Kanban doesn't address the second half, so it is only a half way solution to the Toyota Way applied in software engineering. This couldn't be further from the truth. It seems many folks just see the mechanism - the cards, the WIP limits, the signals, and don't listen to the stories and the effects and the outcomes, or for that matter the motivations. It makes me believe that many people don't actually take the time to watch the presentations before they pass comments.

One of the original motivations for Kanban (in software development) was to limit WIP to enable a truly sustainable pace and to eliminate variability from the day-to-day lives of the workers. This truly shows respect for the knowledge worker. Kanban and its policies empower workers. What is more respectful than empowerment? Kanban encourages teamwork across the whole value stream. It changes the culture of an organization and the result is a much more collaborative workforce. Henrik's One Day in Kanban Land cartoon demonstrates this admirably.

So it's entirely false to suggest that Kanban only delivers the Toyota Half Way. Perhaps those saying this need to reflect that 'respect' does not equal 'politeness' and 'teamwork' need not only be among defined teams. 'Respect' in this context means trust, empower, and do not punish failure rather seek to learn, understand and adjust. 'Teamwork' in this context means collaboration at all levels and along the full value stream.

...+++...

And finally, I missed this earlier post from June 10th on the costs of iterations with Kanban. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

My latest Perspectives article for Borland has been published. It's not the as advertised look at Agile Maturity and Adoption. Those two articles will come later. They seem to be bogged down in the editing process while I try to hit the moving target that is Agile + Maturity Models. Everyone and his auntie seems to want one all of a sudden.

Meanwhile, I thought I'd riff off Stephen Palmer's excellent blog observing that you need to be committed (a Pig) in order to drive cultural change. I actually had this article in the can before Steve posted his, so we changed the order of my Perspectives to keep the them of Pigs rather than Chickens flowing.

Where Everyone's a Pig - the Value of Cross Functional Collaboration in Successful Agile Transition

If anyone wanted a definitive definition of how Kanban differentiates from Scrum then in my opinion this is it! Technorati tag: David+Anderson, Agile+Transition, Agile, Lean, Kanban, Software+Engineering, Project+Management, Change+Management, ShiftAltCtrl, Leadership, Organizational+Culture

Jon Miller has started using his own personal kanban system. Read his adventures of the first day and note how kaizen events to make improvement kicked in almost immediately. Note also that he doesn't feel the need to create a WIP limit for his "delegated to" column simply because the constraint of the size of the board is well below his capacity constraint. He's also introduced some classes of service and despite all these changes he's managing to keep it simple. I hope Jon keeps up this diary of introducing Kanban to his personal business. His incredibly instructional for us all. Thanks for sharing Jon.

Karl Scotland wrote a Kanban sidebar for a forthcoming book by Rachel Davies and Liz Sedley. He's recently revised it during the final review process before printing. Here is take 2 on his Kanban sidebar.

And Alan Barber shares his Kanban board with us, "added a few tasks and completed one."

Meanwhile Rick Simmons reports via Twitter that his team made 3 or 4 revisions to their Kanban system on the 1st day. This is exactly the sort of behavior I'd expect if a team has a culture that already lends itself to kaizen. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

In today's roundup, I'm covering some more general Lean stuff that is flying under the more specific flag of Kanban. It's amazing how people want to be associated with success.

First off, who is this making Kanban t-shirts all of a sudden? Personally, I'll be waiting for my official Limited WIP Society shirt! Designing these is on my backlog, but I haven't pulled that job into my personal WIP limit yet ;-)

Next up, super post from Rob Bowley detailing his team's current practices. A lot of Lean going on here with cumulative flow diagrams, cycle time metrics and so forth. Excellent stuff. One or two tweets on this referred to it as Kanban but Rob is really quite clear in his post. He's doing Lean stuff and doesn't even call his card wall a Kanban board.

Matt Wynne's Kanban State of Mind is worth revisiting.

Kanban in Portugal anyone?

And another example of someone trying to adopt Kanban for their personal life. Not sure if this one has a WIP limit and is a pull system or not.

I'm not entirely sure what Si Alhir is on about with this comparison of Leanness, Agility, and Competitiveness. If someone can understand this chart and explain it to me, please leave a comment. Thanks.

I've mentioned it before on Kanban Roundup but Kallokian blog's Defining Kanban has provoked an interesting discussion thread about kanban versus Critical Chain and early versus late start. I've noticed that when talking to folks with a manufacturing and industrial engineering background about our use of Kanban (or Drum-Buffer-Rope earlier on) that they simply can't get their heads around it. They have a mindset that project management is for knowledge work problems and they have their pet solutions to variability and project dependency graphs such as Critical Chain or GERT (Gantt meets PERT and they had a baby.)

The whole issue of early versus late start is mute with Kanban (using a capital "K" now) because of the prioritization scheme and the use of classes of service. There are no estimates - unless the class of service demands it and a specifically "late start" prioritization scheme is adopted, as I have documented with the Fixed Delivery Date class of service at Corbis (and elsewhere) - so you can't early or late start against an estimate. There is no concept of a dependency graph of the order of work because selection of work is delayed until it is prioritized into the input queue. This looks awfully similar to "late start" to me, but what it really is, is a very similar process to TOC Buffer Management and self-prioritization in advanced DBR solutions.

The problem with the folks debating the project management solutions is that they can't break their minds out of the project management dependency graph paradigm and think of software development as a flow problem. They want to wrap everything up in a project with a defined release date and by doing so, wrap all the activities within the bundle into a homogenuous blob from a risk perspective. There is no concept of "cost of delay" or "loss function" at the individual work item level, only at the project level. Kanban frees us from these man made imaginary constraints and enables us to treat the work independently from a risk perspective and consider the cost of delay (or potential loss) for each item indvidually. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

Scrumban produces 2x productivity gain over Scrum

Today we have an article describing a Scrum-Kanban hybrid & transition (Scrumban) from Charles Suscheck in Dr. Dobbs Journal, Experiences with Kanban. We've now had Kanban articles in both Dr. Dobb's and Better Software so I guess it must be official now ;-)

The most significant thing about Charles' case study is that it appears introducing Kanban produced a greater than 2x productivity improvement over the throughput rate (velocity) being achieved with Scrum on its own. It seems they did notice a significant reduction in waste with Kanban. Charles concludes that, "Kanban seems like a logical next evolutionary step to Scrum." However, his article is thoughtful and balanced and he talks a lot about context.

This team had, "After 18 months, [...] reached a high level of agile maturity, even incorporating numerous lean principles." And they had refined their analysis technique so that they produced small stories (1 to 3 days of work) and there was a small variability in the size of stories. Their environment still had a lot of uncertainty over priority and the delayed commitment on developing stories with Kanban was a huge win for them. Read the article carefully. Take time to understand the context and you may discover between the lines how Kanban was a really good choice and where that >2x productivity gain (probably) came from.

Kanban boards

Xavier Quesada Allue posted pictures of some kanban boards he designed for a friends' business unit. It's worth noting there are no WIP limits in these examples and hence at best only a loose pull system in operation. But the board design and the use of sticky notes and different colors is worth studying.

Nothingness

Derick Bailey posts a slightly discenting view that kanban systems don't need to be pull systems. They can simply be signalling systems. Look for next personal blog post on Kanban to read my thoughts on this. Then he goes on to provide us with a very nice tutorial complete with pictures explaining how to make a pull system work and emphasizes (as I have been for 18 months) that a task card is not a kanban card. In his example they use sticky clips and an empty one was a signal to pull something. It is essentially formalizing the "slot" concept that I first talked about with the XIT case study in 2005. I love this idea. Sticky clips rock! What a great way to communicate the WIP limit! An empty sticky clip is the "nothing" that I referred to in the section heading.

Kanban and kanban

Derick sums up with a discussion of how Kanban (capital "K") has emerged as the name for a methodology that evolved from the use of (virtual) kanban (small "k"). While some folks are getting all hung up about this, Derek seems to have a similar philosophy to mine - it is what it is! The market decided. KSSE (Kanban System for Software Engineering) or a Virtual Kanban System for Software Development (as I first called it 4 years ago) were just too long. The market wanted an easy handle and hence Kanban became a brand. Vive le Kanban!

Is Kanban only for SDLCs?

Joshua Milane posted his thoughts on Kanban SDLC vs PLC at his MITechnology blog. Josh likes the idea of Kanban as a wrapper for a software development lifecycle. He isn't a big fan of the push for Agile Maturity Models. Neither am I but that's a discussion for another day. He loves the simplicity of Kanban and how it encourages better learining by doing.

Kanban Demonstrated

YouTube video of kanban in action at the Sailboat Company of Naples, Florida. [Not a software example]

How to Pronounce Kanban

YouTube Video with David Laribee of VersionOne

Personal Kanban System

Jon Miller of Gemba Panta Rei has decided to adopt the Agile style Kanban technique for his own personal work. He's been trying it out and shared photos and experience. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

Today's roundup of all things Kanban includes a few articles from a month or two ago that I missed, but first I want to start with something brand new posted today.

Mike Jones at About Agility blog, has been asking "What Can We Learn from Kanban?" He's only been researching and his main knowledge seems to come from Jeff Patton's excellent introductory article, Kanban Development Oversimplified. It's worth noting the use of the word "oversimplified" in Jeff's title. He's implying it isn't the full story. So Mike goes on to re-iterate a couple of concerns others have expressed. This is perhaps because he read an oversimplified article that didn't address these issues.

(1) Kanban's lack of iterations is bad. He states that Kanban doesn't allow an iterative approach which is wrong. You can readily iterate on design and implementation with Kanban. He then goes on to imply that Kanban doesn't allow you to sync at regular intervals with the business which is just plain wrong. He clearly hasn't understood the concept of the prioritization cadence and the release cadence. You get all the benefit of time-boxed iterations with none of the drawbacks.

(2) No commitment to deliver. This is a subtle point in Kanban. Kanban strikes a different kind of bargain with the business. There is a commitment to deliver and deliver regularly. However, classes of service are used to control the rules around delivery of specific items and the release commitment is late binding - typically 3 to 5 days prior to a release, no earlier. Kanban also includes a commitment to continuous improvement targeting shorter cycle times, better due date performance and lower variability generally.

(3) Writing Larger Stories. This one is interesting. The main theme of Kanban is "start with what you do now" and don't change your process, just add WIP limits, re-arrange the prioritization and release coordination, visualize and pull. However, some element of the Kanban community, mostly from London, introduced the idea of an MMF (the reference is usually the Denne & Cleland Huang book, Software By Numbers) but the original Kanban introduction was by Chris Matts then at RBS in London. They using the term MMF but not using the Denne-Cleland Huang definition. However, I never adopted the technique and MMF will not appear in the Kanban book. Nevertheless Mike's concern is genuine but again misguided. MMF is not about writing larger stories but recognizing groups of stories that represent a minimum level of delivery to be meaningful from a marketing or delivery functionality perspective.

Next...

Overnight Rob Hathaway enabled the Discussion Forums feature at Limited WIP Society. Practitioner to Practitioner discussion is being moved away from Kanbandev Yahoo! group to this new community hub. The Kanbandev group had become unusable as the signal to noise ratio had reach about 1:10. If you have questions about Kanban and would like a genuinely practicing experienced Kanban community person to respond, do visit and join.

Silver Stripe Blog asks "What does a Work In Progress Limit Mean?" And goes on to demonstrate how to do it with the Silver Catalyst tool. Yet another Kanban tool coming to market. I think that makes 7 now but maybe I've lost count.

Now for some older stuff...

Margaret Rouse has this piece on Kanban - a way to visualize bottlenecks in your software development projects. There really isn't much Kanban content in Margaret's observations. She could have written this article in 2003 based on my Agile Management book. The only thing the book didn't include was the card wall visualization technique.

Pascal Van Cawenberghe asks Why Estimate? and examines whether estimation is required due to a lack of trust in the organization. His conclusion is that high levels of trust are necessary but not sufficient to eliminate estimation. I have to agree with him. There are still some types of work that need estimation. That's why we design a class of service around them and do estimates, but only for items in this class of service. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

Incredibly creative piece of writing by Jon Miller of Gemba Panta Rei - The Amazing Adventures of Kanban. Be sure to read it all the way to the end. I doff my cap to Mr. Miller for getting this out today and including work that I published less than 24 hours ago.

Thanks Jon for the link to Limited WIP Society. We owe you one!

Gemba Panta Rei is a great web site - if a little heavy on the Japanese words for my personal taste. Bookmark it! Add it to your RSS feed. Add it to your blog roll! Technorati tag: Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management, TPS, Toyota, Manufacturing, Industrial+Engineering

My Lean compadre Hal Macomber, one the leading experts in Lean applied to construction project management and also a speaker at the forthcoming UK Lean Conference [sign up now to guarantee your place at the RSA in September] has beaten me to the punch reviewing Ric Merrifield's new book Re-th!nk. Hal's written a really insightful, thoughtful well balanced review over at Reforming Project Management, go read it now!

The book's subtitle "a business manifesto for cutting costs and boosting innovation" talks to the times we live in today. However, the book has been about a decade in the making and about 2 years in the writing. Behind the book is an analysis methodology that Microsoft brands as Motion and Dennis Stevens of Synaptus (one of Ric's collaborators on the early work in the method) calls Capabilities Analysis.

The idea is simple! Companies get hung up on how they do things and try to optimize those while they ought to be asking what they do! For example, if someone in an office is sending a fax then we observe the how - sending a fax - and we may try to optimize that - more functions such as delayed send, automatic retry - or switch to a new how such as email. But if we asked the person sending a fax what they were doing they might tell us that the were confirming an order. If we think more about the what - confirming an order - then this can lead to useful insight, cost savings and innovative thinking.

Capabilities Analysis allows firms to analyze what they do in different divisions and to identify duplication. Instant cost saving! The results on this are astounding. Some firms have saved tens of millions with this one step alone. Meanwhile, the remaining capabilities can be analyzed with questions in a survey of stakeholders and classified into brackets such as stragetic/non-strategic, work class leader/competent/not competent and so forth. Combinations of these can then be used to make recommendations.

For example, if something is not strategic and we are not good at it then we should outsource it and buy the service instead. If we are good or world class at something but it is not strategic then we should spin it out and sell that service to our competitors. This will realize more shareholder value. If something is strategic but we are not good at it then we should invest in it.

Capabilities Analysis is a service that David J. Anderson & Associates is offering to our clients primarily through Dennis Stevens working as an associate.

I should mention that both Dennis and Ric are friends of mine. I've known Ric since I worked at Microsoft. Their third collaborator and co-author their 2008 Harvard Business Review article: The Next Revolution in Productivity, Jack Calhoun was an early fan of my book  Agile Management for Software Engineering and used to hand out copies to Microsoft executives. Pity none of them actually read it!

Microsoft use Motion as a method to analyze businesses and make strategic recommendations for investment in Service Oriented Architecture. They teach SOA by showing businesses how to re-engineer into a plug-n-play set of services. This makes SOA easier to implement and more aligned with the business strategy. In my observation Capabilities Analysis is powerful on its own but when tied to a SOA strategy it becomes the Next Revolution in IT Strategy!

Ric's book is very readable. It's full of stories of businesses he's observed that have understood their what's and haven't been attached to their how's. It's an enjoyable read and/but very light on the theory of Capabilities Analysis. So if you like the message and think Capabilities Analysis is something that would benefit your business contact me and Dennis and I will be in touch. Technorati tag: Ric+Merrifield, Re-th!nk, Dennis+Stevens, Jack+Calhoun, Harvard+Business+Review, HBR, Management, Business

I've been making some web assets for you to use on your own sites to link to the Limited WIP Society site. If you are an advocate of Lean and a practitioner of Kanban and you'd like to show your affinity or affiliation with the community then please put one of these on your site and drive traffic to the Kanban community hub at limitedwipsociety.org.

If you want to use these assets on your site just paste the HTML code provided straight into your web source code or content management system.

Source: <a href="http://www.limitedwipsociety.org/"><img alt="Yes We Kanban" src="http://www.agilemanagement.net/ltdwip/yeswekanban.png" border="0" /></a>

Source: <a href="http://www.limitedwipsociety.org/"><img alt="Yes We Kanban" src="http://www.agilemanagement.net/ltdwip/yeswekanbansm.png" border="0" /></a> 

Source: <a href="http://www.limitedwipsociety.org/"><img alt="Vote Ltd WIP" src="http://www.agilemanagement.net/ltdwip/voteltdwip.png" border="0" /></a> 

Source: <a href="http://www.limitedwipsociety.org/"><img alt="Vote Ltd WIP" src="http://www.agilemanagement.net/ltdwip/voteltdwipsm.png" border="0" /></a> 

Source: <a href="http://www.limitedwipsociety.org/"><img alt="Advocate Ltd WIP" src="http://www.agilemanagement.net/ltdwip/ltdadvocate.png" border="0" /></a> 

Source: <a href="http://www.limitedwipsociety.org/"><img alt="Advocate Ltd WIP" src="http://www.agilemanagement.net/ltdwip/ltdadvocatesm.png" border="0" /></a>

More alternative assets to come soon. And yes, the character in the Yes We Kanban is Taiichi Ohno ;-) Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

It took 6 months for this to come to my attention. Perhaps because the author chose to call the article Finger Charts rather than using the term Cumulative Flow Chart.

I love so much about this story. I love the example diagrams. I love the explanations showing how to read the diagrams and I love the rest of the text explaining how to identify bottlenecks. Akshay correctly identifies the two types of bottleneck: Capacity Constrained; and Non-instant Availability. He has an example of non-instant availability in his BA/QA group.

These are great teaching examples.This first one shows the non-instant availability bottleneck.

While this second one demonstrates how to read the work-in-progress and relates it to cycle time. For me this is at the root of Lean software engineering. Without cumulative flow diagrams, you cannot readily see flow in the work and you cannot achieve a true Lean implementation.

Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Software+Engineering, Project+Management

A number of people are playing up the angle that there is a religious war between Scrum and Kanban or between XP and Kanban. It's interesting that none of these people are actually folks from the Kanban community.

I think one of the issues was Henrik Kniberg (a non-native speaker) chose to use the term "versus" with his Kanban vs Scrum review when what he sought to provide was comparison between the approaches. Ron Jeffries seems to be annoyed that people want a handle with which to pick up a set of practices as a methodology. Woo! Hoo! Welcome to the party Ron! I think I've been saying that since this blog began in 2003. Unfortunately the idea that you educate people ona set of principles and then ask them to think for themselves in their specific situation and make their own choices and solve their own problems. Sounds like way too much hard work. Picking up a methodology with a handle and implementing it is much easier. The Kanban community didn't call Kanban, "Kanban", the market did. In my opinion you'll struggle to find a less dogmatic set of people anywhere in the Agile community than you'll find on the Kanban Yahoo! group.

Karl Scotland has replied to Ron (via his blog, How is Kanban Different from Other Approaches?) with another comparison piece that looks at philosophy rather than Henrik's more practice based review.

Meanwhile at the more pragmatic end of the community Anna Forss talks about she is integrating a Scrum team and a Kanban team within the same program.

Luminis have published how they are using a Kanban system for processing the blocking issues at the daily standup within their Agile development approach. They felt that their daily standup was getting boring and routine. By introducing a board for processing the queue of issues they have brought more focus back to the standup. I'm not sure I like the introduction of the term "issue driven" and I won't be encouraging that. I don't feel it is the issues (or any form of work) that drive a kanban pull system.

Have you blogged about Kanban in the last few days? If so drop me an email or leave a comment. I will cover it in the next update. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management