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 Project Management in a Waterfall World: Managing Sprints with Predictive Metrics

16 views

Published on

Applying Agile methods in a waterfall world seemed impossible until we discovered the 10 essential skills and tools. Five of these skills are organizational, while others translate the short intervals characteristic of Agile to the world outside of Software. User Stories becomes Boundary Conditions; Burn-down charts becomes Deliverable Hit Rate charts; Sprints become HW intervals; Sprint Retrospectives become Event Timeline Retrospectives, while the project as a whole is managed using Boundary Conditions. This presentation shows examples of these tools and shows examples of how they are applied.

Published in: Business
  • Be the first to comment

  • Be the first to like this

Agile Project Management in a Waterfall World: Managing Sprints with Predictive Metrics

  1. 1. 1 AGILE PROJECT MANAGEMENT IN A WATERFALL WORLD MANAGING SPRINTS WITH PREDICTIVE METRICS John Carter, Jeanne Bradford June 2014
  2. 2. 22 INSTRUCTOR BIOGRAPHIES • Architected Apple’s product development process (ANPP) to gain scalability and speed • Led development and program management teams for Apple, Cisco & Texas Instruments • Certified Scrum Manager • John Carter is Principal of TCGen Inc. and currently serves on the Board of Directors of Cirrus Logic (CRUS). • Prior to TCGen, he consulted to leading Silicon Valley technology companies. John was the architect of Apple’s product development process (ANPP) in use by all divisions. • Before starting PDC, John was Chief Engineer of BOSE Corporation where he was the co-inventor of Bose’s Noise Cancelling Headphones. John & Jeanne co-authored “Innovate Products Faster” a visual handbook on tools for teams
  3. 3. 33 AGILITY CASE STUDIES – SUCCESS STORIES 1 Shortening of internationalization of software from 11 months down to 1 month 2 Reducing time to release from every 8 months down to every 2 months 3 Having a savings of 40-50% of product development cycle time But all of these successes were in SW… how can we apply to Physical Products/Systems? Conducted research of case studies where Agile methods were applied to Products/Systems with nearly 20 participants
  4. 4. 44 HOW DO WE APPLY BEST PRACTICES TO HARDWARE? The challenge is how do we apply Agile Software Methods to programs that… • Have components with long lead times? • Development partners that do things their own way? • Long supply chains with components, sub-assemblies, and final assemblies that need integration around the world? • Medical products that require FDA compliance? • Large software platforms that are developed using Waterfall Methods? • …by adopting a couple of changes – easy to say, hard to do 1 AGILE TEAM SOFT SKILLS 2 SHORT INTERVALS WITH FEEDBACK
  5. 5. 55 10 AGILE SKILLS & TOOLS SOFT SKILLS 1. High performance teams 2. Self organized teams 3. Trust and empowerment 4. Customer owner & team interacting daily 5. Daily standup meetings SHORT INTERVALS 1. User Stories into Boundary Conditions 2. Burn-down charts into Deliverable Hit Rate 3. Sprint into HW intervals 4. Manage the project with Out of Bounds Process 5. Sprint Retrospectives into Event Timeline Retrospectives
  6. 6. 66 HOW IS AGILE DIFFERENT FROM WATERFALL? Freeze the Specs and Don’t Look Back Develop Fast, Learn, Improve The Waterfall Model Agile Method
  7. 7. 77 KEY AGILE & DEVELOPMENT TERMS Agile Backlog Burn-Down Daily Standups Scrum Scrum Masters Sprints User Stories Waterfall
  8. 8. 88 AGILE MANIFESTO – HARD TO DO IN SYSTEMS? 1. Business people and developers work together daily 2. Projects require motivated individuals, support & trust 3. Face-to-face conversation is most efficient 4. Agile processes promote sustainable development 5. Continuous attention to technical excellence 6. Simplicity – is essential 7. The best designs emerge from self-organizing teams 8. At regular intervals, the team reflects 9. Welcome changing requirements 10.Continuous delivery of valuable software 11.Deliver working software frequently 12.Working software is the measure of progress Software Specific 75% of the Agile Manifesto CAN apply to development of any type agilemanifesto.org
  9. 9. 99 SCRUM METHODOLOGY – BEST PRACTICES The most common implementation of the Agile Manifesto is Scrum Agile Manifesto Welcome changing requirements Deliver working software frequently Bus. & Developers work together daily Face-to-face conversation is most efficient At regular intervals, the team reflects Scrum Backlog, Backlog Grooming Sprints, Sprint Planning Customer Owner, Daily Standups Daily Standup Meeting Retrospectives, Reviews
  10. 10. 1010 AGILE METHODOLOGY – BEST PRACTICES Question: What are the most impactful elements of Agile/Scrum applied to SW? The top Scrum practices can be applied to Systems too! Daily Standups Burndown Charts Team Culture Customer Owner Sprint Planning User Stories Sprint Themselves Greenhopper 0 1 2 3 4 5 6 7 8
  11. 11. 1111 AGILE METHODOLOGY – BEST PRACTICES Question: What are the most impactful elements of Agile/Scrum applied to SW? Daily Standups Burndown Charts Team Culture Customer Owner Sprint Planning User Stories Sprint Themselves Greenhopper 0 1 2 3 4 5 6 7 8 The top Scrum practices can be applied to Systems too!
  12. 12. 1212 AGILE METHODOLOGY – BEST PRACTICES Question: What are the most impactful elements of Agile/Scrum applied to Products/Systems? Sprint Themselves Simulation/Emulation Local build capability Sprint Planning Empowerment User Stories Daily Stories Burndown Charts 0 1 2 3 4 5 6 More prototype iterations Three of the top “Agile” practices in Systems have little to do with Scrum
  13. 13. 1313 AGILE METHODOLOGY – APPLIED TO HW/SYSTEMS So why is applying Agile/Scrum to HW/Systems so hard?
  14. 14. 1414 AGILE METHODOLOGY – APPLIED TO HW/SYSTEMS The rest of the presentation takes you through the findings from our study and provides you with some practical ideas for implementation… …starting with the soft side and culture 1 Because Agile/Scrum is hard 2 It requires higher process literacy And greater cross functional teamwork skills 3 For more sophisticated teams; not for the faint of heart
  15. 15. 1515 FIRST, APPLY THE FOLLOWING CULTURAL ASPECTS AND… • Accept the fact that requirements may change You might just say that this is just common sense! Adopt the concept of 1 High performance teams 2 Self organized teams 3 Trust and empowerment 4 Customer owner & team interacting daily 5 Daily standup meetings
  16. 16. 1616 THEN, TRANSLATE SCRUM TO SYSTEMS Hardware Sprint Process Create short interval execution cycle based on meaningful deliverables, often Project Integration points PLANNING RETROSPECTIVE 4-8 week interval typical REVIEW OOB if required 4. Out of Bounds Process 2. Deliverable Hit Rate 1. Boundary Conditions 5. Event timeline retrospective 1. Boundary Conditions 1 User Stories into Boundary Conditions 2 Burn-down charts into Deliverable Hit Rate 3 Sprint into HW intervals 4 Manage the project with Out of Bounds Process 5 Sprint Retrospectives into Event Timeline Retrospectives
  17. 17. 1717 1. CREATING BOUNDARY CONDITIONS • A program consists of product attributes and program attributes • Boundary conditions typically have both • Create User Stories – Product Attributes • Create budget and schedule – Program Attributes • Select the top 3-7, define limits, and seek agreement with the management team As a <type of user> I want <some goal> so that <some reason> THIS BECOMES YOUR BOUNDARY CONDITIONS… STAY INSIDE THEM AND THE TEAM CAN KEEP MOVING FORWARD! DEV COST www.mountaingoatsoftware.com/topics/user-stories
  18. 18. 1818 1. EXAMPLE BOUNDARY CONDITIONS Agree on top 3-7 most important program and product requirements and set quantitative limits when possible. Boundary Conditions DEV COST Incremental cost $1.3M
  19. 19. 1919 1. EXAMPLE BOUNDARY BREAK Agree on top 3-7 most important program and product requirements and set quantative limits when possible. Boundary Conditions DEV COST Incremental cost $1.3M • Deliverable Hit Rate too Slow! • Key Engineer pulled! • Three week delay!
  20. 20. 2020 2. TRANSLATE BURNDOWNS INTO DELIVERABLE HIT RATE Identify the key tasks that should be satisfied during an interval • Can features be implemented? • Can features/specs be validated? • Can tasks be performed? • Can be a customized metric of progress This list of requirements can vary from interval to interval • Front end is more definition loaded • Middle is more task loaded • Back end is more validation loaded Create a target curve over the sprint interval • Don’t get too stressed out over perfection • Assume that the events can be distributed evenly, unless you have clear knowledge otherwise
  21. 21. 2121 2. TRANSLATE BURNDOWNS INTO DELIVERABLE HIT RATE Deliverable Hit Rate Based on planning for the sprint, numerically sum the key milestones/tasks (typically 10 or so) and the key verification tests to be performed and passed (typically 10 or so) and then spread them evenly over time, unless you have knowledge of key dates Sprint Duration (Weeks) Numberofremainingtask
  22. 22. 2222 2. EXAMPLE OF PCB LAYOUT PROGRESS • Aug 1 started tracking PCB routing progress to get an idea of project velocity • Aug 3 worried about progress, rate too slow • Aug 4 increased # of engineers assigned to this task 0 200 400 600 800 1000 1200 1400 1-Aug 2-Aug 3-Aug 4-Aug 5-Aug 6-Aug 7-Aug 8-Aug 9-Aug 10-Aug Number of Unrouted Nets Example how a Burn Down Chart can be applied to see the progress in turning a schematic into a layout
  23. 23. 2323 BURN DOWN METRICS FOR HYBRID DEVELOPMENT Concept Program Approved High Level Design Detailed Design Design Validation Production Requirements Design Test
  24. 24. 2424 3. TRANSLATE SPRINT INTO HW INTERVALS Divide the project into the smallest increment possible that represents TRUE INTEGRATION POINTS or CLEARLY DEFINABLE MILESTONES. Idea Approved Concept Approved Lab Prototype Accepted Off Tool Prototype Accepted Off Production Process Accepted Product Released
  25. 25. 2525 3. TRANSLATE SPRINT INTO HW INTERVALS Continuous learning, short intervals, measurable progress, autonomy The secret to getting the benefits of Agile development is to not slip the interval Idea Approved Concept Approved Lab Prototype Accepted Off Tool Prototype Accepted Off Production Process Accepted Product Released
  26. 26. 2626 4. BOUNDARY CONDITION PROCESS Out of Bounds Conditions Description of the steps that the Project Manager follows when an OOB condition is known to be likely. This whole decision tree should take place in hours/days and not weeks/months. PM agree? Know what to do? Team meets with management. Agree OOB Condition Exceeded? YES Send email OOB statement NO Assemble team meet and review YES Send email OOB statement NO Continue on, monitor Boundaries YES OOB Recommendation NO Meet to agree on proposer solution
  27. 27. 2727 5. EVENT TIMELINES AND RETROSPECTIVES 1. Event Analysis Identify the impact of planned & unplanned events on project outcome Event Timeline Process Three Steps to a Productive Retrospective Review 2. Root Cause Analysis Select most significant root causes 3. Root Cause Synthesis Understanding the big picture Planned Events Unplanned Events Definition Design Integration Validation Pilot Ramp Event 1 Event 2 Event 3
  28. 28. 2828 RETROSPECTIVES • Retrospectives should be carried out on all programs • The retrospectives should follow a common process which has the following attributes 1. Fact based, and data driven 2. Involve Cross-functional team members • The retrospective process should be owned by the team • The retrospective process should be used during every Interval • The process consists of the following steps 1. Event time lines & Prioritization of the biggest events 2. Root Cause Analysis 3. Affinity Diagram to summarize results
  29. 29. 29 Thank you
  30. 30. 30 TCGen Inc. Menlo Park CA, 94025 jcarter@tcgen.com (650) 733-5310

×