The Agile Executive

Making Agile Work

John Heintz on the Lean & Kanban 2009 Conference

with 23 comments

Colleague John Heintz has kindly compiled the summary below for the benefit of readers of The Agile Executive. John is well known to Agile Austin folks as well as to out-of-town/state companies to which he consults through his company. You can get a glimpse of his Agile/Lean thinking by reading his blog.

Here is John’s summary of the conference:

The Lean Kanban conference last week in Miami was astounding. David Anderson did a fantastic job, and everyone who contributed had great presentations.

I am humbled and emboldened at the same time. I’ve been involved in Agile since 1999 and Lean since 2004, so I thought this was going to be familiar to me, old hat.

Here’s my confession: I’ve pretty much ignored Kanban, writing it off as just slightly different than what good XP or Scrum teams practice anyway.

Wow, those small differences make a huge impact. I am very glad I decided to go to the conference, some internal hunch finally winning.

Here’s what I thought Kanban was before last week:

  • A Big Visible Board
  • A Prioritized Backlog
  • Close communication, minimizing hand-offs
  • Rules about cards on the wall

No Iteration/Sprint boundaries (I’m thinking more efficient but maybe losing something important…)

That’s all well and good and true enough. Easy to justify writing it all off with “I already know enough to help teams make a big difference”. In fact, Kanban can be boiled down to one single rule:

  • Limit the number of things in work to a fixed number.

But, if that’s all there is too it, why then did I hear things like these:

  • Kanban is easier to introduce to teams than Agile/Scrum/XP
  • “People who never say anything were offering ideas” (I’m pretty sure I heard this three time the first day…)
  • The team felt comfortable dropping estimates/retrospectives/standup questions/…

Wait, you say, this was the first conference and obviously full early adopters! Of course people are going to succeed because they self-selected for success. Good point, but that’s not everything that’s here. For example, Chris Shinkle’s presentation was a case study of rolling out Kanban to many teams who hadn’t asked for Kanban.

So between furiously scratching down notes[1], listening and tweeting[2], I started to think to myself:

  • Why does this make such a difference?
  • Easier to create thinking and reflective teams! Isn’t that cultural change?

I had the pleasure of wrestling this “why” question out with several people, especially Alan Shalloway.

The first answers people gave me were entirely unsatisfying:

  • David Anderson’s reply tweet: “Kanban is easier than Scrum because you don’t change any roles or workflow and you don’t teach new practices.”
  • Alan Shalloway first response: “Kanban cuts out the noise and reduces thrashing.”

Sure, sure, but none of those (good) things seem likely to create: cultural change, engaged teams, or reflective individuals. Those answers are technical, details, and generally not the “emotionally” important things needed for change. Mind you, I’m not really well versed in cultural or emotional change, but being the stubborn person I am, I kept digging.

Here’s where Alan and I got, please add any insights[3]:

  • My hypothesis: Kanban has concrete reflective tools: like “should WIP be 4 or 5?”. Very reflective, but not very abstract or hand-wavy. People can’t often use abstract reflective tools like Retrospectives.
  • Paraphrasing Alan Shalloway: Kanban reduces the fear of committing to a per story estimate – a significant risk in some teams. Less fear can lead to cultural change.
  • (not sure who): Kanban changes the focus away from blaming an individual to examining why stuff is stuck on the board. (I hear Deming…)

On to the actual trip report. Here is an abbreviated transcription of the proceedings of the conference. (Very abbreviated!)

  1. Alan Shalloway started the conference off with no small announcement: the formation of the Lean Software and Systems Consortium. He also mentions that this consortium will be creating a body of knowledge and promoting a distributed certification process. Certifications will be a very interesting topic, my initial reaction was negative. Now I’m just skeptical 😉 I’ve got a hunch that TWI, a hidden influence of Lean, may hold some of the secrets for a successful certification method. We’ll see how this plays out.
  2. Dean Leffingwell gave a keynote on a Lean and Scalable Requirements Model for Agile Enterprises. Very clear from executives down to team activity: maps from Themes to Epics to Features to Stories. This immediately cleared up some questions I and a client were having.  My favorite quote: “If you don’t know hot to get the story out of the iteration – don’t let it in” referring to acceptance tests.
  3. Peter Middleton presented material from “Lean Software Strategies“, co-authored by James Sutton who presented next. Peter is a professor at Queen’s University in Belfast and was the first person to really talk about the people issues. Much of what Peter related was how various practices caused people problems: recruiting and training goals (10 per week) would require recruiters and trainers to push even unqualified people into the company. That led to poor service, high-turnover, and greater costs.
  4. James Sutton has a small personal goal: to save the middle class. His presentation did a good job ranging over various Lean and Systems thinking topics, connecting the dots to Agile. Key quote comparing Lean and Agile: “Getting Prepared” vs “Getting Started.
  5. Sterling Mortensen presented a case study of introducing Lean into the Hewlett Packard printer development division. He said HP was already the “best of breed” and still became much more efficient and effective. My favorite quote: “Stop Starting, Start Finishing“. Sterling also said the “One” metric was continuous Flow. I’m not sure I understand that all the way; I’d been working under the assumption the One metric was customer to customer cycle time (from concept to cash.)
  6. Amit Rathore gave a personal case study of Lean in a start-up, Amit showed many examples and talked really honestly about his experience. My favorite quote: “not released equals not done”.
  7. Corey Ladas presented on his book Scrumban and his experience at Corbis (with David Anderson) and other projects. I bought a copy of his book out of his backpack and made him sign it.
  8. Jean Tabaka presented a thoughtful presentation on Lean, learning, ignorance, and people. Her narrative helped me further realize how Lean, and Kanban, play into the personal issues of learning and reflecting.
  9. Alina Hsu presented a case study of using Lean to organize the work of procuring a COTS (commercial off-the-shelf) software solution, not development. She had some great things to say about how delays cause major cost overruns. One thing that reduced the delays she mentioned was to change how agreement was reached. The team defined consensus as “I can live with it”, with the rules 1) I won’t go into the hall and try to subvert it, and 2) I won’t lose any sleep. These definitions help teams make decisions faster and reduced waste.
  10. Alan Shalloway presented on a model for understanding Lean and moving it beyond Toyota. He organized all the various concepts down into Lean Science, Lean Management, and Lean Education. Connecting this back to the Lean SSC announcement in the morning he said the consortium working to create value in those three areas.

And that was just the first day. Did anybody mention the conference day started before 8am and lasted till after 6pm? Oh, and everyone was glued into the room.

  1. David Anderson presented a keynote on the principles and evolution of Kanban. So much information! You’ll have to read his presentation and see the video on InfoQ, but just to provide a fragment from each I wrote down:
    • Principled recipe for success (including Balance Demand Against Throughput)
    • Metrics (like WIP is a leading indicator)
    • Agile Decision Filter questions
    • Lean Decision Filter questions
    • Kanban decouples input cadence, cycle time, release cadence
  2. Karl Scotland continued the detailed treatment of Kanban. Karl spoke about the Lean concept of Flow as expressed with Kanban – and even rename typical process steps to avoid any baggage with waterfall terminology. If you want to know more about how work actually gets done in a Kanban system, watch his presentation. His interesting names for for process steps are: Incubate, Illustrate, Instantiate, Demonstrate, Liquidate.
  3. Rob Hathaway presented a case study of his work building a game portal for a publishing business. He believed very strongly that teaching from principles (Value, Prioritization, WIP limits, Quality) led to success.
  4. Alisson Vale presented a tool… that enchanted everyone in the room. David Anderson himself said that Vale “has the highest maturity software team on the planet”. Now, tool support often isn’t the answer, and many teams get real value with a physical board – a tool isn’t a Silver Bullet. If a tool makes sense for you – this tool absolutely blew us away. I asked Alisson about buying or helping with the tool and he said they were considering open sourcing it! I offered my coding skills in extending it for my own clients to help reach that goal.
  5. Linda Cook presented a case study of using Kanban at the Motley Fool. Her presentation does a good job of showing how little is necessary to get a lot of value out of Kanban.
  6. Eric Landes gave a great case study about using Kanban in an IT development shop. His team went from struggling to turn requests around (41 days) to a rapid 9 day turn around. Again, his discussion of the team dynamics and reflection were interesting to how a tiny bit of Kanban can have a huge impact.
  7. Eric Willeke’s presentation was visually beautiful, but you’ll have to watch the InfoQ video to get the value out of it. It contained only two words in a quote bubble (from memory “Momma! Pirates!”) and was the backdrop for the story that he told. His story highlighted to me, again, that Agile doesn’t always stick but Kanban seems to.
  8. Chris Shinkle presented a multi-case study on rolling Kanban into a large software consultancy. Very interestingly, and contrary to much discussion before, Chris presented a practices first, principles later message. This again resonated strongly to me that Kanban practices are somehow special in encouraging people to reflect and reach for the principles.
  9. David Laribee presented an opinionated view on leadership and change using Lean. This quote stuck with me: “people support a world they help create”. His style of leading is to drive from “Values -> Practices -> Tools” and his presentation wove a story of Agile/Lean process change. Also, I really enjoyed his injecting reference to hardcore technologies: REST, Git and OSGi were fantastic to see in a Lean/Kanban presentation.

That was day two. I’d said we were all glued to the room before, now as I type this I realize our brains were coming a bit unglued at this point. Every presentation was top-notch, barely time for questions, breaks were cut short, and we came back for more as fast as we could. Oh, and apparently we collectively drank 2.5 times as much coffee as the hotel usually allocates for a group our size.

I’m not going to summarize the Open Space. Too many topics and changes in direction. You just had to be there 🙂

John Heintz

[1] I used the first 25 pages of a brand new notebook… for a 2.5 day conference… Every session had an overwhelming amount of information, and I’m glad InfoQ recorded video.
[2] My twitter account is, and you can follow everyone’s conference coverage at
[3] I’m going to keep following up on this topic in my personal blog:


23 Responses

Subscribe to comments with RSS.

  1. […] attended in many years. In addition to Mike Cottmeyer’s blog, John Heintz has done at  an excellent summary of the conference. Also, a few of my personal reflections can be found at Israel Gat’s […]

  2. It’s a pity folks look at Alisson Vale’s talk and see a tool. What they need to see is the process and the origanization behind the tool. The tool reflects the way the team work and their level of maturity. It’s not the tool that is impressive – though it is an impressive piece of software.

    What’s most impressive about Phidelis is that they build software and deliver it to customers with the type of precision and just-in-time efficiency that is normally associated with manufacturers like Dell.

    Phidelis are a Lean/Agile software company working at high maturity with a quantitatively managed business that is constantly improving through causal analysis and resolution and continuous improvement (kaizen events). Their portfolio is constantly risk balanced and aligned with customer contracts that are written based on a high trust relationship between the client and Phidelis. All their decision making is aimed at long term relationship development and customer satisfaction.

    All of this is breathtaking.

    The tool is impressive but it is merely the window. It allows us to look into the slick workings of Phidelis in real-time.


    David Anderson

    May 11, 2009 at 4:03 pm

    • Thanks for the insights, David! Could you also elaborate on their customer contracts?



      May 11, 2009 at 4:13 pm

      • I can’t speak to it intelligently. I would refer you to the presentation, video and paper in the proceedings. The key point is that the contracts contain four types of customer commitment. Phidelis organize their work using classes of service to align with these four types of contractual obligation. They then use policies to allow self-organization of the team to maximize the effectiveness of delivery against those contractual commitments. Essentially insuring that every release contains the optimal amount of customer satisfaction.

        It’s worth noting that Alisson Vale has tweeted that he is hugely impressed with my paper on risk management in the proceedings and believes that by adding risk profile / cost of delay as an orthogonal attribute to the work items and then associating appropriate policies (for pull) with these, he can further optimize the outcome. Essentially, he is saying he believes he can optimize customer satisfaction in each release while optimally balancing risk in his portfolio – and all in a self-organizing fashion at the individual contributor level.


        David Anderson

        May 11, 2009 at 4:19 pm

    • You’re right, I didn’t give Alisson credit for the team or social contracts.

      It was quite a deep presentation and I hadn’t absorbed it sufficiently to relate that.

      In fact I wanted to talk with Israel about the contract, since he has written and presented on social contracts before.


      John Heintz

      May 11, 2009 at 10:28 pm

  3. John asks a good question about why Kanban appears to drive culture change and institutionalization in a way that Agile hasn’t/struggles with.

    The answer he quotes me giving is really the response to “Why is Kanban easier to adopt?” It reduces the barrier to change by not changing/challenging things people old dear or things that define their professional ego or self-esteem.

    I think I gave the answer to why it drives cultural change in my key note…

    Most people in the workforce want to do the right thing. They want their employer to be successful. They want their projects to be successful and their careers to grow.

    There are very few pathological people in the workforce – though they do exist.

    Given that you are most likely to encounter the non-pathological folks, then it appears that when you provide transparency onto the workflow and the affects of individual actions (or inactions) then folks will learn from the outcomes of their actions and correct their behavior accordingly.

    If you couple this to education on a model or mindset that encourages people to make positive change then you have a powerful combination. By educating people on the effects of bottlenecks, waste and variability and the positive things that can be changed to alleviate them then you enable change on top of the transparency.

    Finally, by encouraging people to think of process as a set of policies (that can be changed) you arm them with the tool to enable the desired changes. You empower people by giving them policies to apply and follow and responsibility to change them when necessary. This is the final step in creating a controlled self-organizing, continuously improving culture.

    In other words, there is no one simple element in Kanban that is creating the cultural change. It is an ecosystem that contains transparency, workflow mapping and tracking, a model for improvement opportunities (bottlenecks, waste, variability), and explicitly defined policies mapped against authority levels with most policies controlled by individual contributors who use them to self-organize.

    The role of the manager becomes one of setting policies and empowerment levels – effectively defining the rules of the collaborative/cooperative game that is “agile/lean software development.”


    David Anderson

    May 11, 2009 at 4:15 pm

    • Thanks for the thorough reply, but I don’t think it really answers my question. I’m absolutely in support of what you are saying, but it doesn’t explain the extent of cultural change (at least to my stubborn hunch).

      You said:
      a) “transparency onto the workflow and the affects of individual actions (or inactions) then folks will learn from the outcomes of their actions and correct their behavior accordingly.”

      b) “education on a model or mindset that encourages people to make positive change … educating people on the effects of … and the positive things that can be changed”

      c) “encouraging people to think of process as a set of policies (that can be changed) you arm them with the tool to enable the desired changes”

      Transparency, education, thinking… None of those hit the emotional fear or courage meter.

      My main point is: XP should have done all of this, why didn’t it? (Or FDD or Scrum or SixSigma or …)

      Sure, sometimes it worked out, but not enough. Many people just didn’t grab hold and make it their own. Developers, managers, customers, executives, and so on – why didn’t more people take hold of the process and make it their own?

      You say:
      “You empower people by giving them policies to apply and follow and responsibility to change them when necessary. This is the final step in creating a controlled self-organizing, continuously improving culture.”

      I say Kanban seems to let more people take ownership than XP or Scrum. XP and Scrum empowered people too, at least I make it so when I lead Agile teams. Yet, there is something more or different.

      How do we exaggerate the cultural change even more than Kanban does?


      John Heintz

      May 11, 2009 at 10:52 pm

      • I don’t think you have to do anything on the fear or courage meter. As I explained in the key note. Someone leads by example – by suggesting improvements and making it happen.

        If there is one thing I didn’t mention in the earlier reply – the management need to show leadership, encourage changes (innovation) and show objective tolerance to the results. But most of that falls under transparency and reporting – just add leadership and stir.

        Now that does sound like Deming!

        It’s worth noting that XP talked about courage. In my book (2003) I argued that it wasn’t courage that was required rather a culture of personal safety instilled by a management with a failure tolerant attitide. Why should people have to brave at work?

        David Anderson

        May 11, 2009 at 11:00 pm

      • (Reply to David’s May 11, 11pm reply below…)

        Cultural change always involves emotional components. Maybe not fear and courage, but something beyond technical.

        Let me rephrase my in terms of your comment:
        How is it that simple Kanban is better than XP/Scrum at creating:
        * management leadership
        * innovation
        * objective tolerance to results
        * personal safety
        * fault tolerant attitude

        Rolling Agile out to teams should have the same goals and context, but in my experience only sometimes works.

        (I would also argue that “personal safety” and courage are linked…)

        John Heintz

        May 12, 2009 at 10:13 am

      • John, “Cultural change always involves emotional components. Maybe not fear and courage, but something beyond technical.”

        I’m sorry but I don’t agree with this. You’ve missed a very important point I’ve made. Perhaps I didn’t underscore it at L&K2009 in the key note and you haven’t seen me say it elsewhere…

        The observation about Kanban is that it produced counter-intuitive and unexpected results. While we thought we were doing Kanban originally for the mechanical benefits – elimination of queuing waste, reduced inventory levels and shorter cycle times – we actually discovered that Kanban changed the culture.

        There is no explicit emotional element to it. I now believe that it is as simple as creating a framework for the sociology of the organization to exist in a collaborative cooperative game. [I did say this in my key note speech.] It’s as simple as that. Create the right collaborative cooperative game.

        If you want the answer to why XP/Scrum don’t stick (institutionalize) or adopt as quickly, then ask, what are the elements of the XP collaborative game? What are the elements of the Scrum collaborative game? Who do they include? and what style of interactive is required? What does Kanban add that is different?

        I believe Alan Shalloway has answered some of these questions. For example, Kanban includes management in a collaborative way where Scrum excludes them as mere “chickens” and XP ignores them altogether.

        Kanban also includes more people further up and down the value chain where Scrum proxies the upstream value chain with a Product Owner and generally XP and Scrum ignore downstream partners altogether.

        I also stated that Kanban sets a cultural expectation of causal analysis and resolution and quantitatively managed continuous improvement from the very beginning. Both Scrum and XP are very weak in this area. They offer only the concept of a retrospective and the subjective approach used therein. They merely wave hands at the idea that things will change (and for the better.) The rest is left as an exercise for the reader. Kanban also elevates impediment removal to first class issue management and resolution. Again this is too softly described in the Scrum literature. Most Scrum teams I encounter are not good at this and the tools on the market generally underplay the role of impediments merely marking stories as “blocked” and not treating impediments/issues as first class work items that can be assigned to people for resolution. There is no reporting on number of open issues, age of the issue and impact. The only agile method that really made this explicit was FDD.

        So my advice based on empirical observation of high maturity Kanban teams/orgs is do not look for some magical emotional element at the root of success. Look to the rules of the collaborative cooperative game. Create rules that cause the desired behavior to emerge naturally.


        David Anderson

        May 12, 2009 at 10:42 am

  4. David, thanks for filling us in on Phidelis/Alisson. And, congratulation on the success of the conference!


    Israel Gat

    May 11, 2009 at 4:36 pm

  5. (not sure who): Kanban changes the focus away from blaming an individual to examining why stuff is stuck on the board. (I hear Deming…)

    That was me too!

    Alan Shalloway

    May 11, 2009 at 5:31 pm

  6. […] let me quote from this morning’s wake-up call: John Heintz on the Lean & Kanban 2009 Conference: Here’s what I thought Kanban was before last […]

  7. […] summaries from John Heintz and Dean Leffingwell, courtesy of The Agile […]

  8. Readers of this thread might also want to take a look at an earlier post in this blog on the subject of Kanban & Retrospectives (



    May 12, 2009 at 5:46 pm

  9. I had the pleasure of meeting with John in person to learn first hand about LK2009. We also exchanged emails on the subject over the past few days.

    It is becoming clear to me that that LK2009 was the kind of conference where quite a few things came together simultaneously to form a punctuated equilbrium.

    To quote John on the subject: “I’d say yes, you had to be there, to a certain degree.”


    Israel Gat

    May 15, 2009 at 11:23 am

  10. Another relevant post is David Anderson’s How to Start with Kanban (


    Israel Gat

    May 16, 2009 at 1:25 pm

  11. Click for a repository of posts on LK2009 by David Anderson.


    Israel Gat

    May 16, 2009 at 11:11 pm

  12. […] I am impressed: John seems to hit the ground running immediately after the LK2009 conference. […]

  13. See for discussion of what Kanban is vis-a-vis its organizational effects vis-a-vis its marketing punch.


    Israel Gat

    May 20, 2009 at 8:57 am

  14. […] may also wish to check out John Heintz review and perspective on the Lean&Kanban 2009 […]

  15. […] trip report from last year is on the Agile Executive blog for anyone interested. This entry was posted in posts by John Heintz. Bookmark the […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: