This document provides an overview of applying agile project management practices to hardware and systems development. It begins with biographies of the authors and case studies where agile methods improved software development. It then discusses challenges applying agile to hardware with long lead times. Key practices discussed include using short intervals with feedback, translating user stories and burn-downs to hardware, and managing projects with boundary conditions and out of bounds processes. The document provides examples and outlines adapting scrum practices like sprints, planning and retrospectives for hardware development.

1. 1
AGILE PROJECT MANAGEMENT IN A
WATERFALL WORLD MANAGING SPRINTS
WITH PREDICTIVE METRICS
John Carter, Jeanne Bradford
June 2014

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. 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. 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. 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. 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. 77
KEY AGILE & DEVELOPMENT TERMS
Agile
Backlog
Burn-Down
Daily Standups
Scrum
Scrum Masters
Sprints
User Stories
Waterfall

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. 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. 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. 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. 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. 1313
AGILE METHODOLOGY – APPLIED TO HW/SYSTEMS
So why is applying Agile/Scrum
to HW/Systems so hard?

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. 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. 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. 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. 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. 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. 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. 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. 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. 2323
BURN DOWN METRICS FOR HYBRID DEVELOPMENT
Concept
Program Approved
High Level Design
Detailed Design
Design Validation
Production
Requirements
Design
Test

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. 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. 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. 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. 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
Thank you

30. 30
TCGen Inc.
Menlo Park
CA, 94025
jcarter@tcgen.com
(650) 733-5310