Lean Software and Systems Conference 2010 (Bletchley Park)

This is just a summary of the points I took from the Lean conference at Bletchley. They all need expanding, this is just the stuff that struck me that I want to record.

A Kanban Multiverse – Karl Scotland

Points from his talk

  • Meaning = visualise; interact; persist
  • Kanban provides the translation between communities
  • Remove columns from the Kanban board - no more chucking things over the wall to people
  • Flip charts for design models
  • Dots on cards for every day in dev, crosses for every day in test
  • Exploration of UI is part of the card

Ideas applicable for my project

Add broken acceptance tests to the Kanban Board?

  • Start doing task breakdowns again
  • Add issues and impediments to Kanban board?
  • Mingle should be updated to reflect the Kanban, at the moment the states are incorrect

Converting a Scrum Team to Kanban - Mattias Skarin

Points from his talk

  • Moved from releases per iterations to releases per week
  • Shifted motivation from delivering at end of iteration towards delivering quality
  • Establish release cadence and team rhythm
  • Root cause analysis to find problems and target them
  • Removed the need for estimates

Ideas applicable for my project

Shift to focus on release cadence from iterations?

Product Development in the Land of the Free

Points from their talk

  • Goal should be to “Delight Customers”
  • Sitting together decreases waste
  • Sysadmins belong to the team and rotate
  • Deliver value fast enough and you don't have to ask for permission

Learn to Lean: Becoming a Lean Startup – Damon Morgan

Points from his talk

  • Introduce a learning culture: blogs, brown bags, conferences
  • Scrum introduces a half-day overhead of planning etc.
  • Scrum implies a handed off release to QA / Ops
  • Didn't have “QA” but “Developer/Testers” and “Tester/Developers”
  • Lean = planning on demand.
  • Not sure when we're supposed to do retrospectives with a pull model?
  • Definition of Done is not only released to production, but has two possibilities: Generating Value and Not Generating Value
  • Cards that are “complete” but not released are inventory (and therefore waste)
  • Need fast smoke tests
  • Monitoring allows you to reduce errors and see if the release was good. Auto-rollback if not
  • Releases can be small, feature-specific releases
  • Have an ideas wall for anyone to contribute
  • AB Testing very useful to this organisation.
  • Reduced reliance on estimates
  • Releases not a big deal – happen daily
  • Measure outcomes, not activity
  • Out of 20 ideas, maybe one works. But cost/benefit clear and well understood

Ideas for us

  • Become more release-focussed
  • Should we encourage developers to do (more) exploratory testing?
  • Definition of done should be “released”
  • Better automated monitoring

Using Kanban to Continuously Improve – Benjamin Mitchel

Points from his talk

  • Quality First
  • Flow important
  • “What wasted your time?” to do root cause analysis
  • Measure time taken to flow through the board
  • Even if you show people metrics they still don't believe you

Ideas for us

Thank goodness we're not a big enterprise organisation

Behaviour Driven Development – Liz Keogh

Points from her talk

  • The term BDD and what it means has solidified over time, but it's nothing new
  • Concentrate on your riskiest tests first
  • Write your tests starting “should”
  • Conversations are around behaviour not tests
  • Development of stories is focussed on learning

Ideas for us

We're pretty good at BDD

Value Stream Languages – Eric Willeke

Points from his talk

  • Really just a summary of the day / Lean
  • We should respect different languages
  • Break things down into what you need to learn, not what you need to do and how long it will take
  • Variation comes from time it takes to learn, not time it takes to do
  • Ask “what do we need to know that we don't know now?”
  • Break milestones down accordingly – High Learning → High Risk → Core Value → High Value
  • Standup should be phrased “what did we learn yesterday; what do I need to learn today”
  • When your acceleration of learning decreases it might be time to stop designing and start doing

Ideas for us

Maybe a shift in thinking about “learning” instead of “doing”


Points frequently repeated and/or relevant to my project

  • Aim towards no estimation
  • Not focussing on iterations but on releases
  • Releases are part of the definition of done
  • Our BDD and basic Kanban is pretty good
  • Visibility allows us to find bottlenecks and target them
  • Focussing on learning might be a path to improvement
  • Silos are Bad, mmmkay?


  • Trisha Gee

    Trisha is a software engineer, Java Champion and author. Trisha has developed Java applications for finance, manufacturing and non-profit organisations, and she's a lead developer advocate at Gradle.

    View all posts