Announcing the Formation of the Lean Software & Systems Consortium

I’m incredibly honoured and excited to have been able to be a founding member of the Lean Software & Systems Consortium which was announced today at the Lean & Kanban Conference in Miami. I hope that this is a significant venture which will have a major impact on the software development industry.  Further information can be found in the press release, which I have copied below.

Announcing the Formation of the Lean Software & Systems Consortium

Consortium to Promote Lean Software & Systems Thinking For Software Intensive Enterprises

SEATTLE, WA., May 6, 2009 / PRNewswire. The Lean Software & Systems Consortium (LeanSSC) was formed today to assist enterprises that depend on software – from start-ups to those that build complex, software intensive products, systems & services – with the application of Lean Thinking throughout the enterprise.

LeanSSC is a global, non-profit organization whose mission is to promote professionalism and create awareness of lean science and associated competencies by creating and promoting a body of knowledge and an associated certification program. This body of knowledge will be organized around three elements of Lean Thinking – lean science, lean management and lean education.

LeanSSC will assist organizations in applying Lean Thinking to reliably deliver business value, adapt to changing market conditions, manage risk, improve predictability, increase flexibility and reduce variability – with the clear goal of substantively increasing the ROI of their software investment.

Founding member David Anderson noted, “It has been recognized for over 30 years that the role of management is the most significant leverage point on the economic performance of organizations that depend on software. During this period, management practices have not kept pace with innovations in software and systems development processes. The LeanSSC will bring Lean Thinking to bear on the organizational problem of creating software economically by providing a framework for better decision making and policy setting at all levels of the enterprise. We believe Lean Thinking adds value not only to individual contribution such as development, testing and analysis, but also to all levels of management.”

Other founding members also commented on the formation of the consortium:

“Lean Thinking brings an organizational solution to an organizational problem. I look forward to the LeanSSC making a substantial contribution to the industry.” – Dean Leffingwell

“The LeanSSC will help create a foundation of knowledge and foster a Lean Thinking paradigm shift that will greatly increase professionalism and improve outcomes in the software development industry.” – Alan Shalloway

“Enterprises building systems of significant scope have become increasingly lean, but not yet been able to engage its software development in this transformation. The LeanSSC provides the first practical mechanism to integrate software development into the lean enterprise.”
– James Sutton

About Lean Software & Systems Consortium

Based in Washington, USA, LeanSSC is non-profit consortium comprised of corporate members, academic institutions, and industry leaders who share the belief that understanding and application of the science of lean will be of great benefit to software intensive industries. LeanSSC’s mission is to promote professionalism and create awareness of lean science and associated competencies by creating and promoting a body of knowledge and an associated certification program.

The consortium is committed to community, communication and education and will be hosting Lean Software & Systems Conferences in Atlanta, GA and Europe in 2010.

Founding members of the consortium include David Anderson–David J. Anderson Associates, Alan Shalloway and Alan Chedalawada–Net Objectives, Dean Leffingwell–Leffingwell, LLC., Don Reinertsen–Reinertsen & Associates, Karl Scotland–EMC Consulting, Rob Hathaway–IndigoBlue, James Sutton–Lockheed Martin, Mike Cottmeyer–VersionOne, Peter Middleton–Queens University @ Belfast.

Information on the consortium will soon be available at For further information, contact David Anderson at

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Calendar and Download Updates

I’m pleased to have been asked to give a Lean and Kanban 101 talk at the Swiss Lean Agile Scrum conference in Zurich on June 4th.  I have added details to my Calendar page.

I have also now uploaded the slides from my “Kanban, Flow and Cadence” presentations at SPA and ACCU to my Downloads page.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)


Boris Gloger has written a couple of posts on Kanban. While I know Boris is a great ScrumMaster, Coach and Trainer, his interpretation of kanban is wrong in my opinion – although I may have misinterpreted his interpretation! My immediate thoughts were too wide and varied for a comment on his blog, and I was at SPA2009 so didn’t have time for an immediate response, so I made a number of tweets with the #notkanban hashtag.  This post is to follow up those tweets.

Boris says, “We need to tell the development teams what they have to do and we need to make sure that all activities: specification, requirements engineering, development testing will be worked on in exactly the right order, sorry FLOW”.  A kanban system does not prescribe a process (or the activities), but rather visualises the process in order to improve it.

Boris continues, “we need to make sure that all roles in the development team needs to know exactly when the owner of a role can do a piece of work. So they can really focus on their specialization.” He also says “This is definitely not SCRUM or the idea of working creatively together. It imposed specialization”. A kanban system does not insist on imposed and siloed specialisation with handovers, but rather recognises overlapping phases. This is actually closer to the Type C development style described in the New New Product Development Game than Scrum itself, which acknowledges Type C development as a primary source.

Next, Boris says “Development teams … do not need to think anymore. They do just need to work according to plan and we do not have any break in the deliver process anymore”. With a kanban system, teams do think. They should be continuously improving the process and value stream.  As James Shore reminded us (on twitter), Jeffrey Liker said in The Toyota Way that “TPS experts get very impatient… [when people] focus on kanban… kanban is something you strive to get rid of, not to be proud of”.

Boris seems to think that kanban is a process when he says, “So we do have now a very clear focused PROCESS that works much better than all the Scrum Framework”.  However, a kanban system is merely a tool to help visualise an existing process in order to improve it and enable work. It is not something which imposes a process and inhibits work.

Yet Boris also says, “So if we agree that it is a TOOL, that means CARD than we can not explain a way of development as KANBAN”. So yes, a kanban system is a tool, but it is not just having a taskboard with cards, but should also strive to limit work-in-progress in order to improve throughput and cycle time (via pull).

Boris also says, “The terrible danger of this approach is that we put the the thinking about the features before the development”. A kanban system is actually designed to achieve the opposite and not overly invest in features before development as this creates work-in-progress.

Finally, Boris says, “Why do we always look into processess of the manufacture world. Why does nobody tries to see the value of the work-processes that works in companies like PIXAR or IDEO. These are the companies in which creativity and coolness lifes”. A kanban system does not exclude creativity. The team is responsible for the process and the workflow and is empowered to inspect and adapt the system in whatever way it wants in order to maximise the value that it generates.

If anyone (especially Boris) wants to discuss these points (and others) more, then please join the kanbandev list. That’s where I and others are trying to find better ways of using and describing kanban systems for software development.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

SPA 2009 Highlights

This week I was at SPA2009. Possibly one of the best conferences I’ve been to recently. Diverse people with lots of great ideas. There are my highlights.

Coaching Self Organising Teams

This was an excellent session but Joseph Pelrine, full of useful and interesting ideas I hadn’t come across before.

  • Behaviour is a function of a Person and their Environment. Thus while we can’t change a person, we can change their environment.
  • Thoughts on the strengths and weaknesses of the popular Forming, Storming, Norming, Performing model
  • An alternative cooking based model: Solidifying, Congealing, Stagnating, Cooking, Burning
  • Understanding Flow, in terms of balancing skills and challenges
  • The Cynefin ABIDE model: Attractors, Boundaries, Identities, Diversity, Environment
  • Social Networking theory

In particular, the ideas around  Flow (“the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity”) resonated with me. While this is different from the MMF based Flow of Value I tend to talk about, I did find some interesting other parallels for thinking about kanban systems. A topic for a future blog post.

Estimation Fallacy

This was a great goldfish bowl discussion around the value of estimation. A recurring theme was trust. Should we spend our time building trust so that we can rely less on estimation, or should we spend our time getting better estimates because we can’t achieve trust?  The output of the session can be found here.

Automated Ajax Testing

This was run by a couple of guys from Caplin, who have an extremely Ajax based Rich Internet Application. They presented their experiences and learning from using Selenium as their automated testing tool.  Their conclusions were that, while Selenium isn’t perfect, when used with its Custom Locator functionality, and a UCD/DSL approach to structuring tests, it can be extremely valuable. A good example of a positive, art-of-the-possible approach to automated acceptance testing.

The session also introduced me to WebDriver, which looks like it could have potential as a new emerging automated web testing tool.

Complex Adaptive Systems

Jurgen Apello ran a thought provoking session on “What’s next for Agilists”? He based his assertions on learning from Complex Adaptive Systems (CAS), so I found it a useful recap of those ideas. It also generated lots of discussion about whether Agile has already applied CAS ideas, whether there are new things we can learn, or whether the ideas don’t apply at all.  The slides can be found on Slideshare.


Probably the most popular topic at the conference was functional programming, and in particular Haskell. One keynote, two scheduled sessions, and at least three BOFs. I went to a workshop on TDD and Haskell, and we looked at an approach to testing a Java application, via the Slim framework using Haskell and Model Based Testing. While I didn’t fully understand all the Haskell concepts, and I’m probably not going to start using the approach on a day to day basis, it was hugely eye opening as a different way of approaching a problem. Another example of smart people being creative and practicing the art-of-the-possible.

Lean & Kanban

As well as running my Kanban, Flow and Cadence tutorial, I was asked to help lead a Lean & Kanban BOF which had a really good turnout. We had some interesting discussion and it was nice to see some interest in looking at being successful from a different perspective.


Finally, there as a special evening event with the Extreme Tuesday Club which involved a panel discussion with some of original XTC crowd. The main point of debate was around how optimistic people were about the future of Agile. Personally, I think there are enough new ideas emerging (e.g. kanban got a mention) and enough people doing great things (e.g. the Selenium and Haskell sessions above) to be optimistic.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Lean & Kanban 2009 Miami Promotion

A new program and pricing structure has been created for the Lean & Kanban Conference in Miami.

There is now a Lean Day and a Kanban Day, each with a single track. The idea behind the new program is that it allows everyone to be able to see all the presentations, as well as enabling people to only come for a single day.  Additionally, there is currently an Early Bird rate until April 13th.

The new pricing is:

  • Full Registration (May 6-8) for all 3 days is $700 (subsequently $800)
  • Lean Day only (May 6), including evening reception, is $335
  • Kanban Day only (May 7), is $295

I’m also pleased to be able to announce a couple of promotions for readers of this blog. Please email me (kjscotland-at-yahoo-dot-co-dot-uk) if you would like to register at these prices.

  1. A Super Early Bird rate of $550 for all 3 days. (Update: Book directly from
  2. A Corporate rate, which includes 5 places for the price of 3, at the Super Early Bird rate of $550. (5 places for $1650).
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Kanban, Flow and Cadence at the Brighton Agile Forum

I’m going to be talking about Kanban, Flow and Cadence at the Brighton Agile Forum next week on Wednesday 18th March, 7.30pm. The venue is The Skiff, 49 Cheltenham Place.  More details can be found on upcoming.

If you’re in the area, I hope to see you there.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Lean & Kanban Conference London 2009 – Call for Ideas

Update: The provisional dates have moved to from Sep 21-22 to Sep 27-29.

I am pleased to announce that we have started to plan for a Lean & Kanban Conference to take place in London, provisionally set for Sep 27-29 at the RSA (

As well as hoping to get these dates pencilled into your diaries, we would like to get your ideas and feedback on what and who we could include in the conference program.  Please let us know if:

  1. There is something you would like to talk about
  2. There is something you would like to hear about
  3. There is someone you would like to hear talk
  4. There is a format you would prefer (e.g. more talks or more open space)

We’d particularly like to hear from you if you are based in Europe so we can have a strong ‘local’ flavour, and we’re also looking for recommendations of people beyond software development who might add a different perspective.

Looking forward to getting lots of replies!

p.s. Don’t forget the Lean & Kanban 2009 Miami conference on May 6-8.  See

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

An Agile Workflow

A common topic of discussion around kanban is whether the workflows or stages in a kanban system are counter to the Agile principles of cross functional and collaborative teams.   Its easy to talk about a feature going through the following flow in a kanban system:

Analysis –> Build –> Test –> Release

which I confess looks very waterfall-ish and I can understand why this can raise warning flags about the suitability of the kanban approach.  This got me thinking about how best to express a typical agile-friendly workflow.

Lets begin with the common basic stages on an agile team’s ‘story-board’.

To Do –> In Progress –> Done

Ideally, ‘Done’ means In Production, but often it means Ready for Release.  From a Lean perspective, features that are ‘Ready for Release’ but not yet ‘In Production’ can be thought of as inventory, and we want to minimise inventory, so visualising that inventory would be useful.  Thus we can change the workflow to:

To Do –> In Progress –> Ready for Release –> In Production

Looking at the start of the workflow, a common practice in Scrum is shaping the backlog, or grooming the backlog.  This is the process of ensuring that the the Product Backlog Items that we take into Sprint Planning are well-formed.  That is, that they are small enough, and understood well enough, for the team to be able to plan and deliver them within the time-box.  I don’t think this is Scrum specific.  There will always be a step of taking a business problem or goal, and transforming into pieces that can delivered incrementally and iteratively.  Sounds like Analysis to me.

To Do –> Analysis –> In Progress –> Ready for Release –> In Production

Features which are ‘To Do’ have not had any significant time invested in them yet but they are generally formed to some extent.  We can say that they Incubate. ‘Analysis’ has baggage associated with it so we can give it a different name. I like the idea that we Illustrate what we need to do as it seems to allow for the notion of using executable requirements or other lightweight, quick feedback techniques.  ‘In Progress’ now really means ‘Build (and Test)’.  We can say that at this stage we Instantiate the illustration.  ‘Ready for Release’ means that we can Demonstrate what we have instantiated.  This could also include any validation or acceptance by the business. Finally, when a feature is ‘In Production’ it should be generating value, so we can say that we Liquidate it.

So for each feature, one by one, we end up with:

Incubate –> Illustrate –> Instantiate –> Demonstrate –> Liquidate

Does that still seem like a waterfall process?

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

A Scrum and Kanban Comparison

In a recent thread on the kanbandev list, Tim Uttormark asked about how Kanban handles teams with different dysfunctions without the Sprint timebox and associated meetings.  He gave the following example:

In Scrum, all tasks for the iteration are estimated by the team in sprint planning. Tasks assignments are not known at the time of sprint planning. The task estimate results from a team consensus, so the one doing the work on a task is not (solely) responsible for creating the estimate.

In my example, Harry (due to his incompetence) and Bill (due to his laziness) would fall short of the standard set by the team’s task estimates. Jeff’s behavior will not point as clearly to him as the problem, but will still be manifested as a team issue. Since he is highly skilled, he is probably able to produce at a higher rate than the average team member, and he can finish his tasks on time despite overengineering them. The team however would be better off if he stopped at “good enough”, finished early and moved on to other tasks. Jeff’s dysfunction would likely be manifested as the team missing their sprint commitments — the team needs the above average performers to complete more than their share of tasks to compensate for the lesser performers. In this case the team’s estimate of how much work they can commit to completing in an iteration provides a standard for comparison of team performance. Of course this can be gamed too, but requires more of a team conspiracy than just individual efforts to undermine it.

I responded by trying to map the Scrum process onto a Kanban process in order to show how a kanban system might deal with the same situation.

Sprint Planning is where the team collectively and collaboratively plans and commits to a small increment of work. As you say, this meeting will highlight any mismatches in understanding of the problem or solution by generating the Sprint Backlog with tasks and estimates, such that the whole team has a common understanding of what needs doing and how long it should take. Harry’s incompetence can be mitigated because he should have a better understanding of the solution. Bill’s laziness can be mitigated because he has been part of the estimation process, and Jeff’s over-enthusiasm can be mitigated because scope has been clearly discussed.

The Sprint Review is where the team are accountable for their Sprint commitment. This accountability should again mitigate for Harry, Bill and Jeff, because they have to demonstrate their progress and explain variation from the plan.

The Sprint Retrospective is where the team can explore reasons behind variations from the plan (and strengths and weaknesses in general) and can inspect and adapt in order to learn and improve. Over time, this can also mitigate individual weaknesses.

So for Kanban…

Sprint Planning becomes Feature Planning. Rather than planning a timeboxes worth of product increment, the team plans a single valuable increment at a time – sometimes referred to as a Minimal Marketable Feature (MMF). The team limits the amount of work in progress in order to minimise the cycle time of these MMFs. Once they have completed and released an MMF, the pick up a new one and start by planning it. The Planning can happens as a team, and break down into tasks and estimates as per Scrum, thus bring the same benefits and mitigating weaknesses in the same way. A possible downside is the break in flow that may happen when you bring the team together. A solution to this could be to keep a prioritisation and planning cadence – e.g. a weekly meeting to decide what the team will be working on next, and to plan it out. The frequency of this meeting will probably depend on throughput. The more frequently the team is able to complete and release work, the more frequently this meeting can be scheduled. A difference between this planning cadence meeting and a sprint planning meeting, is that the planning is ‘de-coupled’ from the release. In other words, whatever is planned does not have to be completed and released before the next planning meeting. In an ideal world, however, the MMFs are able to be small enough such that they can be completed and released within a week. In this case, Scrum with weekly Sprints can look very similar to Kanban.

Because of this ‘de-coupling’ of planning and release, a commit and deadline is made per MMF. This is sometimes referred to as a Service Level Agreement (SLA) between the team and business. The SLA says that the team will deliver features X days from when they are prioritised in the planning cadence, and is usually derived from past measurement of cycle-time. Where there is variability in the size of MMFs, different SLAs can be set for different sizes. Standard Scrum story point estimating can be used to classify the MMFs into different SLAs. A Due Date Performance (DDP) metric can also be measured, which is the percentage of MMFs delivered within their SLA. This SLA and DDP is what creates the equivalent team accountability in Kanban. I blogged some more about this here.

Sprint Review can still happen as part of the Release cadence. However, as we have de-coupled planning from release, this can happen as frequently as necessary, depending on the cost associated with a release. In the ideal world, this cost is zero, and you could release small MMFs daily. In this case, a small review of each MMF as it is completed might be appropriate. If there is a small release process the team needs to go through, then a weekly release cadence might be better, with a weekly Review. Whatever the frequency, the release cadence brings the same accountability for what has been delivered, and how long it has taken.

Sprint Retrospectives, similarly, can still happen with their own cadence. Kanban does try and shift the emphasis on the improvement to be as continuous and ‘kaizen’ as possible, but a fortnightly or monthly retrospective would certainly be a good thing to start with. Again, the retrospective brings the same benefits as in Scrum. I blogged some more about this here.

So I’d say in summary that a kanban approach includes all the elements of Scrum (including stand ups as well), but decouples them from all being tied to the Sprint. This can create a more natural process. On the other hand, it can also be less clear what to do when as its not so defined.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Lean & Kanban 2009 Miami Update

From the kanbandev list:

Just wanted to remind you that our Lean & Kanban 2009 Conference is taking place in Miami May 6-8.

We’ve confirmed a few additional speakers for the event. Notably Joshua Kerievsky who’ll talk about the iterationless, estimationless XP process at Industrial Logic, and Jeff Patton who’s been using kanban with his clients in North America. It’s great to have Jeff, a recipient of the Agile Alliance Gordon Pask Award, on our roster.

We’ve also got Rob Hathaway from London who’ll be presenting a kanban case study from IPC Media in London and Sterling Mortensen who’ll revisit the Lean implementation at Hewlett-Packard LaserJet Development that revolutionized their cycle time and productivity.

This is undoubtedly the best collection of practitioners of Lean techniques in software development ever assembled. Don’t miss out. Register soon.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)