Agile Project Management in a Waterfall World
•
5 recomendaciones•3,517 vistas
Agile software management methods have helped teams become faster, but until now these methods don’t work well within the traditional phased development environments (waterfall). We demonstrate with case studies and a recent Silicon Valley study how select agile components (sprints, retrospectives, and burn down charts) can be tailored into a new project management model for complex product development. We also show the relevance of cadence, standup meetings and other foundations of the agile methodology in waterfall environments to give you a fresh approach to managing projects. You will learn: • How to create the Boundary Conditions to clarify and quantify project risks • How to break a phased project into Sprints that balance overhead with agility • How to apply Predictive Metrics to accurately gage progress
Recomendados
Más contenido relacionado
Destacado
Más de Cprime
Más de Cprime (20)
Último
Último (20)
Agile Project Management in a Waterfall World
- 1. Agile Project Management in a Waterfall World Managing Sprints with Predictive Metrics Kevin Thompson & cPrime Guest Presentation by John Carter February 11, 2014 JOHN CARTER TCGEN INC jcarter@tcgen.com
- 2. • • • • MANAGING SPRINTS WITH PREDICTIVE METRICS BIOGRAPHY JOHN CARTER John Carter is Principal of TCGen Inc. and currently serves on the Board of Directors of Cirrus Logic (CRUS). He co-authored “Innovate Products Faster” with Jeanne Bradford, a visual handbook on tools for teams 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. He earned his MS in electrical engineering from MIT. 2
- 3. MANAGING SPRINTS WITH PREDICTIVE METRICS AGILITY CASE STUDIES - SUCCESS STORIES • Shortening of internationalization of software from 11 months down to 1 month • Reducing time to release from every 8 months down to every 2 months • 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 over a dozen participants 2/11/2014 3
- 4. MANAGING SPRINTS WITH PREDICTIVE METRICS cPrime & TCGen 2014 Agility Study • Kevin Thompson and John Carter plan a study Agile/Scrum can be applied outside software • We are also exploring the best practices found in coordinating multiple Agile projects • We will use this Webinar TODAY to recruit qualified study participants • If you have had experience in these areas we would like to talk to you! • There is no charge for participation and you will receive an in depth participant report • Participation will require 1-2 hours of time • We will follow up at the end of this talk and ask for participants Are you interested? 2/11/2014 4
- 5. MANAGING SPRINTS WITH PREDICTIVE METRICS 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 2/11/2014 5
- 6. Freeze the Specs and Don’t Look Back 2/11/2014 MANAGING SPRINTS WITH PREDICTIVE METRICS HOW IS AGILE DIFFERENT FROM WATERFALL? Develop Fast, Learn, Improve 6
- 7. 7 2/11/2014 MANAGING SPRINTS WITH PREDICTIVE METRICS KEY AGILE & DEVELOPMENT TERMS
- 8. 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 MANAGING SPRINTS WITH PREDICTIVE METRICS AGILE MANIFESTO – HARD TO DO IN SYSTEMS? Software Specific 10. Continuous delivery of valuable software 11. Deliver working software frequently 12. Working software is the measure of progress 75% of the Agile Manifesto CAN apply to development of any type 2/11/2014 http://agilemanifesto.org/ 8
- 9. MANAGING SPRINTS WITH PREDICTIVE METRICS SCRUM METHODOLOGY – BEST PRACTICES The most common implementation of the Agile Manifesto is Scrum 2/11/2014 9
- 10. MANAGING SPRINTS WITH PREDICTIVE METRICS AGILE METHODOLOGY – BEST PRACTICES Question: What are the most impactful elements of Agile/Scrum applied to SW? The top Four Scrum practices can be applied to Systems too! 2/11/2014 10
- 11. Question: What are the most impactful elements of Agile/Scrum applied to Products/Systems? Three of the top “Agile” practices in Systems have little to do with Scrum 2/11/2014 11 MANAGING SPRINTS WITH PREDICTIVE METRICS AGILE METHODOLOGY –APPLIED TO HW/SYSTEMS
- 12. MANAGING SPRINTS WITH PREDICTIVE METRICS AGILE METHODOLOGY –APPLIED TO HW/SYSTEMS So why is applying Agile/Scrum to HW/Systems so hard? 2/11/2014 12
- 13. MANAGING SPRINTS WITH PREDICTIVE METRICS AGILE METHODOLOGY –APPLIED TO HW/SYSTEMS Because Agile/Scrum is hard It requires higher process literacy And greater cross functional teamwork skills For more sophisticated teams; not for the faint of heart 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 2/11/2014 13
- 14. MANAGING SPRINTS WITH PREDICTIVE METRICS FIRST, APPLY THE FOLLOWING CULTURAL ASPECTS 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 AND… • Accept the fact that requirements may change You might just say that this is just common sense! 2/11/2014 14
- 15. 1. 2. 3. 4. 5. 2/11/2014 MANAGING SPRINTS WITH PREDICTIVE METRICS THEN, TRANSLATE SCRUM TO WATERFALL User Stories into Boundary Conditions Burn-down charts into Deliverable Hit Rate Sprint into HW intervals Manage the project with Out of Bounds Process Sprint Retrospectives into Event Timeline Retrospectives 15
- 16. MANAGING SPRINTS WITH PREDICTIVE METRICS HOW TO SYNCHRONIZE AGILE SW TO PRODUCTS/SYSTEMS Side note Target HW integrations to Sprint End Points • If HW schedules move, target Sprint n+1 or Sprint n+2 Place SW engineers close to metal on HW team to shield SW Use emulation/simulation extensively to buffer the HW/SW interface • PC’s to simulate mobile devices • Custom Sprints to develop emulators And when all else fails…use a very good Project Manager 2/11/2014 16
- 17. MANAGING SPRINTS WITH PREDICTIVE METRICS 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! http://www.mountaingoatsoftware.com/topics/user-stories 17
- 18. 2/11/2014 MANAGING SPRINTS WITH PREDICTIVE METRICS 1. EXAMPLE BOUNDARY CONDITIONS 18
- 19. MANAGING SPRINTS WITH PREDICTIVE METRICS 1. EXAMPLE BOUNDARY BREAK • Deliverable Hit Rate too Slow! • Key Engineer pulled! • Three week delay! 2/11/2014 19
- 20. MANAGING SPRINTS WITH PREDICTIVE METRICS 2. TRANSLATE BURNDOWNS INTO DELIVERABLE HIT RATE Identify the key requirements that should be satisfied during an interval • Can be features implemented • Can be tests validated • Can be tasks 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 2/11/2014 20
- 21. 2/11/2014 MANAGING SPRINTS WITH PREDICTIVE METRICS 2. TRANSLATE BURNDOWNS INTO DELIVERABLE HITRATE 21
- 22. MANAGING SPRINTS WITH PREDICTIVE METRICS 2. EXAMPLE OF PCB LAYOUT PROGRESS Number of Unrouted Nets 1400 1200 1000 800 600 400 200 0 1-Aug 2-Aug 3-Aug 4-Aug 5-Aug 6-Aug 7-Aug 8-Aug 9-Aug 10-Aug • 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 Example how a Burn Down Chart can be applied to see the progress in turning a schematic into a layout 2/11/2014 22
- 23. MANAGING SPRINTS WITH PREDICTIVE METRICS 3. TRANSLATE SPRINT INTO HW INTERVALS Divide the project into the smallest increment possible that represents TRUE INTEGRATION POINTS or CLEARLY DEFINABLE MILESTONES. 2/11/2014 23
- 24. MANAGING SPRINTS WITH PREDICTIVE METRICS 3. TRANSLATE SPRINT INTO HW INTERVALS Continuous learning, short intervals, measurable progress, autonomy The secret to getting the benefits of Agile development is to shed features and not slip the interval 2/11/2014 24
- 25. 2/11/2014 MANAGING SPRINTS WITH PREDICTIVE METRICS 4. BOUNDARY CONDITION PROCESS 25
- 26. MANAGING SPRINTS WITH PREDICTIVE METRICS 5. EVENT TIMELINES AND RETROSPECTIVES Don’t use Post Mortem Case Study 2/11/2014 26
- 27. MANAGING SPRINTS WITH PREDICTIVE METRICS RETROSPECTIVES • Retrospectives should be carried out on all programs • The retrospectives should follow a common process which has the following attributes • Fact based, and data driven • 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 2/11/2014 27
- 28. MANAGING SPRINTS WITH PREDICTIVE METRICS AGILE – BEST PRACTICES FOR HW/SYSTEMS Study Participation 1. If you have had experience with the application of Agile/Scrum/Iterative development out of software environments… OR 2. If you have had experience with governance of multiple Agile/Scrum programs we would like to talk to you! Please respond positively to our poll… “Are you interested in participating in an Agile Best Practices Study?” 2/11/2014 28
- 29. After the webinar… • We will send directions to collect the PDU you will earn from attending this webinar • We will also send a links to the recorded webinar and presentation slides once they are posted online For more information, visit www.cprime.com
- 30. MANAGING SPRINTS WITH PREDICTIVE METRICS AGILE – BEST PRACTICES FOR HW/SYSTEMS Thank You! 2/11/2014 30
- 31. MANAGING SPRINTS WITH PREDICTIVE METRICS AGILE – BEST PRACTICES FOR HW/SYSTEMS Appendix 2/11/2014 31
- 32. 2/11/2014 MANAGING SPRINTS WITH PREDICTIVE METRICS ANOTHER APPROACH: WATER-SCRUM-FALL 32
- 33. 2/11/2014 MANAGING SPRINTS WITH PREDICTIVE METRICS 3. THE FIVE KEY ELEMENTS OF AGILITY 33
- 34. MANAGING SPRINTS WITH PREDICTIVE METRICS 4. BOUNDARY CONDITION PROCESS • What is the Tool? Used to realign teams when a project has gone out of bounds help course correct and realign to a new plan • Which Business Problems Does the Tool Solve? Is an effective recovery vehicle when projects run into trouble Creates mechanism to quickly align project and management teams Eliminates creating an exception-handling process each time a deviation occurs • Benefits Helps you realign projects within hours/days, not days/weeks Empowers the team to move forward with minimal guidance Minimizes team confusion by establishing a single agreedupon limits Engages the team because of the greater trust by management 2/11/2014 34
- 35. MANAGING SPRINTS WITH PREDICTIVE METRICS AGILE – BEST PRACTICES FOR HW/SYSTEMS Side note 1. User Stories needed to make the best tradeoffs 2. Plan to have multiple DVTs that involve the customer 3. Build multiple variants in DVTs (buttons, PCB layouts, Firmware) 4. If lead time is 6 months and you need to go to market in 4, ask for their buffer stock 5. Use reference designs & allocate BOM choices to supplier 6. The entire team must be 'Agile' for it to work 7. Rely on Postponement 2/11/2014 35
Notas del editor
- Have you wondered if and how you can apply Agile techniques to your projects when either: They don’t’ seem to be suitable, OR you don’t know where to start?It is not All in All or Nothing!THIS PRESENTATION IS THE FIRST STEP TOWARDS UNIFIYING AN APPROACH TO APPLY SCRUM METHODS TO SYSTEMS & HARDWARELOVE this TOPIC – Technical Management
- I enjoy technology management and have many scars from leading technology development and also experience with innovation.Many great ideas nearly go into the waste basket as the Noise Cancelling Headphone, but after marketing it to the private aviation market, it worked its ways into the consumer market.
- For this talk we performed a study involving nearly 20 companies in North America, most in Silicon Valley, and most are technology companies (except Melt)Even in the context of this study, I found many instances of dramatic successes, so there are some real benefits of the application of Agile methods in pure software.However, this should not be overstated --- one case study indicated that they have never seen improvement in speed – BUT dramatic increases in code quality AND less burnoutSpent more time working on code that actually shippedHow was the study performed: 4 Questions, limit to 30 minutes on the phone, deep probing.1 . How long and how successful has your experience with Agile software development?2. What techniques have you seen that makes the biggest impact with implementation of the Agile SW process?3. How do you interface your Agile process with non-Agile programs (either larger SW platforms or Hardware)?4. What techniques have you seen pulled from Agile SW development process and applied to Hardware or Waterfall SW development?
- We would love for you to participate… but you need to to have been successful in your Agile implementation
- Our research found there may be a simple path forward, that does not involve a lot of heavy processThe importance of soft skills can not be under emphasized!
- The fundamental differences are obvious from a big picture – but the subtilities are not shown! You have seen these types of diagrams many times… what is the essence? ITERATIONDeliver working software frequently! - this ensures you focus on shipping codeCan accommodate frequent change in requirements because you simply manage when and how stories are planned in sprints
- Agile – overlying spiritBacklog – work to be doneBurn-down – chart showing how units of work are completed over timeAgile Manifesto – Key principles on which various Agile methods are builtSprints – 2-4 week intervals where a complete SW cycle is performedScrum – one of the most popular Agile embodiments
- 9 out of 12, 75% have nothing to do with software and can be applied to almost any type of developmentMany of these items have their roots in good design methodology OR best practices in teaming
- The Scrum best practice has many elements that map into Agile Manifesto componentsBacklog Grooming – prioritizing stories to go into the next sprintSprint Planning – planning how many stories can fit into a sprintSizing Methods – Fruit, Fibonacci Series
- We asked our survey respondents, in their experience, what did they see was the most impactful elements of SCRUM to their programs.This chart is a frequency of occurrence chart, where we scoured the verbatim interview notes and counted mentions.AMAZING, without prompting, the top four really have nothing per se to do with the CORE of the SCRUM itself, which are the Sprints themselves.(I would even say the top SIX… well even the top SEVEN, and with modification, ALL can be applied to SYSTEMS TOO!Greenhopper is a tool to manage Agile development (now called JIRA Agile – By Atlassian)
- We asked the respondents, what have they seen in their application to non-software work. Although we ASKED specifically to draw from SCRUM, the respondents tended to draw out specific best practices outside SCRUM Note ALL had experience with this, indicating that there is some dabbling in this area. It was interesting to note that the most frequent mentioned are really not from SCRUM, although that was what was asked… HOWEVERThey are good best practices that should be added to the SCRUM for SYSTEMS methodology.
- We have just seen in our study, that leading firms are beginning to experiment with agilityBut it is rare. So is there something intrinsic that FUNDAMENTALLY prevents the application of SCRUM?NO!
- Of course it is easier to break SW down to sprints because of the inherent reproducibility to scale of SWBut as you have seen there is nothing fundamental to apply many of the principles to HWIt just requires discipline and fortitude
- Lets start with the basics of Scrum (and what came out of our study). It is all about a TEAM BASED CULTURE based on TRUST AND EMPOWERMENT.Daily Standups are controversial – in our study some said that it really worked well in HW/Systems, others said no, because HW is too slow. Use discretion.We could end the talk here, and you would get THREE OF THE TOP FOUR Scrum elements that move the needle.BUT we will not stop now, because we have some really cool best practices to talk about.
- This is the unified theory of applying SCRUM to SystemsThe hardest step is step three. We will give you some guidance on how to do this.
- The third point - One of the most frequent examples were in consumer tech where desktops simulated android/Linux widgets – IE do Hardware in SW and apply the sprint methodology to the SW. CASE STUDY – First sprint of one company was to build the HW emulator in SW so more of the development could be ScrumNot jokingly, one respondent said this is really hard… and a good project manager can make a difference
- Two of the best pracices that can reinforce the TEAM CULTURE – BC’s and the OOB ProcessProduct Attributes are User Stories, that need to be translated into requirements, which get translated into a product specification.As a casual fitness enthusiast, I want to see how many steps I have walked in a day, in order to get feedback on my daily exercise planTranslates into product spec of creating a readable display at 4’, in ½ a second, with one button push.
- These can be put into the boundary diagram as three sides – Display; SW performance speed, and a one button push UI.In a early HW sprint this might be Select a display; select a microcontroller fast enough, Develop UI screen shotsIn middle HW sprint this might be verify display viewability, benchmark verify the prototype, perform Usibility studiesIn the later HW sprint it might be verify display reliability, verify actual production system performance, confirm product with finished product testing
- Example Boundary Break – to be solved by OOB process. Stay tuned!
- You would think that burn down rate for SW (the rate at which progress is made by satisfying requirements – stories are measured by story points) CAN NOT be applied to your projects. It can, it just requires more creativity. Also, you may have to vary it by sprint.
- One of the most typical ways is to map out tasks in the next interval of development. Over an average of a large number of tasks, they can be predicted to have some average value. And they must all be completed in a sprint. So linearly spread them out.Equivalent of a burn down chart in SW.Can also do this at beginning for RequirementsSTART – Requirements burn downMIDDLE – Deliverable Hit RateEND – Verification of Requirements
- Background – designing a watch, had remote design team doing HWProgress to lay out PC board is to use SW to round the tracesConvert a schematic diagram (network diagram) into a layoutSo what percentage of the network paths have been converted from a schematic to the PC trace layout, out of 1200 connections?Case study of one survey participant. Short program – just over a two week period.
- This is the hardest best practice, IMOModification is that some companies divide up the middle intervals into multiple sprints if the time line looks longer – typical by segmenting by HW integration maturity… Functional Mockup, Works like, looks like model, Pre Production Sample. These burn down charts would be deliverable hit rates.CASE STUDY - DVTx, keep doing builds until it is right – it costs more, but it yields a higher quality product.CASE STUDY – Overlapping builds where you start the next build before the predecessorDVTx, keep doing builds until it is right, like co X.
- Shown is a typical set of management milestones for a product development processFor a 12 month development timeframe, there might be five sprints shown by the arrows between the milestones, which translates into 10 weeks per ‘sprint’ which is about twice as long as a 4 week sprint.There is a balance between the sprint length and overhead, I would recommend you begin here.
- The OOB process fits hand in glove with the BCs.When, during a sprint, a boundary is broken – or you will knowingly cross it in the near future, you call a boundary breakOnce the team agrees that a boundary is broken, do they know what to do, and if so will management likely accept – NOTIFYIf they don’t know what to do OR know management management may need to move a boundary, the – MEET, DISCUSS, AND DECIDEAND THEN MOVE ON… DON’T STALL
- The last best practice is a way to perform a retrospective of a sprint – what went well and what did notFrom the Manifesto “At regular intervals, the team reflects”Three key elements, typically takes the better part of a day, and involves the core team 8-12 people1 hour, 3 hours, 2 hours is typical breakdownPlanned events, unplanned eventsFishbone diagrams, Ichikawa diagrams – the drawings like fishbones depict the root cause analysis process of asking why five times
- This is not a post mortem, but a mid-mortemKeep online in a data base, have cross team learningFirst started this at Apple many years ago as part of the ANPPReally is the tool for empowermentIf the team has a clear contract at the beginning of a sprint, then they have the assurance they will be notified when the team runs into a rough patch = TRUSTThis EMPOWERS the team, and frees management from MEDDLINGAnd it shortens decision making time.
- PCB layouts are used for RF testing (black magic/art)Firmware for multiple User Interface options
- In this talk, I hope that I have inspired you with the possibility that you CAN apply Agile methods to your projectsI hope you have learned that it is NOT all or nothingAnd I hope that you have learned JUST ONE NEW THING that you can apply to your programs when you return to your team on WednesdayThank you for your time
- Extra Charts
- Many, many companies use this approach. Kind of s Scrum Sandwich. You get some of the benefits, but not all. Can this method be applied to HW & Systems?
- This is the schematic of how the various best practices weave together
- As a bonus from the talk,In the research we picked up on the following 7 additional best practices that you might apply to your programs.User stories allow engineers to look behind the requirementsHave customers involved in the middle of developmentExpensive, but build variantsIn tight part areas – memory for example, ask suppliers to advance you some of the buffer stock – you only need to satisfy the first month of production, say and for many companies that are starting up, they don’t demand the quantity that larger companies demandPCB layouts are used for RF testing (black magic/art)Delegate choices to partnersNeed all functions to buy into Agile paradigm, not just engineering or just operations, but every core team functionFirmware for multiple User Interface options, and then you can make your final choice when you pack in a local distribution center (where you ‘postpone part of the production’)PCB layouts are used for RF testing (black magic/art)Firmware for multiple User Interface options