1 / 41

Leveraging Lean Software Development Methodology in Agile Teams

Leveraging Lean Software Development Methodology in Agile Teams. Agile Philly Event – Lean Software Development Present by: Keetming Joel Chew, MSEE, PMP, MBA, CSM Jan 27, 2015. ACKNOWLEDGEMENT. Thank you Cerner for hosting this event! Our Hosts.

christined
Download Presentation

Leveraging Lean Software Development Methodology in Agile Teams

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Leveraging Lean Software Development Methodology in Agile Teams • Agile Philly Event – Lean Software Development • Present by: Keetming Joel Chew, MSEE, PMP, MBA, CSM • Jan 27, 2015

  2. ACKNOWLEDGEMENT • Thank you Cerner for hosting this event! • Our Hosts. • Cecile Mihalich, Charlie Villare & John Voris. • Our Food Sponsor is: the world's leading source of intelligent information for businesses and professionals. http://thomsonreuters.com/en.html

  3. BIO: KEETMING JOEL CHEW • Experiences utilizing agile and lean in new software product development, enterprise software implementation, and software release management. • Passionate about leveraging lean and agile best practices to help businesses deliver greatest value and, as a result, achieving a sustainable competitive advantage.

  4. AGENDA • Origin of Lean Principles. • Its impact on Lean Software Development. • Lean Software Development - 7 principles. • Looking at each principle in details. • Experiences of applying lean software development methodology in agile teams. • How to apply the 7 principles in the existing processes. • Lean Tool: Value Stream Mapping and Analysis. • "Before" and "After" Results. • Questions and Interactive Discussion.

  5. FORMAT • Presentation – 50 mins • About 30 mins for Interactive Discussion

  6. LEAN PRINCIPLE - ORIGIN Inspired by Ford Motors, later enhanced in Toyota Production System. Lean production is popularized by Toyota’s Kiichiro Toyoda and Taiichi Ohno. Lean processes focus on continuously deliver value quickly and smoothly with minimum waste and high quality in a sustainable way. Reference: 1. http://www.sae.org/manufacturing/lean/column/leanjun01.htm 2. http://www.lean.org/WhatsLean/History.cfm 6

  7. LEAN ADVANTAGE • Toyota transferred its concept of “lean” from manufacturing to product development. • Designs and prototypes are not useful to the customers until the new product is delivered.

  8. In many ways, Agile methods are consistent with lean thinking. "Think big, act small, deliver swiftly and smoothly with quality; learn and improve quickly.” Lean Software Development methodologies has evolved rapidly. It emphasizes on eliminating non-value adding activities. Improves flow. Improves organization decision making. Strive for continuous improvement. Emerged as its own discipline with the Agile movement! LEAN THINKING - AGILE Reference: 1. Poppendieck, Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesley, 2003 8

  9. LEAN SOFTWARE DEVELOPMENT Any software development lifecycle process or a project management process could be said to be “lean” if it aligns with the principles of Lean Software Development. No single prescription or formula for implementation. Just incorporate Lean principles and core values in processes. 9

  10. 7 PRINCIPLES OF LEAN SOFTWARE DEVELOPMENT Eliminate Waste  Empower the Team (Respect People) Defer Commitment Amplify Learning (Build Knowledge) Deliver Fast Build Quality In See as Whole Reference: 1. Poppendieck, Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesley, 2003

  11. 1. MINIMIZE/ELIMINATE WASTE Waste (Muda) in Software Development Work in Progress (Inventory). Defects. Waiting time (requirement gathering, infrastructure downtime, and others). Miscommunication. Unclear business requirement. Develop work that client does not want. Loss time from tasks switching. Others. Reference: 1. http://www.lean.org 11

  12. 1. MINIMIZE/ELIMINATE WASTE – Cont. Unevenness in Process (Mura) Need to maintain predictability while eliminating “Muda”. Use small batch. Leverage ‘Pull’ system. Overburdening of Team and Resources (Muri) Unrealistic plan/deadlines/arrangement. Failure to fully utilize talents and resources. Minimize escalations! Hot fixes! Reference: 1. http://www.lean.org 12

  13. 2. AMPLIFYING LEARNING “Kaizen” – Continue to learn and improve. Team must focus on reflection at end of each iteration and improve instead of “blaming” and “avoidance”. Improve various stakeholders communication. Team to acquire and share information on “how to” and “what to” resolve bottlenecks and risks that could hinder the continuous flow of lean process. If appropriate, use agile vertical slicing. Reference: 1. http://www.deltamatrix.com/horizontal-and-vertical-user-stories-slicing-the-cake 13

  14. 3. RAPID DELIVERY Deliver to end user quickly to get prompt feedback. Reduce future rework. Team can quickly make adjustments to meet customer needs. 80:20 rule, get the most important features, often with 20% of total effort, out quickly to achieve 80% percent customer value. 14

  15. 4. DEFER COMMITMENT Need to maintain flexibility to reduce irreversible decision. High cost decision should be deferred. Requirement could change. Deliver minimum viable product and get feedback. Lean Startup approach. Reference: 1. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses – Eric Reis 2. Running Lean: Iterate from Plan A to a Plan That Works - Ash Maurya 15

  16. 5. EMPOWER THE TEAM Decentralize control and allow team to have a sense of ownership and responsibility. People who do the work should be empowered to make decisions and commitments. Upper management should focus on motivation, mentorship, training, support, removing impediments and provided needed resources to the team. Respect each other among team members, “Listen First, Speak Second.” Facilitate direct access to various key resources. Promote training and skill acquisitions for longer term value creation.

  17. COST OF BUGS IDENTIFIED AND FIXES AT VARIOUS STAGES OF A PROGRAM

  18. 6. BUILD QUALITY IN Solid software architecture for scalability, stability and flexibility. Majority of defects have their root causes in the development systems and procedures. Stop and examine anomalies, need to understand root causes while fixing these bugs. Detect and fix defects as early as possible. Establish quality in processes. e.g. code standards. Continuous Integration, pair programming, code review. Test automation. Acceptance tests and test scenarios.

  19. 7. SEE THE WHOLE Need to see the entire value chains of the delivery, not just individual functional group or team. Identify delays between processes and handoffs between teams, departments or other organizations. Team should quickly identify any critical issues that affect value delivery and address them promptly. Systematically engage other key members outside of the team to contribute effectively. Should consider aggregates defects by feature.

  20. CHALLENGES IN CURRENT IMPLEMENTATION • Software releases are very unpredictable. Late. • Worst, there were several major escaped defects. • Team members failed to see big pictures by only focusing on ‘their’ user stories but little on team performance, roadmap epics and features. • Difficult for anyone to visualize end-to-end process beyond immediate Agile sprint.

  21. CHALLENGES IN CURRENT IMPLEMENTATION Agile means a lot of different things to different people. Team spent too much time arguing what is and what is not considered as “agile”.

  22. CHALLENGES IN CURRENT IMPLEMENTATION • Scrum Master and team NOT getting adequate support from others outside of the team. • Recognize the need to analyze and improve in existing agile processes.

  23. LEAN PRINCIPLE IN AGILE IMPLEMENTATION Agile manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Using Lean Thinking in Scrum is a great way to sustain a Kaizen culture. “Lean” practices are gaining popularity because they could make Scrum Teams more effective. There are many common practices and techniques used in knowledge work which directly support Lean principles. Reference: 1. https://www.scrumalliance.org/community/articles/2011/may/using-lean-thinking-to-help-scrum-teams

  24. ADOPTING LEAN PRINCIPLES • Many businesses are going through major organizational transformation with Lean. • Lean is well understood by and proven in our organization. • Lean generates vast interests for upper management. • Imperative to get full support from business executives make them successful and “Lean” did that. • Perceived to be more “transparent”. • Step-by-step value-driven delivery.

  25. LEAN TOOL: VALUE STREAM ANALYSIS Everyone in the organization can visualize the entire delivery value chain from a customer’s request to its final delivery. Team to examine what are the steps/processes that are NOT adding value to the delivery. Definition Process time (PT), aka “cycle time” - The time it takes to actually perform the work without any interruption within a process. Lead time (LT), aka “throughput time” - The time work is made available until it is completed and transferredto the next process in the delivery chain. It includes process time. To help the team analyze the information, we will separately examine “lead time” within each process and also “lead time”, the waiting time, between processes.

  26. VALUE STREAM MAPPING GUIDELINES Map all processes “as is” in a value stream map. Help team see the entire value chain of delivery. Perform analyses with inputs from stakeholders. Identify “non-value added” processes and “unevenness” in flow. Process re-engineering to eliminate non-value add and non-critical processes and streamline remaining processes.

  27. VALUE STREAM MAPPING GUIDELINES 2 Goals setting (realistic) together with the team with a “target” value stream map. Take key measurements and re-examine the value stream map after a period of time. (e.g. 4 weeks 2 sprints later). Check against planned value stream. Team will repeat analysis phase, learn from experience, and repeat the steps described above in subsequent iterations.

  28. VALUE STREAM: CURRENT STATE

  29. VALUE STREAM ANALYSIS – CURRENT STATE

  30. Too many functional silos. Many processes along the value chain have no ownership. Excessive decision in progress. Development and QA did not understand how and what the customer will consider a valuable release. Too many processes and long delays in product review and business analyses. VALUE STREAM ANALYSIS ISSUES FOUND

  31. VALUE STREAM ANALYSIS ISSUES FOUND 2 • Major defects were found late and with multiple reworks - number one waste. • Insufficient ATs. and miscommunications between BAs, Dev. and QAs. • Inappropriate quality analyses and test strategies. • Inadequate in-depth test cases scenarios early in the process.

  32. VALUE STREAM ANALYSIS ISSUES FOUND 3 • Various processes had excessive WIP, partial completion (inventory). • Gold Plating, extra features • Client facing team trying to impress clients and internal team with the breath of their domain knowledge. • A few development members were trying to impress by building sophisticated features that the customers do not really need. • Re-writing code/feature instead of reusing.

  33. Place appropriate limits on WIP. Modify processes to reduce DIP (decision-in-progress). Customer learned our development process. Use UI prototype reviews as a tool to collect VOC. Customers in Sprint demonstration. Review user stories and acceptance criteria with clients. LEAN SOLUTION

  34. LEAN SOLUTION 2 New paradigm shift in QA, including non-quality assurance members. Assist in identification of missed scenarios, unit tests, skipped processes. Mistake proofing. Embrace “A stitch in time” mindset. A timely effort will prevent more work later. Fix issues promptly. Acceptance Test driven development (ATDD)

  35. LEAN SOLUTION 3 Entire team now focus on customers’ value and ‘minimum viable product’, MVP instead of “cherry picking” individual user stories. Engage other departments that need to support team members. Team members become more vocal and willing to point out any issues early in the process. Team members have much greater awareness of what they are going to release and the value they are delivering. Team actively identify “blockers” of the value chain and evaluate key data they could use for self-management. Participate in continuous improvement as part of their routine.

  36. VALUE STREAM: AFTER

  37. VALUE STREAM ANALYSIS - AFTER

  38. LEAN IMPROVEMENT • Management while supporting the team had progressively increase the bar in terms of flowing value more effectively and efficiently. • Happy customers with faster deployment and high quality solution. • Gained customers’ trust and in better negotiation positions for various subsequent decisions. • Happy team members with greater sense of ownership and achievement, and better work-life balance.

  39. REAL WORLD CHALLENGES To some members, Lean reveals incompetence's, bureaucracy and non-value added activities that could be closely tied to certain organization roles. Significant cultural changes in all parts of the organization. Trained members were re-assigned to other projects or seek other opportunities. Hard to replace in a short period of time. Key members, especially the executives, underestimated the effort to sustain a “Lean” process. Failed to truly understand organizational capability, common causes of variation of each process. Set unrealistic long term goal.

  40. QUESTIONS Any Questions?

  41. DISCUSSION Share your thoughts and experience implementing Lean software development. Thank you!

More Related