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

|

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

|

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

|

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

|

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. :-S

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

|

It was a revolution in conference submission and a move toward a high trust, transparent culture when the Agile Alliance moved in 2008 to an open submission system for the Agile 2008 conference. It wasn't without it's flaws though and this year the system had a few tweaks - one of which was to hide the rating given by reviewers.

This reduction in transparency and consequent social capital was lamentable in my opinion. I am sure there was a better way to handle the problem with the recommendation engine. The 2008 model had a -2,-1,0,+1,+2 type voting system and some individuals were notable for simply skimming through and voting "-2" on topics they didn't like or people they didn't like, without attempting to provide any constructive feedback.

For Agile 2009, the system seems to be working even more poorly. Submissions opened in mid-December. Despite this about 20% of submissions to the Agile Frontier stage, for which I am a reviewer, happened in the last 3 days, with around 10% in the last 6 hours before the system closed.

For those who got their submissions in early, there seemed to be little benefit. Despite a review committee of 10 people for each stage, each submission received only 1 or 2 comments or reviews in the early weeks. Even now after the system has closed to submissions, but open for review, there are on average only 3 or 4 reviews for each submission. If the system were working properly there ought to be at least 10 and more like 20 reviews for each submission. In 2008, my submission received 14 reviews.

[Now there were issues with the technology... For example, if a submitter wanted to solicit reviews by sharing the submission URL on the Web, the socially minded agile community member clicking the link to give a review was in the early days simply shut out with an "access denied" message. Later this was updated to provide a login screen. However, many folks may not have had an account and would have to create one, by which time the system would have lost the state/context for the original link. The usability of the system has remained a problem despite the fact that this is version 2. I'm curious if the Agile Alliance pays for this development work. If so, then it ought to be better. It ought to be an exemplar, an archetype of agile development and business value delivery. If not, then they really ought to consider paying professionals to do the web site.]

So meanwhile, what about that lack of reviews, lack of community spirit and lack of early feedback? Shouldn't those who submit early be rewarded for their efforts. Should those who submit late be penalized? And what about those folks who have submitted 5 or more submissions? One fellow submitted 4 proposals to the Agile Frontier stage on the final day! My view on this behavior of submitting 5 or more proposals is that it is anti-social. In an open system it should never happen. If the system were working properly, then those who made 5 or more submissions should be thrown out of the Agile Alliance because they clearly don't understand a fundamental principle on which the community and its methods are based. Until then they can be forgiven. The system doesn't work the way it's intended.

For those of us who made the effort to review, folks who make multiple submissions give us extra work.

So, how do we modify the system for 2010? Firstly, we must not regress to a closed system. We should push forward with an open and transparent system. We should reward people for making early submissions, for making fewer, higher quality submissions, and for contributing to the community through the review system. Perhaps the system needs to work like a bulletin board? Perhaps you need to earn points for reviews and you can spend points on submissions? The key here is that there must be an economic system introduced that provides the correct balance of incentives. We need to get away from a deluge of submissions in the last 72 hours and from the culture that encourages spamming the system with submissions in the hope that one will be successful. Technorati tag: Agile+2009, Agile+Chicago, Agile+Alliance, David+Anderson

|

In the 2nd in my series to promote the Lean & Kanban 2009 conference, I'd like to highlight Amit Rathore (former Thoughtworker) and promoter of Lean Thinking in software development. Amit is proof that several people can follow the same line of thought independently and come up with almost identical solutions. I've been a big fan of Amit's blog. I'm looking forward to meeting him in person at the conference. Amit will be presenting on May 6th, Lean Day in Miami.

Lean Software Development for Startups (or Why Agile isn't Enough?)

If you're in a startup, then you know that statistically, the odds are heavily against you. Pretty much the only inherent characteristic of a startup that can be counted upon to help, is that of its small size. If the company can be nimble and agile, then it can hope to gain some traction against its larger rivals. In such an environment, using an Agile methodology is a given. Without some form of a hyper-iterative software process, it is impossible for a startup to create a successful product. Or even to determine what that product is! In todayʼs climate, exacerbated as it is due to competition, lower capital requirements for software companies, the compression of Internet time, and the recessionary economic conditions, it is no longer enough to just use an Agile method. To stay competitive, indeed to just survive, something more is required. Lean Thinking provides just such an advantage. A startup needs to ground its philosophy in Lean Thinking, Theory of Constraints, Critical Chain, Queueing Theory, Systems Thinking, and the like. It will obviously gain from the long-term focus, throughput-based accounting, and value-based constructs that these provide.

Amit Rathore Bio

Amit Rathore has been using agile methods since 2001 - and has more recently been a thought-leader in the lean software development community. He spent nearly seven years at ThoughtWorks working on a variety of projects in several domains - at large and small organizations. He's played several roles during this time - developer, architect, and project manager. Amit has been writing about his experiences at http://epistemologic.com and at http://s-expressions.com .

In the middle of 2008, he became part of the founding team of a startup based in Mountain View, CA. He's leading the software development effort in this organization - and he's been using lean techniques in order to do maximize what is doable, given the limited resources at the fledgling startup.

Register today for all 3 days at Super Early Bird price of $550, or Lean Day May 6th only at $335. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Amit+Rathore

|

I'm going to do a series of blog posts highlighting content at the Lean & Kanban 2009 Conference in Miami May 6-8. Starting with Peter Middleton, co-author of Lean Software Strategies. Peter will be presenting on May 6th Lean Day at the conference.

Lean Software Development: achieving better requirements

Abstract: Agile approaches help by acknowledging the uncertainty and noise that surrounds software development projects. Their solution to this is evolutionary or emergent development. The question now is how can we improve on this? How to make the requirements process more objective and rigorous? The presentation suggests that a lack of rigorous requirements data can lead to sub optimisation and solutions that lack end customer focus. The next wave is to understand why customers interact with the organisation and then put those interactions under statistical process control. The evidence available for the strength of this approach is substantial

Peter Middleton Bio: Dr Peter Middleton MBA is a Senior Lecturer in Computer Science at Queen's University Belfast, Northern Ireland. His PhD in Software Engineering is from Imperial College London. With James Sutton he co-authored the book: 'Lean Software Strategies' which explored the application of lean ideas to software development. His current work is on putting customers' interactions with an organisation under Statistical Process Control (SPC). The SPC data shows precisely the organisational performance customers are experiencing and therefore the current capability of an organisation to deliver it's services. Performance gains in the order of 40% are normal when change based on this data is implemented. The proposal is therefore the Agile and Lean methods should evolve to incorporate this technique.

Register today for all 3 days at Super Early Bird price of $550, or Lean Day May 6th only at $335. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Peter+Middleton

|

Exciting news about the Lean & Kanban 2009 Conference released today...

Quite simply the greatest ever assembled group of experts in Lean
software development will be convening in Miami in May to explore the
frontiers of agile and lean in software development. This is your
chance to be a part of the new wave in agile development and
management practices.

Speakers include: Alan Shalloway, Dean Leffingwell, Peter Middleton,
James Sutton, Corey Ladas, Karl Scotland, Amit Rathore, Sterling
Mortensen, Aaron Sanders, Rob Hathaway, Alisson Vale, Max Keeler,
Linda Cook, Eric Landes, Eric Willeke, Chris Shinkle and David Laribee.

The final conference agenda has been released. You can download it here.
http://www.leankanbanconference.com/agenda.pdf

along with the program (draft) released yesterday
http://www.leankanbanconference.com/LeanKanbanProgram.pdf

The new conference format provides Day 1 - May 6th - as a Lean Day and
Day 2 - May 7th - as a Kanban specific day. Day 3 will be open space
and lightning talks.

Pricing
Today we are announcing exciting new pricing for the Lean & Kanban
Conference. We're responding to market feedback and making the event
more accessible.

Full Registration
Until March 16th full registration for all 3 days will be offered at
the super low price of $550. All existing registrants will be
receiving a refund in the next few days of the difference between the
previous amount and the new $550 super early bird rate.

After March 16th early bird registration will be $700 until April 16th
after which time the full $800 price will apply.

Register now at http://www.leankanbanconference.com/

Agile Florida special rate
Members of an Agile Florida User's Group can make use of the Super
Early Bird price as a special discount until April 16th. Membership of
an agile group in Florida and residency in Florida (based on Credit
Card details) are required to qualify.

Register now at http://www.leankanbanconference.com/

Lean Day Only Registration - May 6th
For those who only want to attend the Lean sessions at the conference,
we are offering a special one day rate that will include the evening
reception. The price for this is $335. Register now at
http://www.leankanbanconference.com/

Kanban Day Only Registration - May 7th
For those who only wish to attend the Kanban case study presentations,
we are offering a special one day rate of $295. Register now at
http://www.leankanbanconference.com/

Please bear in mind that the numbers at the event are strictly
limited. Please register early to avoid disappointment.

David
http://www.leankanbanconference.com/ Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Alan+Shalloway, Dean+Leffingwell

|

I've been busy finalizing the speaker roster and program for the Lean & Kanban 2009 Conference in Miami May 6th-8th.

We've finalized our speaker list. We will have key note speeches from me, Alan Shalloway and Dean Leffingwell. And main conference sessions from Karl Scotland, Amit Rathore, Corey Ladas, Alisson Vale, Peter Middleton, James Sutton, Rob Hathaway, Eric Landes, Eric Willeke, Chris Shinkle, Max Keeler & Linda Cook, Sterling Mortensen, Aaron Sanders and David Laribee. While there might be other leaders in Lean applied to software development that I'd love to have present at our event, I am confident this is the best line-up of thinkers and practitioners of Lean in software development ever assembled. Be sure to sign up soon as the numbers at the event are strictly limited.

Download the full program of titles and abstracts and speaker bios. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Alan+Shalloway, Dean+Leffingwell

|