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
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
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
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
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
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
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
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 do 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