agile program management

Agile Program Management: An Oxymoron?

Johanna RothmanNew: Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects

@[email protected]

781-641-4046

http://www.jrothman.com

© 2011 Johanna Rothman

Program Management

Organizing and coordinating several projects’ results into

one deliverable. That deliverable has the value to the

organization

2


Program Management of Concurrent Projects

3


Program Management of Phased Projects

4


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


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


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


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


Making Risks Transparent

Many people say, “Just do Scrum-of-Scrums”

Scrum-of-Scrums has its place, and it’s not for everyone

9


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


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


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


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


One Approach to Programs I’ve Used for Decades (Not Agile)

14


Organizing the Program

15


Communication in an Agile Team

16

Paths = (N(N-1)/2


Communication Problems on a Program

17


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 Rothman19

Program Organization


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


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


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


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


Backlog and Architecture

24


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


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 Picture26


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


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


Product Backlog Burnup Chart

29


Thermometer May Work

30


Last vs. Most Responsible Moment

31

© 2011 Johanna Rothman32

Typical Product Delivery Mechanism

Cost of delivery or

update

User Involvement with release

User involvement with update

When to make architecture decisions

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 field

Low to manageable

0 Minimal Last responsible moment, but not later

Hardware or other difficult-to-upgrade product High Varies Significant

As early as responsible because of program risks

(development and delivery)

Product Delivery and Architecture Decisions


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


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

http://www.jrothman.com

http://www.jrothman.com/pragmaticmanager

http://www.jrothman.com/pragmaticmanager

agile program management

Technology