After the market fell out of complex derivatives, look to generate revenue by doing volume deals with external customersBuilt a website on top of internal pricing, booking and document generation tools.No real clarity about projects (and it changed) … but a default one
Only two products were usedOne client represented more than 90% of the activityOnly 1/3 of the users were actively using the system, nearly half had never even priced a single productWere we achieving purpose?Did we learn very much – did we need another product? Was the 28th really going to make a difference?
http://duke.edu/~dandan/Papers/meaning.pdfIn order to get closer to purpose, go back and question the way we are developing novel products in novel situations
Reverse the traditional “build it and they will come”
People look at making sub-components of the system faster, but not at why demand hits the system.
This is a graph of business days along the bottom.For each product, it shows the flow from development, to production, to being priced and finally, sometimes, traded.The red shows the time spent waiting for never traded.NOT LEAN – building ahead of demand.Red also showed the complexityWhat we we able to do in terms of our capability
Project was meant to be “all complete” for a “drop-dead date of the end of the year”The initial project was run by a consultancy who confused incremental and iterativeResult was no working build. Technical practices such as “re-generate the web services interfaces between front and back ends using meta-data” – like introducing ourselves to ourselves! “Enterprise”Took over in start of 2008 and introduced SCRUMAfter go-live, we decided to drop Scrum
Provides some evidence that doing more takes longer
Shows our Scrum days. Amazingly low variation. Does this help us understand how we are delivering relative to purpose? How could we improve?
Does this represent a natural distribution about how people require ambulances?Targets always distort the behaviour of the system.
System conditions:Different teams – win / loseHierarchySeparation from decision making from work
Getting angry isn’t effective.If you’re not part of the problem, you’re part of the solution.
Ideally measures should achieve two goals:Understand how you are workingUnderstand how you can improve
Run experiments quickly to see if the data is valuable
Analyse it in more detail if necessary.The question is does this help us deliver the purpose of the system, or how we can improve?- Perhaps improvement from seeing long delays on certain tasks
Measures of activity are less useful. The number of numeric points per person was broadly in control with massive variations. It is questionable whether achieving a more consistent numeric delivery. If so, there’s the hard work of de-aggregating and running experiments.Variation needs to be seen in the relation to the economic pay-off of the product development. If the variation adds value then removing it will be sub-optimal.
Here’s an example where variation is definitely not going to add value to the end customer.
Benjamin mitchell agile x
Using Kanban to Get Knowledge and Continuously Improve<br />Benjamin Mitchell<br />Independent Consultant<br />Twitter: @benjaminm<br />
Take-aways<br />Thinkfor yourself in your context<br />Get knowledge by studying your process as a system, end-to-end from the customer point of view<br />Only apply tools when you’re confident they fit your context<br />Run experiments to learn while you work<br />Do this in a way that encourages Double Loop Learning – “Doing the Right Thing, Righter”<br />
The Vanguard model for ‘check’<br />Thinking<br />What is the purpose (in customer terms)?<br />C<br />U<br />S<br />T<br />O<br />M<br />E<br />R<br />S<br />System Conditions<br />Flow : Value work + Waste<br />1<br />4<br />3<br />2<br />6<br />5<br />Capability of response<br />Demand : Type + Frequency<br />What matters?<br />Vanguard Model for Check<br />
Take-aways<br />Think for yourself in your context<br />Get knowledge by studying your process as a system, end-to-end from the customer point of view<br />Only apply tools when you’re confident they fit your context<br />Run experiments to learn while you work<br />Do this in a way that encourages Double Loop Learning – “Doing the Right Thing, Righter”<br />