Uploaded bySkills Matter
Benjamin mitchell agile x
The document discusses using Kanban to continuously improve processes through knowledge gain. It recommends thinking about one's own context, studying processes as customer-focused systems, and only applying tools like Kanban if they fit the context. The Deming cycle of plan-do-check-act is referenced. Key aspects to focus on include purpose, measures, method, system conditions like flow and demand, and capability of response. The goal is to improve performance through changing thinking and running experiments to learn while working in a way that encourages reconsidering approaches, or "doing the right thing, righter."
More Related Content
Similar to Benjamin mitchell agile x
Benjamin mitchell agile x
- 1. Using Kanban toGet Knowledge and Continuously ImproveBenjamin MitchellIndependent ConsultantTwitter: @benjaminm
- 2. Take-awaysThinkfor yourself inyour contextGet knowledge by studying your process as a system, end-to-end from the customer point of viewOnly apply tools when you’re confident they fit your contextRun experiments to learn while you workDo this in a way that encourages Double Loop Learning – “Doing the Right Thing, Righter”
- 3. Deming Cycle /PDCA
- 4. The Vanguard modelfor ‘check’ThinkingWhat is the purpose (in customer terms)?CUSTOMERSSystem ConditionsFlow : Value work + Waste143265Capability of responseDemand : Type + FrequencyWhat matters?Vanguard Model for Check
- 5. Purpose“To get andkeep customers”
- 9. Minimize TOTAL timethrough the loop
- 11. Demand: Type +Frequency
- 13.
- 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
- 34.
- 35.
- 36. PurposeMeasuresMethod To improveperformance, change thinkingThinkingSystemPerformance
- 38.
- 39.
- 44. Minutes to Deployto Production
- 45. Is this bananaactive?
- 46. Take-awaysThink for yourselfin your contextGet knowledge by studying your process as a system, end-to-end from the customer point of viewOnly apply tools when you’re confident they fit your contextRun experiments to learn while you workDo this in a way that encourages Double Loop Learning – “Doing the Right Thing, Righter”
Editor's Notes
- #6 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
- #7 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?
- #8 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
- #10 Reverse the traditional “build it and they will come”
- #12 People look at making sub-components of the system faster, but not at why demand hits the system.
- #13 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
- #15 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
- #27 Provides some evidence that doing more takes longer
- #31 Shows our Scrum days. Amazingly low variation. Does this help us understand how we are delivering relative to purpose? How could we improve?
- #32 Does this represent a natural distribution about how people require ambulances?Targets always distort the behaviour of the system.
- #36 System conditions:Different teams – win / loseHierarchySeparation from decision making from work
- #38 Getting angry isn’t effective.If you’re not part of the problem, you’re part of the solution.
- #40 Ideally measures should achieve two goals:Understand how you are workingUnderstand how you can improve
- #41 Run experiments quickly to see if the data is valuable
- #42 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
- #43 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.
- #45 Here’s an example where variation is definitely not going to add value to the end customer.