Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (17)
Semelhante a Benjamin mitchell agile x
Semelhante a Benjamin mitchell agile x (20)
Mais de Skills Matter
Mais de Skills Matter (20)
Último
Último (20)
Benjamin mitchell agile x
- 1. Using Kanban to Get Knowledge and Continuously Improve Benjamin Mitchell Independent Consultant Twitter: @benjaminm
- 2. Take-aways Thinkfor yourself in your context Get knowledge by studying your process as a system, end-to-end from the customer point of view Only apply tools when you’re confident they fit your context Run experiments to learn while you work Do this in a way that encourages Double Loop Learning – “Doing the Right Thing, Righter”
- 3. Deming Cycle / PDCA
- 4. The Vanguard model for ‘check’ Thinking What is the purpose (in customer terms)? C U S T O M E R S System Conditions Flow : Value work + Waste 1 4 3 2 6 5 Capability of response Demand : Type + Frequency What matters? Vanguard Model for Check
- 5. Purpose “To get and keep customers”
- 9. Minimize TOTAL time through the loop
- 11. Demand: Type + Frequency
- 16. Flow: Value Work + Waste
- 24. Source: Reinertsen, D. (2009) The Principles of Product Development Flow: Second Generation Lean Product Development
- 31. Source: Kay, J, (2010). Obliquity: Why our goals are best achieved indirectly
- 33. Wasted Time Hrs/ Week
- 36. Purpose Measures Method To improve performance, change thinking Thinking System Performance
- 44. Minutes to Deploy to Production
- 45. Is this banana active?
- 46. Take-aways Think for yourself in your context Get knowledge by studying your process as a system, end-to-end from the customer point of view Only apply tools when you’re confident they fit your context Run experiments to learn while you work Do this in a way that encourages Double Loop Learning – “Doing the Right Thing, Righter”
Notas do Editor
- 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.