This document discusses managing programs using agile principles. It begins by defining a program as organizing several projects' results into a single deliverable. It then addresses some challenges of program management, such as risks increasing with program size and complexity. It proposes using agile approaches like timeboxing, iterative delivery, and transparency to help program management. Specific topics covered include organizing teams, communication challenges, and managing backlogs, architecture, risks and status across multiple teams. The document provides examples of organizing teams and information flow for larger programs. It emphasizes the role of the program manager in coordinating teams while allowing autonomy.

1. Agile Program Management:
An Oxymoron?
Johanna Rothman
New: Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
@johannarothman
www.jrothman.com
jr@jrothman.com
781-641-4046

2. Program Management
Organizing and coordinating several projects’ results into
one deliverable. That deliverable has the value to the
organization
2 © 2011 Johanna Rothman

3. Program Management of
Concurrent Projects
3 © 2011 Johanna Rothman

4. Program Management of Phased
Projects
4 © 2011 Johanna Rothman

5. Programs Are Riskier Than Projects
You all know that projects don’t scale
The larger and the longer the program, the more risky it is
The more pieces the program has, the more risky it is
Hardware and software
Mechanical and hardware and software
Embedded and hardware and software
Regulated industries
5 © 2011 Johanna Rothman

6. What Kind of Program Are You
Working On?
Who here is working on a program?
Small software-only or software/firmware program (3 teams
or fewer)
Small software/hardware program (3 teams or fewer)
Large software-only or software/firmware program (more
than 3 teams)
Large software/hardware program (more than 3 teams)
Something else?
6 © 2011 Johanna Rothman

7. Why Use Agile For Programs?
Agile provides fast feedback
You know where you are every iteration
Timeboxes provide urgency and focus
It’s clear early if anyone is having trouble
It’s clear early if the architecture is not going to work,
assuming you use good tests
7 © 2011 Johanna Rothman

8. What About Your Teams?
All the teams are cross-functional and collocated teams
All the teams are cross-functional and they are geographically
distributed
Some teams are cross-functional. Some people are dispersed
All people are organized by function and all people are collocated.
All people are organized by function and all are distributed or
dispersed.
My program is something else
8 © 2011 Johanna Rothman

9. Making Risks Transparent
Many people say, “Just do Scrum-of-Scrums”
Scrum-of-Scrums has its place, and it’s not for everyone
9 © 2011 Johanna Rothman

10. Traditional Program Management
Program team
Software program manager (person who program manages all the software teams)
Hardware program manager (person who program manages all the hardware teams)
Marketing program manager
Sales program manager
Anyone else you need who can
Speak for that function
Commit people
Manage risks
Commit other resources
10 © 2011 Johanna Rothman

11. How Agile Changes Program
Management
Teams commit, not functional managers
Product owners manage the what-to-build risk
The teams manage
The how-do-we-build-our-features risk
Collecting and explaining their status
Program management
Helps make the between-teams risks transparent
Collects and explains program status
11 © 2011 Johanna Rothman

12. Issues in Program Management
Especially in concurrent projects, how do you manage, what do you
manage when you have 4, 7, 18, 25 teams of people all working on the
same product?
The issues are
Backlog management
Architecture decisions
Managing the risks, up, down, sideways
How to understand and explain status
12 © 2011 Johanna Rothman

13. Dirty Little Secret of Program
Management
If you’ve ever managed programs successfully, you have used “agile”
approaches:
Timeboxes to keep people focused
Implement by feature
Program-wide release criteria
Commit at the last responsible moment to high cost-of-change
decisions
Prototype architecture
Interim milestones
13 © 2011 Johanna Rothman

14. One Approach to Programs I’ve
Used for Decades (Not Agile)
14 © 2011 Johanna Rothman

15. Organizing the Program
15 © 2011 Johanna Rothman

16. Communication in an Agile Team
Paths = (N(N-1)/2
16 © 2011 Johanna Rothman

17. Communication Problems on a
Program
17 © 2011 Johanna Rothman

18. Managing Status, Risks,
Architecture, Backlog
S-o-S works for small programs, of up to, say, 7 teams. What
about more teams?
There are too many people for a daily standup
Possibly too many risks for the program team to manage
Need to collect software risks (or any other group of teams
that’s relatively independent) as a delegate to the program
team
18 © 2011 Johanna Rothman

19. Program Organization
19 © 2011 Johanna Rothman

20. Collecting Groups for Representation
to the Program Team
Several software reps to the program team
Gather some related teams and have them select one PM/SM to go to
the program team
One software rep to the program team
Organize the software like a program and have one overall software
program manager
Each team sends a rep to the software program team and if too many,
do some gathering
Do some hierarchical gathering of groups, based on the product features
20 © 2011 Johanna Rothman

21. Program Management
At the program level, need
Program manager
Program architect
Program product owner
Anyone else needed for the program (hardware, finance, training, sales, support, …)
For each team, need
Product owner, full time for feature sets
Depending on how long the team has been agile, maybe a project manager/Scrum
Master
< 2 years, yes!
Architect, at least part time
21 © 2011 Johanna Rothman

22. Starting an Agile Program
Iteration 0: Do you need one?
What you need to start an agile program:
Charter (vision, release criteria)
Product roadmap (so everyone sees where we are headed)
Enough of a backlog to start
Any market-driven architecture decisions
Program product owner to manage business value of the program backlog
Program architect to manage business value of the architecture
Program manager to manage program level risks
22 © 2011 Johanna Rothman

23. Program Managers
Generate the program charter
Start the drumbeat for the program
Create and update landing zones
Make sure there is a feature roadmap
Decide about technical debt
Watch for failure points
Multitasking
Design that’s too far ahead
Testers too far behind
Frameworks without features
23 © 2011 Johanna Rothman

24. Backlog and Architecture
24 © 2011 Johanna Rothman

25. For Each Iteration (Part 1)
All start and end at the same time for each team (No staggered iterations)
Normal agile for the team
Each team selects its backlog items from the product backlog
Each team estimates and commits
Each team builds their iteration’s backlog, with the local architect as a regular
member of the team
Daily standups
Each team elevates risks, issues through the PM/SM to the program team
Each team gets to release-able at the end of an iteration
If you have hardware, maybe demo-able
25 © 2011 Johanna Rothman

26. For Each Iteration (Part 2)
Program team
Potential of a daily standup (think Scrum of Scrums)
Meets weekly to manage risks and figure out how to present status
Storyboards, thermometer, product backlog burnup
Program velocity
Architecture team
Uses what each team has learned to refine the architectural picture
May decide to hold architectural reviews periodically
To prevent technical debt, not to pre-define too far
Keep refining the Big Picture
26 © 2011 Johanna Rothman

27. When You Have Hardware
Nothing changes until you have pilot hardware
If the teams have only been getting to “demo-able” at the end of an
iteration before pilot hardware, now they have to get to “release-
able”
The program will encounter problems
Be prepared to manage more risks
Be prepared to have sub-program meetings to manage the who’s
going to do what in the hardware, firmware, software
27 © 2011 Johanna Rothman

28. Make the Program’s Progress Visible
Agile makes the product visible as you proceed
You have to think about what you want for status for the program
Working product is the best
Velocity might be ok, but velocity is personal for a team
You can’t add velocities together and have a program measure
Consider product backlog burnup
28 © 2011 Johanna Rothman

29. Product Backlog Burnup Chart
29 © 2011 Johanna Rothman

30. Thermometer May Work
30 © 2011 Johanna Rothman

31. Last vs. Most
Responsible Moment
31 © 2011 Johanna Rothman

32. Product Delivery and Architecture
Decisions
Cost of User User
Typical Product Delivery When to make architecture
delivery or Involvement involvement
Mechanism decisions
update with release with update
Software as a Service (SaaS) Negligible 0 0 As late as responsible
Boxed (Shipped) software Minimal 0 Total As late as responsible
Firmware upgradeable in the Low to Last responsible moment,
0 Minimal
field manageable but not later
As early as responsible
Hardware or other difficult-
High Varies Significant because of program risks
to-upgrade product
(development and delivery)
32 © 2011 Johanna Rothman

33. Program Management is Difficult
Agile provides transparency
Use a combination of techniques, and move to agile as you can
No matter what lifecycle or combination of lifecycle you choose,
make sure you:
Have interim milestones
Demo early and often
Raise risks and resolve them
Have fun!!
33 © 2011 Johanna Rothman

34. References and Reading
Manage It! and Manage Your Project Portfolio have a number of how-to’s on
programs
Tons more on jrothman.com
If you’d like me to stay in touch with you, please sign up for my email
newsletter, fill out a yellow form, or email me
34 © 2011 Johanna Rothman