Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile & Lean & Kanban in the Real World - A Case Study

3,762 views

Published on

An example of how Agile., Lean, and Kanban was used in the real world

Published in: Technology
  • Be the first to comment

Agile & Lean & Kanban in the Real World - A Case Study

  1. 1. Agile & Lean & Kanban in the Real World
  2. 2. Agile Lean Kanban in the Real World Outline 1. Lean Agile Overview 2. Kanban Method Overview 3. Case Study Lean Agile Overview Kanban Method Overview Case Study Copyright © 2014 Russell Pannone. All rights reserved.
  3. 3. Lean Thinking Lean Agile Overview Kanban Method Overview Case Study Copyright © 2014 Russell Pannone. All rights reserved.
  4. 4. Lean Thinking Explicit permission granted by Scaled Agile, Inc. © 2008 -2014 Scaled Agile, Inc. and Leffingwell, LLC Copyright © 2014 Russell Pannone. All rights reserved.
  5. 5. Value Delivery In Traditional projects: •Value is only delivered at the completion of last Phase of the Project •Real value cannot be recognized during the majority of the development process •Maximum value is achieved at product launch In Agile projects: •Each iteration delivers incremental functionality intended to continuously reflect the customer chosen direction for the product •Customer realizes value as early as the completion of the first iteration •Frequent integration at the end of each iteration ensures product quality early in the product lifecycle Months Weeks VS Copyright © 2014 Russell Pannone. All rights reserved.
  6. 6. The Triple Constraint Dynamic System Development Method Source: http://www.dsdm.org Copyright © 2014 Russell Pannone. All rights reserved.
  7. 7. Lean Thinking Explicit permission granted by Scaled Agile, Inc. © 2008 -2014 Scaled Agile, Inc. and Leffingwell, LLC Copyright © 2014 Russell Pannone. All rights reserved.
  8. 8. Develop individuals and teams; they build products Empower teams to continuously improve Build partnerships based on trust and mutual respect Respect Copyright © 2014 Russell Pannone. All rights reserved.
  9. 9. Lean Thinking Explicit permission granted by Scaled Agile, Inc. © 2008 -2014 Scaled Agile, Inc. and Leffingwell, LLC Copyright © 2014 Russell Pannone. All rights reserved.
  10. 10. Kaizen in Japanese means continuous improvement Humanizes the workplace Eliminates overly hard work (muri) Teach people how to perform experiments on their work using the scientific method Learn to spot and eliminate waste In all, a humanized approach to workers and to increasing productivity Kaizen Copyright © 2014 Russell Pannone. All rights reserved.
  11. 11. Lean Thinking Explicit permission granted by Scaled Agile, Inc. © 2008 -2014 Scaled Agile, Inc. and Leffingwell, LLC Copyright © 2014 Russell Pannone. All rights reserved.
  12. 12. 12 Seven Principles of Lean Software Development 1.Eliminate Waste 2.Amplify Learning 3.Delay Commitment 4.Deliver Fast 5.Empower the team 6.Build Quality In 7.Optimize the Whole Copyright © 2014 Russell Pannone. All rights reserved.
  13. 13. 13 Traditional Waterfall Process Explicit permission granted by Scaled Agile, Inc. © 2008 -2014 Scaled Agile, Inc. and Leffingwell, LLC Copyright © 2014 Russell Pannone. All rights reserved.
  14. 14. Empirical Process Ideas Build Product Measure Data Learn Build It Deploy It Measure It Think It Study It Tweak It Image based on lean startup mentality as popularized by Eric Riesin his book The Lean Startup. Copyright © 2014 Russell Pannone. All rights reserved.
  15. 15. Lean Thinking Explicit permission granted by Scaled Agile, Inc. © 2008 -2014 Scaled Agile, Inc. and Leffingwell, LLC Copyright © 2014 Russell Pannone. All rights reserved.
  16. 16. 8 Principles of Lean Agile Leadership Lean Agile Principles12345678Build high-performing teamsImplement software development flowUnlock the intrinsic motivation of knowledge workersTake an economic view of the full value chainEmbrace the Agile ManifestoDevelop people, not thingsOwn the system of which you speakDecentralize control Copyright © 2014 Russell Pannone. All rights reserved.
  17. 17. The Kanban Method Overview Lean Agile Overview Kanban Method Overview Case Study http://net1.ist.psu.edu/chu/wcm/vc/toyota1.gif Kanbanis a Japanese word that literally means sign card or sign board Copyright © 2014 Russell Pannone. All rights reserved.
  18. 18. Kanban Method –Core Practices for successful adoption 1.Visualize 2.Limit Work-in-Progress 3.Manage Flow 4.Make Policies Explicit 5.ImplementFeedback Loops 6.ImproveCollaboratively, Evolve Experimentally (using models and scientific methods) Copyright © 2014 Russell Pannone. All rights reserved.
  19. 19. Visualize Copyright © 2014 Russell Pannone. All rights reserved.
  20. 20. Limit Work-in-Progress
  21. 21. WIP Limits Each activity can only have so many work items Work items are pulled into next state only when there is space Copyright © 2014 Russell Pannone. All rights reserved.
  22. 22. Make Policies Explicit Policy Copyright © 2014 Russell Pannone. All rights reserved.
  23. 23. Sample Kanban Board Copyright © 2014 Russell Pannone. All rights reserved.
  24. 24. •Lead time measures the arrival rate. Lead time clock starts when the request is made and ends at delivery. Lead time is what the customer sees. •Lead Time is measured by elapsed time (minutes, hours, etc.) *Wikipedia Ticket Created Lead Time Manage Flow –Lead Time Copyright © 2014 Russell Pannone. All rights reserved.
  25. 25. •Cycle Time measures the completion rate •Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. •WIP = 100 work items in progress •Throughput = 2 work items per week •Cycle Time = 100 / 2 = 50 weeks This means that the Cycle Time to clear out all of this WIP is going to be 50 weeks, or roughly one year. Ticket Live Ticket Created Start Work Cycle Time Manage Flow –Cycle Time Copyright © 2014 Russell Pannone. All rights reserved.
  26. 26. Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Ticket Live Ticket Created Start Work Lead Time Cycle Time Summary -Lead Time and Cycle Time Copyright © 2014 Russell Pannone. All rights reserved.
  27. 27. Infrastructure Team Kanban Experiment Lean Agile Overview Kanban Method Overview Case Study •This real life example covers how a newly formed Infrastructure group applied hybrid of Lean Agile and Kanban within an American multinational corporation that is engaged in the design, development, manufacturing and worldwide marketing and selling of footwear, apparel, equipment, accessories and services. •As part of a $700K three year strategic program enabling Company ABC’s mission to create, transform and lead the marketplace with new organizational skills, processes and tools. From To Sales functional focus Enterprise solutions Independent fixes Integrated environment of people, process & technology Unstable Sales 1.0 tools Robust Sales 2.0 ecosystem Copyright © 2014 Russell Pannone. All rights reserved.
  28. 28. Setting Up, Supporting and Maintaining a Continuous Integration Environment Local Workstation DEV QA STAGE PROD Purpose Design & Code Purpose Support Development This is theTeam Integration Environment Purpose System Testing 1sttesting outside of Dev. Team Demos Purpose Final Qualification in PROD-like environment Purpose Live & accessible to End Users Generate Sales Gate to DEV •Commit to Source Control •Compile •Unit Test •Analysis (Sonar) •Component Test •Package •Deployment and Configuration Automation Gate to QA •Automated Functional Test (eg. Sauce) Gate to STAGE •Manual Acceptance Test •Manual PCI scans Gate to PROD •Automated Performance Test •Auto. Security Test (PCI Compliance) •UAT •PMO/Release Man. Approval •Business Approval Go live criteria •Technical Validation •Business Validation Copyright © 2014 Russell Pannone. All rights reserved.
  29. 29. Their Reality -Most of their work is event driven Russell: How are things going now that you are being agile and using Scrum? Carol: On this Program we’ve finally gone all-out being Agile and Scrum! Russell: So how’s it going? Carol: Well, it’s a lot better overall than what we had before... Russell: ...but? Carol: ... but we are a support & maintenance team. Russell: yes, and? Carol: Well, we love the whole thing about setting priorities in a product backlog, self- organizing teams, daily scrums, retrospectives, etc.... Russell: So what’s the problem? Carol: We keep failing our sprints Russell: Why? Carol: Because we find it hard to commit to a 2 week plan. Sprints don’t make too much sense to us, we just work on whatever is most urgent for today. Should we do 1 week iterations perhaps? Russell: Could you commit to 1 week of work? Will you be allowed to focus and work in peace for 1 week? Copyright © 2014 Russell Pannone. All rights reserved.
  30. 30. Their Reality Carol: Not really, we get issues popping up on a daily basis. Maybe if we did 1 day sprints... Russell: Do your issues take less than a day to fix? Carol: No, they sometimes take several days Russell: So 1-day sprints wouldn’t work either. Have you considered ditching sprints entirely? Carol: Well, frankly, we would like that. But isn’t that against Scrum? Russell: One size does not fit all. You choose when and how to be agile or use Scrum. Carol: So what should we do then? Russell: Have you heard of Lean Software Development and the Kanban Method? Carol: What’s that? What’s the difference between that and Scrum? And I really like the rest of Scrum though, do I have to switch now? Russell: No, you can combine the techniques! Lets collaborate on how. Carol: Great where do we start? Copyright © 2014 Russell Pannone. All rights reserved.
  31. 31. •Experiment with a process that better fits our mixof planned and unplanned (event driven) work •Better visibilityinto what the team is doing and needs to donext •See if Kanban Work-in-process limitswill help improve team effectiveness. •See if measuring and optimizing cycle timewill help improve our effectiveness Goal Copyright © 2014 Russell Pannone. All rights reserved.
  32. 32. •Backlog: (State=Future) Product Owner’s next 8 things for team to address. Max=8 Min=3. This state should *never* run out •Ready: Tasked-out stories ready to be worked. Max=8 Min=3. •Pending External Dependency: Blocked due to dependency on a ticket, meeting, info, etc. •Done: No limit because only Product Owner works on this state. •Accepted: A celebration of recently completed work. Clear out every two weeks. •Expedite: Emergencies (Yellow Cards)-may exceed the Work-in-progress limits Initial cut: Infrastructure Kanban Board Backlog (3-8) Ready (Tasked) (3-8) Pending External Dependency (8) In Progress (6) Done Accepted Expedite Copyright © 2014 Russell Pannone. All rights reserved.
  33. 33. •When you are available but In Progress is full, instead of starting something, can you collaborate to get something Done? •If not confer with the rest of the team and then go ahead and exceed the Work-In-Progress limit if that’s the only way to do valuable work. We hope that will be rare. •If you identify the need to issue a ticket, setup a meeting, request information, etc. Initiate that request during Task-out and put the card in Pending External Dependency. That gives us a head-start on things that require waiting. Put a sticky on the card to identify the dependency. •Use the process to the team’s benefit –but the process should not prevent you from doing the right thing. •Help someone requests turn into quick-planned stories, grouped into a Consulting epic. •Emergency something broke are Yellow-Card expedites. Hopefully rare. Explicit policies Copyright © 2014 Russell Pannone. All rights reserved.
  34. 34. •Continuous Planning: No Sprint Planning / Sprint Closing Meetings •Product Owner prioritizes the Backlog and keeps the 3 slots in (Top of) Backlog column full. •The Team tasks out stories when a slot is available in the Ready column. •WIP Limits: When a Work-In-Progress limit is reached, help someone finish something instead of starting something new (as much as possible). •Less Splitting: No need to artificially split a story to make it fit-in-a-sprint. However still a good idea to deliver value in small, manageable chunks. •VersionOne: New status Pending for (Pending External Dependency). •Cycle Time: Measuring and optimizing cycle time how fast can we get tasks done. •Consulting Stories: Help someone consulting (> 1 hour) –create a story and work with Product owner to plan it in right away Kanban-style. What changes Copyright © 2014 Russell Pannone. All rights reserved.
  35. 35. •Daily Stand Up •Product Owner prioritizes backlog •Retrospectives every two weeks •Product Owner backlog grooming daily •Time box Research stories •Track event driven work as Tasks •Keep the Kanban board and VersionOnein-sync What stays the same Copyright © 2014 Russell Pannone. All rights reserved.
  36. 36. •What is the right Work-in-process limit (if any) for Pending External Dependency column? •If you are Interrupted from In Progress work, should that card come out of the column? Where should it go? How does it re-start? Need to figure out Copyright © 2014 Russell Pannone. All rights reserved.
  37. 37. Scrum Kanban Scrumban Board/Artifacts Product backlog Sprint backlog iteration board mapped on the process board mapped on the process Events daily Scrumsprint planningsprint reviewsprint retrospective none required daily Scrumother Scrum related events if needed Prioritization Part of backlog grooming. Done by PO Out of the process. There should be a prioritized backlog. Out of the process. There should be a prioritized backlog. Who feeds the work in progress (brings new work) PO Depends on defined roles and necessities Depends on defined roles and necessities Iterations yes (sprints) no (continuous flow) not mandatory (continuous flow); could have sprints Estimations yes (in ideal days or story points) no (similar work size items) (a) no (similar work size items) (a) Teams recommended cross functional cross functional or specialized cross functional or specialized Roles Product OwnerScrum MasterTeam as needed Team + as needed Teamwork collaborative based on pull approach based on pull approach WIP planned for the duration of the sprint controlled by workflow state controlled by workflow state changes to work scope should wait for next sprint added as needed (JIT) added as needed (JIT) Product backlog prioritized list of user stories (estimated) no (JIT) no (JIT) Impediments addressed immediately addressed immediately (b) addressed immediately (b) When does it fit? Product developmentSmall value adding increments development possibleRequirements are in good shape Support/maintenance work (operational level) Product development (a) team needs to comment on non-fitting work items in order to ensure readiness (b) stop the line approach; teams should swarm to solve the impediment http://www.ontheagilepath.net/2013/09/scrum-kanban-scrumban-fast-overview-and.html Copyright © 2014 Russell Pannone. All rights reserved.

×