Day 3: Wednesday, 1 May
How to Measure Anything: Douglas Hubbard
I've read the book before but this was a great opportunity to hear it in person and remind me of the bits I had forgotten.
Douglas provided an example of human calibration training.
For example...
Douglas provided an example of human calibration training.
For example...
- Provide a 90% confidence estimate range of the year Napoleon Bonaparte was born
- Now imagine you have a choice:
- If the real year is within your estimate, you win $100
- You spin a dial with 90% chance of winning $100
- If you prefer one choice over the other, your estimate is not actually reflecting 90% confidence so adjust it until you don't care either way
During questions, someone asked about measuring productivity.
Question 1: Why do you want to measure it? What outcome are you looking for?
Question 2: If it improved, what would you notice?
The Language of Change: Esther Derby
Esther's talk mainly triggered various questions for me:
Is the shape of the Satir change curve affected by change approach taken? As a solution-focused or positive deviance practitioner might say, successful change is already happening. Does amplifying that existing change behave the same as a foreign element?
In a culture of continuous improvement (e.g. Toyota), is there a generally different perception of change? Does this change how people generally respond to it?
Esther was in essence talking about modifying our language to better reflect the world view we wanted to change to.
I wondered then whether this conflicts with using the language of the customer which is what Steven Spear advocated in the 2012 conference.
Can key behaviours of an organisation be changed independent of modifying their world view? Essentially the behaviours are rationalised into the existing world view.
This reminds me of Edgar Schein's perspective in Organizational Culture and Leadership:
"...successful organizational change probably arises more from identifying assumptions that will aid than from changing assumptions that will hinder."
"...be alert to the fact that organizational change is often no culture change at all or, at best, a change only in some elements of the culture."
"...be alert to the fact that organizational change is often no culture change at all or, at best, a change only in some elements of the culture."
Rethinking Front-End System Design - Moving from Fuzziness to early "Success is Assured": Michael Kennedy
Realised that Success Assured is pretty much equivalent to finding Problem-Solution Fit in Customer Development but in scenarios where there is also significant technical risk.
Realised also that Lean Product Development is essentially talking about situations where there's more than one new product development effort / Lean Startup running and therefore there is value in capturing solution knowledge for faster responses to the next problem.
The purpose of trade-off curves is to accelerate the path to Success Assured by capturing and communicating relevant knowledge across new product development efforts.
After the session, I was talking to Michael Kennedy and Frank Vega about how this applies to what we do. For software development that is pushing performance boundaries (e.g., high frequency trading, games), classic trade-off curves seem quite relevant. For others, I proposed that it would be interesting for us to look back at past instances of decisions where we could have benefited from knowledge that was already acquired but lost from a previous effort.
No comments:
Post a Comment