What I have learnt is; don’t.
Lean is counter intuitive, ill-defined*, and a tough concept to sell. Instead, ask them what outcome they want to improve: efficiency, speed, quality, innovation, morale or reliability. Use Lean Thinking to determine what Predictor could lead to the improvement they desire. Measure that Predictor, and apply some Lean Thinking without talking about Lean. The improvement they seek should materialise and you will then have support to work on the next improvement. Over time the business will be more successful.
Effectively Lean is a tool kit that you can utilise to improve business outcomes. Don’t ‘do Lean’, use ‘Lean Thinking’. Similar to agile, you can’t ‘do agile’, but you can think in an agile way.
*just search for images of ‘House of Lean’ to see how many different ways it is represented.
Sell OutcomesGenerally speaking any manager is going to be interested in improve one or more of these outcomes:
- Efficiency - producing more with less.
- Speed – increases frequency of delivery, or completing projects quicker.
- Quality - of the product delivered.
- Innovation – both internal innovation and product innovation.
- Morale - of staff
- Reliability - of delivery / predictability of release cycles / doing what we say
Conversations about getting better at an outcome; are much easier to have then attempting to explain how Lean Principles can help them. So instead of trying to sell them on the idea of using Lean, talk to them about what they are really interested in (getting better).
Measure Predictors not OutcomesA Predictor is an aspect of work that affects the target Outcome.
To gain support for making future changes it is important to be able show improvement. This is where you apply some Lean Thinking (without mentioning that it is Lean) to select appropriate Predictors to measure.
e.g. As a team you release that you quality is not as good as you would like it to be. After discussion with the team you find out that the code coverage is low (i.e. < 60%). Using the Lean Principle of ‘Build Quality In’ you decide to measure Code Coverage. The extra tests will increase the quality of your deliverables. Once the code coverage approaches 80% you drop that metric (to prevent gaming of the metric). Now you switch to measuring the pass rate of the test suite, so that the effectiveness of the tests them improve. This will again improve quality. You could also consider measuring the ratio of Test lines of code to Product lines of code.
Some examples of PredictorsThis list is just meant to give you an idea of what to consider, it is by no mean exhaustive. Importantly these measures may not fit your situation. This is where your Lean Thinking needs to kick in.
Outcome (measure of the outcome)
- Predictor / Measure of the Predictor
Efficiency (High value delivered per release)
- Low average hours in meetings.
- High ratio of work developed using ATDD.
Speed (Low cycle time)
- Low WIP.
- Smaller User Stories.
- Average utilisation of staff below 70%
- High Quality & Reliability (speed usually comes from quality and reliability)
Quality (Low average escaped defects)
- High ratio of work developed using TDD.
- Test coverage approaching 80%.
- Mutation coverage approaching 80%.
- High average pairing hours.
- High average Dev-QA pairing hours.
Innovation (High Average innovation ideas submitted per month)
- High time logged to innovation activities.
- Low duration of continuous integration test suite.
Morale (High Engagement survey results, High Retention rate)
- Low sick days.
- Average working hours just under 40 per week.
Reliability (High Ratio of delivered to planned user stories)
- Smaller User Stories.
- Low WIP.
- Low average days a story in blocked/impeded.
- High average number of commits per day.