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”
Summary
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?
