Monday, March 30, 2009

Voting & Democracy! Are they like Kanban & Lean?

In the last few days, a quote from the new book by Craig Larman and Bas Vodde, Scaling Lean & Agile Development, has been getting some Re-tweet love on the Twitterverse since Jason Yip gave it visibility…

“Reducing lean thinking to kanban, queue management and other tools is like reducing a working democracy to voting.” Craig Larman, Bas Vodde

Larman and Vodde actually dedicated 14 pages of their new book to criticising one blog post on this site, Kanban in Action. It seems they find Kanban somewhat threatening. Their opinion was widely discussed on the Kanban Yahoo! group shortly after publication.

What worried me most about the quote Jason chose to highlight was the quality and stature of the folks re-tweeting. Sure it’s a snappy sound bite and seems very clever at first glance but I worry those reading it fail to think deeply about it and miss a very important point. Jason followed up with this reply to me on Twitter…

@agilemanager Their comment is obviously targeted but if we imagine ourselves outside that context, it’s quite a useful universal comment.

It seems he sees real value in the comparison. I beg to differ and 140 characters isn’t enough to express my opinion fully, so this blog post is required.

Comparing Kanban to Lean as a tool like voting is to democracy misses a very important point. While voting is clearly an enabling technology for democracy, kanban pull systems are more than a mere tool for Lean. What we’ve discovered from actually doing Kanban (something neither Larman nor Vodde had tried before writing 14 pages of criticism) is that Kanban enables all aspects of Lean in ways that are not obvious and seem counter-intuitive. You have to be doing it to discover this.

The combination of a WIP limited pull system, and the transparency and visual control in Kanban produce a focus on external/special/assignable cause variation (aka “impediments” in Agile-speak) and encourage the team to “stop-the-line” and fix impediments rather than going around them, shelving the work and continuing with something else, as is the default behavior in non-WIP limited agile methods. Kanban also exposes bottlenecks, waste and common/chance cause variation that is natural to the method of software engineering and analysis being used. Queue management in Kanban is a necessary side-effect of that variation and visibility on to queues shows the waste inherent in the variability. Hence, Kanban provides a mechanism to enable causal analysis and resolution and continuous improvement through management of bottlenecks, waste and variability. It provides an objective, quantitative management system for systemic improvement.

Other methods that merely provide a mechanism for reflection and adaption do not provide the objective, focused, quantitative framework with specific attention to bottlenecks, waste and natural variability. As such, they are less mature from a capability maturity model perspective. The quantitative, objective, structured nature of Kanban has allowed us to mature teams and improve performance very rapidly. It’s more than just a tool. Kanban enhances Lean Thinking. When you add a WIP-limited pull system and a transparent visual control to your process you enable all aspects of Lean in a highly mature fashion. Kanban is Lean Development++ not Lean Development—. This is counter-inuitive. You need to try it to experience the true benefit of Kanban. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

Friday, March 20, 2009

Kanban & Planning and Estimation

And while we’re on the topic of Kanban controversy against Agile practice stalwarts (Kanban & Retrospectives), let’s revisit Kanban & Planning and Estimation ...

I’ve reported in the past how some Kanban teams eliminate estimation altogether and reduce planning to a very simple prioritization scheme to re-fill slots in the input queue. It’s worth discussing whether or not these are prescriptive foundational elements of Kanban or whether they are in fact choices made in specific situations?

First, let’s look at estimation. Kanban teams often eliminate estimation except when they don’t! What Kanban exposed was the fact that not all requirements or requests are equal from a risk perspective. Some requests carry a significant risk from late delivery due to the nature of their cost of delay (or cost of failure) curve, also known as the market payoff function. If for example, failure to deliver a feature on a given date would result in a Federal government fine for breaking the law, then we can describe this as a unit step cost of delay function with a defined tangible cost. Kanban teams treat requests like this differently from other types of requests. In fact Kanban teams typically create several classes of service - 4 or 5 is typical. Classes of Service are delineated (usually) with different colored tickets on the board and through different prioritization policies. It is normal for higher classes of service to require some form of estimation. The significant cost of delay that can be incurred through late delivery has to be mitigated through estimation and the use of the estimate to facilitate prioritization into the input queue in an optimal fashion. Early enough to insure delivery, not too early as to displace something that might be more valuable at an earlier date.

So, Kanban teams eliminate estimation when the risk profile says it is appropriate to do and don’t when it doesn’t.

What about planning?

Well planning is different in Kanban. A release cadence needs to be agreed based on the transaction costs of delivery/deployment. An input cadence needs to be agreed based on the transaction costs of convening the stakeholders and the coordination cost of bringing them together to discuss the input queue. A standard class of service level agreement with a cycle (or lead time) needs to be agreed as a target for delivery. As for planning in terms of selection of items in the backlog, this is done as late as possible on as little of the backlog as possible. It’s a very Lean approach to planning.

It’s not that there is no planning in Kanban but it is a different approach to planning than either traditional project management or more modern Agile methods such as Scrum.

Related Posts: Kanban & Retrospectives, Kanban in Action. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Software+Engineering, Project+Management

Kanban & Retrospectives

There’s been some chatter on the discussion lists and Twitterverse recently on the topic of whether Kanban practitioners view Retrospectives as waste (in Lean Thinking terms).

Heck, Kanban has already cocked a snoot at Agile Holy Grails such as time-boxed iterations, and planning and estimation, so why not retrospectives as well?

So the record needs to be set straight on this. Some clarity and signal needs introduced amongst the noise.

Some mature Kanban teams did drop the use of retrospectives. No one told them to do it. They just did. Retrospectives were not adding value in their lives and hence were seen as a wasteful activity that could be eliminated. How did this come about? Well, firstly the management (that’d be me) had encouraged a culture of continuous improvement and a focus on objective quantitative management. The organization was holding a monthly operations review to reflect on performance. So, there was already a monthly retrospective opportunity built in to the working lives of team members. Secondly, mature kanban teams were capable of releasing (or integrating in the case of major projects) every couple of weeks or so, with a negligible defect count. Things went very smoothly so there wasn’t much to discuss. And thirdly and most importantly, the institutionalization of a culture of continuous improvement had created what was known as the “after meeting”, when folks huddled together after the morning standup meeting to discuss issues that often led to improvement opportunities. These spontaneous meetings were equivalent to what in manufacturing is referred to as a spontaneous quality circle. This empowered self-organizing type of self-affiliating quality/improvement group has only been seen in some of the most Lean of companies. Kanban seems to facilitate it in software development.

So, to summarize… teams that were part of an organization that gathered objective data, held a monthly operations review (and walked the walk, not just talked the talk) on organizational performance, and teams that delivered with a mature regularity, reliably and predictably, and teams where the culture had matured sufficiently that spontaneous quality circles were forming after daily standup meetings, found iteration (or release) retrospectives to be of little added-value and dropped them from the process.

Teams that did not mature to this level tended to keep retrospectives as part of their process. While the very mature teams would still hold a retrospective when something extraordinary happened - such as a botched release. In this case, retrospectives were being used in an event driven manner to perform casual analysis and resolution.

So it’s horses for courses. Kanban can enable a team to reach a level of maturity where they may choose to eliminate retrospectives (or not.) It’s a choice! Every situation will be unique. The important thing is not to see elimination of retrospectives as wrong or bad or “not agile.” Equally, don’t rush in and eliminate retrospectives. Don’t proscribe retrospectives. Let the team make its own decision when it is ready and embrace the evolution of process that comes with continuous improvement. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Software+Engineering, Project+Management

Thursday, March 19, 2009

L&K2009: Dean Leffingwell Opening Keynote

Dean Leffingwell will be the opening keynote speaker at Lean & Kanban 2009 in Miami on May 6th. Register now for the whole event at the early bird rate of $700, or for the one day Lean event May 6th only at $335.

A Lean and Scalabe Requirements Information Model for Agile Enterprises

Agile development practices introduced, adopted and extended the User Story as the primary currency for expressing application requirements within the agile enterprise. However, as powerful as this innovative concept is, by itself the user story does not provide an adequate construct for reasoning about investment, system-level requirements and acceptance testing across the enterprises project team, program and portfolio organizational and system hierarchy. Building enterprise-class software systems in an agile manner requires a richer model for discussing requirements-related concepts including not only user stories, but Investment Themes, Epics, Features and Nonfunctional Requirements as well as the various types of acceptance testing that helps assure system quality. In this tutorial, Dean Leffingwell describes a Lean and Scalable Agile Enterprise Requirements Information Model that scales to the full needs of the enterprise, while also providing a quintessentially agile subset for the agile project teams that do most of the work. This model has been developed and applied effectively in a number of very large scale agile enterprises, some supporting thousands of practitioners.

Dean Leffingwell Bio

Dean Leffingwell is a consultant, entrepreneur, executive and technical author who provides product strategy and enterprise-level agility coaching to large software enterprises. Recently, Mr. Leffingwell was founder and CEO of consumer marketing identity company ProQuo, Inc. Mr. Leffingwell has also served as chief methodologist to Rally Software. Formerly, Mr. Leffingwell served as Vice President of Rational Software, now IBM’s Rational Division, where he was responsible for the Rational Unified Process. Leffingwell was also co-founder and CEO of Requisite, Inc., makers of RequisitePro for requirements management. Mr. Leffingwell has been a student, coach and author of contemporary software engineering and software development management practices throughout his career. His is the author of Scaling Software Agility: Best Practices for Large Enterprises and Managing Software Requirements: First and Second Editions, all from Addison-Wesley. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Dean+Leffingwell

Tuesday, March 10, 2009

Reflections on Agile 2009 Part 2: Frontier Stage

Thanks to everyone who supported the campaign to add the Agile Frontier stage to the Agile 2009 program. Our passion for this was vindicated with Frontier receiving 125 submissions in total. It has been given a full stage status (not a virtual stage as originally suggested) and allocated one room at the event. This means that in terms of numbers of submissions to available slots the stage is 5x over-subscribed. In terms of bandwidth (time for each proposal versus time alloted) the stage is 9x over-subscribed.

:-D This is fantastic news!

There is clearly demand for innovative new ideas, Devil’s Advocacy, and slower burning concepts on the fringe of the Agile community. The quality of the submissions is quite outstanding and the stage attracted some big name submitters such as Scott Ambler and Mary Poppendieck.

During the submission process Olav Maassen, I and Eric Willeke triaged our submissions, reviewing them and advising up to 30 people to move their submissions to another stage. We actually did everything we could to minimize submissions to the Frontier and yet it was still one of the most popular stages. Ironically, we got penalized for this community-centric social behavior. The conference bandwidth was allocated based on number of submissions to each stage. If we had not pushed content off to other stages but simply horded it and then rejected it later, we would have been given more bandwidth at the conference.

The system certainly isn’t perfect. There is a lot of work to be done to show that the Agile Alliance conference is capable of exhibiting the core principles of agility.

Meanwhile, the Agile Frontier stage review team has a hard job on its hands. I hope we’ll be able to be as transparent as possible about our selection criteria. I’d really like to see us lead by example. More on this as it happens…. [We’ve set the review committee a deadline of Friday March 13th to close out their reviews. Then we’ll get down to the hard work of selection.] Technorati tag: Agile+2009, Agile+Chicago, Agile+Alliance, David+Anderson