Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
The Kanban Method - Fixing Continuous Improvement - AgileIL12
Transcript of The Kanban Method - Fixing Continuous Improvement - AgileIL12
How will we know this approach helps? Improvement Achieving Goals For your organization - Choose ONE
http://innovationgames.com Let's do a Retrospective for the Conference so far The "Scatter"/"Shotgun" approach "Laser" Focus Approach TIP: Use ROTI (Return on Time Invested) to focus retrospectives about Daily Meetings or Training Events Will you perfect the Conference from a "Learning that will Stick" perspective? Improvement Manifesto Sustainable Pace Burnout/Shock Therapy Work with the organizational network Shortcuts that seem easier / more convinient Integrate to the organizational Cadence Inventing a new cadence/routine Framed as Achieving Performance Goals Framed as holding Improvement Routines Start improvements when the timing is right Starting cool improvement programs regardless of current context Wait for Change Leaders who CARE Managers who happen to be FREE Focused Improvements towards Goal Scattered improvements We are uncovering better ways of improving by doing it and helping others do it.
Through this work we have come to prefer the approaches on the left over those on the right OVER OVER OVER OVER OVER OVER OVER What are you Doing? What are you Doing? Challenging your comfort zone http://www.agilesparks.com Questions? Energizing technology delivery organizations in Israel and Worldwide... Should we start with Scrum or Kanban? Establish traceability between WHY, HOW, WHAT + how to validate progress UP FRONT! Even if you start measuring later, this helps buy-in... Playing with the map available is easy enough... What if it's a bit more cloudy/foggy? So, we chose the right pace, focused on what's valuable, and are willing to adapt. We have a perfect Plan right? Minimum Viable Change How can we make Improvement Stick? Evolving through Experiments and Validated Learning OVER Following a Plan With an Improvement Goal in mind, find the # of Retrospectives Held ROTI Score of Retrospectives # of Issues raised # of Process Experiments # of Improvement Ceremonies spontaneously starting to happen # of failed Process Experiments # of improvement suggestions in the Backlog # Noise level in Retrospectives http://www.fourhourworkweek.com/blog/2009/05/19/vanity-metrics-vs-actionable-metrics/ Engagement score on the Improvement Board % of capacity allocated to Improvement Work Types continuously seeking the right process
for evolving the product continuously evolving the product / service for many agile is about breaking down a big product/project to smaller pieces in the face of complex dynamic markets/ecosystems with great uncertainty about the requirements since we are working in complex system and our understanding of what is the best fit for our needs is continuously evolving 2. Learning along the way After deciding which lean/agile building blocks to use, trace back to issues to verify the approach Pictures from a real @AgileSparks IT client management workshop - Major mobile provider in Israel 1. Dot-voting to choose Agility Goals 3. Identify Actionable Metrics 2. Build Implementation Backlog 4. Trace Backlog to Metrics to Goals (Inspired by Lean Hoshin Kanri Strategy/Policy Deployment Matrix) Participants take turns filling the matrix with explanations how a practice addresses the Goal 1. Participants vote what was their ROTI 2. Retrospect with ROTI as the Context that you can validate your direction and tactics with.
Use small experiments to eliminate the uncertainty around what works and provides value 5. Willingness to Experiment + Guidance How do we ensure the experiments do not stray from the righteous path? How do we avoid Babel Tower? Aren't we wasting time? You are the coach - don't you know what is best? Why experiment? longer sprints... micro-management dates on all cards Different Board for each Team! Different Estimation approaches Different engineering practices Different kinds of meetings Different questions in the daily Try... Exposing people to Complexity Thinking Try... Establishing Values
that filter experiments Remember - Experiments are GUIDED towards an expected condition Try... Establishing a small set of overarching Explicit Policies teams use as baseline http://alistair.cockburn.us/Summarizing+the+DOI Its best to choose values you connect to... Object Oriented Inheritance anyone? Kanban Board
Limited WIP Task Board ScrumBan Visualize Small Batches Manage WIP Scrum Guided/Informed Experimentation mindset Unwillingness to try/fail or deal with
heterogeneity OVER Also try... explicit consideration/reuse based on experiments elsewhere in the organization as part of the improvement workflow a.k.a Continuous Improvement is BROKEN - WHY? WHAT can we do about it? There is a story set in medieval times that tells of a traveller who comes upon three stonemasons. He asks each in turn:
‘What are you doing?’
The first answers, without hesitation, ‘I am cutting this stone.’
The second, who appears to be doing the identical job makes a gesture with his hand and says; ‘I am completing the wall.’
The third, again seems to be doing the same job slowly raises his eyes to the sky and says; ‘I am building a cathedral.’ There is a story set in current times that tells of a coach who comes upon three teams holding a meeting.
He asks members of each team in turn: ‘What are you doing?’
The members of the first answer, without hesitation,
‘We are holding a retrospective.’
The members of the second, who appear to be having the same kind of meeting make a "taking off" gesture with their hands and say;
‘We are improving our performance.’
The members of the third team, again seem to be having the same kind of meeting, slowly raise their eyes to the sky and say; ‘we are building a better business.’ WHY do many change programs take off with great energies only to stall mid-flight ? nimble and disciplined - you can be both - but you can also choose where to apply which The Kanban Method can be used as ONE kind of MVC to validate the direction of Lean/Flow/Agile What are the risky assumptions in your plan? What will Stick? What will be rejected? How do we know people will care about this change? What will actually be a step forward towards our goal? Improvement Landscapes 8h 5h 2h More importantly BOTH are designed to
become Inspect and Adapt methods at some point... Kanban Scrum 8h 5h 2h Identify Minimum Viable Change "Install" the Change Engine Establish Baseline of Engine Performance Tune the Engine Pivot or Pursue? Pivot or Pursue? Pivot or Pursue? Pivot or Pursue? Pivot or Pursue? http://www.agilemanagement.net/Articles/Weblog/OperationsReview-2.html
http://www.agilemanagement.net/AMPDFArchive/AMSE_Chapter14.pdf Operations Review Opportunity to learn and improve from data Standard Operation Metrics Measures aligned with Improvement Goals The first step in creating a Kanban system is to visualize the work and its flow. Identify the work items, steps from start to finish, and enumerate all work in the system. This is visualized on Kanban boards - Each item is a card. Each Step is a Vertical Lane. Start to use the kanban board as your main system to track work. You will start noticing things you weren't aware of and improving already. BUT don't stop here... the really good stuff is yet to come... WARNING: Some teams do stop here. They are only doing kanban partially and are not really getting the benefits of the Kanban change management system. Limit Work in Process As you can imagine, this is not trivial to make happen. Focusing on fewer things is HARD! Typical challenges are specialization, obstacles that block the work, and bottlenecks. All are things we typically sweep under the carpet and just take on more work to stay utilized. Kanban is about Facing the Pain & First, Lets see what happens before we limit Work in Process (WIP)... Queues Fill Up Work is Trashed as there is no capacity to process it Swarm to deal
with huge inventory We get a force/policy that drives the system to prefer flow over inventory, and gets things out the door faster DOING something
about it With Limited WIP... There is no improvement without Learning
There is no learning without surprises
There are no surprises without expectations/constraints
Drive your organization's capabilities forward by establishing the right constraints We argued that Toyota’s much-noted commitment to standardization is not for the purpose of control or even for capturing a best practice, per se. Rather, standardization—or more precisely, the explicit specification of how work is going to be done before it is performed—is coupled with testing work as it is being done. The end result is that gaps between what is expected and what actually occurs become immediately evident. Not only are problems contained, prevented from propagating and compromising someone else’s work, but the gaps between expectations and reality are investigated; a deeper understanding of the product, process, and people is gained; and that understanding is incorporated into a new specification, which becomes a temporary “best practice” until a new problem is discovered. http://hbr.org/2004/05/learning-to-lead-at-toyota/ar/1 Steven J. Spear Try... a 20 mile march adopt fanatic discipline when it comes to your improvement pace. march on in good/bad conditions, in a sustainable pace. * helps avoid the adrenaline bias of sprinting too fast and then burning out Leadership - give permission for ideas and encourage process innovation from any and all team members. Minimum Viable Change With an Improvement Goal in mind, find the 9. Learn along the way that you can validate your direction and tactics with.
Use small experiments to eliminate the uncertainty around what works and provides value The Kanban Method can be used as ONE kind of MVC to validate the direction of Lean/Flow/Agile Playing with the map available is easy enough... What if it's a bit more cloudy/foggy? What are the risky assumptions in your plan? What will Stick? What will be rejected? How do we know people will care about this change? What will actually be a step forward towards our goal? Implement Organizational Feedback using Quantitative Measures of Demand and Capability Manage and Limit Work Size Stories Features Funded Active Initiatives Manage WIP Levels Stories Features Projects/Initiatives Measure Cycle and Lead Times Stories Features Projects/Initiatives Requires some intelligent aggregation Leadership - give permission for ideas and encourage process innovation from any and all team members. or, in the words of Mike Rother (Toyota Kata): If an organization wants to thrive by continually improving and
evolving, then it needs systematic procedures and routines—methods—that channel our human capabilities and achieve the potential. Such routines would guide and support everyone in the organization by giving them a specific pattern for how they should go about sensing,
adapting, and improving. http://bit.ly/ToyotaKataChapter1Sample Inspiration / Further Reading http://bit.ly/ContImprovReading The next expected condition is an Hypothesis that we can improve further We design and run experiments on how we do things in order to reach it But Experiments sometimes succeed and sometimes fail! Cope in a sustainable healthy way with increasing Demand with same or decreasing Capacity Goal Improve Cycle Time Maintain or improve Motivation /
People Health (Net promoter score - Would you recommend a friend to come work in your department? Rate 1..10) Hypothesis - Kanban will help us shape demand, deliver faster on the highest priority items, while reducing abuse/context switches/unsustainable behavior Lets "Install" a minimum Kanban system so we can start seeing the flow of demand, how our capacity deals with it, and establish a baseline Even at this stage we will make progress towards our goals but it might be hard to measure if we don't have a previous baseline...
We will usually FEEL it though With a baseline installed we can start setting higher and higher expected conditions, running experiments to deal with problems we see, sometimes failing sometimes succeeding and raising the bar We might end up with different kanban systems/boards, different policies But they will be aligned with our goal or "die" in the evolution and we will have an evolving "shared language/baseline" over time experiments will be more and more decentralized as we teach our people how to run them leading to accelerated progress towards the goal At some point we might decide we are close enough to our goal and shift our focus to another goal