Agile Program Management:       An Oxymoron?                                                  Johanna Rothman New: Manage ...
Program ManagementOrganizing and coordinating several projects’ results intoone deliverable. That deliverable has the valu...
Program Management of   Concurrent Projects          3          © 2011 Johanna Rothman
Program Management of Phased          Projects             4         © 2011 Johanna Rothman
Programs Are Riskier Than ProjectsYou all know that projects don’t scaleThe larger and the longer the program, the more ri...
What Kind of Program Are You          Working On?Who here is working on a program?  Small software-only or software/firmwar...
Why Use Agile For Programs?Agile provides fast feedback  You know where you are every iterationTimeboxes provide urgency a...
What About Your Teams?All the teams are cross-functional and collocated teamsAll the teams are cross-functional and they a...
Making Risks TransparentMany people say, “Just do Scrum-of-Scrums”  Scrum-of-Scrums has its place, and it’s not for everyo...
Traditional Program ManagementProgram team   Software program manager (person who program manages all the software teams) ...
How Agile Changes Program           ManagementTeams commit, not functional managersProduct owners manage the what-to-build...
Issues in Program ManagementEspecially in concurrent projects, how do you manage, what do youmanage when you have 4, 7, 18...
Dirty Little Secret of Program              ManagementIf you’ve ever managed programs successfully, you have used “agile”a...
One Approach to Programs I’ve Used for Decades (Not Agile)              14        © 2011 Johanna Rothman
Organizing the Program           15            © 2011 Johanna Rothman
Communication in an Agile TeamPaths = (N(N-1)/2                    16   © 2011 Johanna Rothman
Communication Problems on a        Program             17         © 2011 Johanna Rothman
Managing Status, Risks,          Architecture, BacklogS-o-S works for small programs, of up to, say, 7 teams. Whatabout mo...
Program Organization         19            © 2011 Johanna Rothman
Collecting Groups for Representation         to the Program Team Several software reps to the program team   Gather some r...
Program ManagementAt the program level, need   Program manager   Program architect   Program product owner   Anyone else n...
Starting an Agile ProgramIteration 0: Do you need one?What you need to start an agile program:  Charter (vision, release c...
Program ManagersGenerate the program charterStart the drumbeat for the programCreate and update landing zonesMake sure the...
Backlog and Architecture           24          © 2011 Johanna Rothman
For Each Iteration (Part 1)All start and end at the same time for each team (No staggered iterations)   Normal agile for t...
For Each Iteration (Part 2)Program team   Potential of a daily standup (think Scrum of Scrums)   Meets weekly to manage ri...
When You Have HardwareNothing changes until you have pilot hardware  If the teams have only been getting to “demo-able” at...
Make the Program’s Progress VisibleAgile makes the product visible as you proceed  You have to think about what you want f...
Product Backlog Burnup Chart             29         © 2011 Johanna Rothman
Thermometer May Work         30        © 2011 Johanna Rothman
Last vs. MostResponsible Moment         31          © 2011 Johanna Rothman
Product Delivery and Architecture                     Decisions                                Cost of          User      ...
Program Management is DifficultAgile provides transparencyUse a combination of techniques, and move to agile as you canNo m...
References and ReadingManage It! and Manage Your Project Portfolio have a number of how-to’s onprograms  Tons more on jrot...
Upcoming SlideShare
Loading in...5
×

Agile Program Management

2,047

Published on

Scaling a

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,047
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
104
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Agile Program Management

  1. 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. 2. Program ManagementOrganizing and coordinating several projects’ results intoone deliverable. That deliverable has the value to theorganization 2 © 2011 Johanna Rothman
  3. 3. Program Management of Concurrent Projects 3 © 2011 Johanna Rothman
  4. 4. Program Management of Phased Projects 4 © 2011 Johanna Rothman
  5. 5. Programs Are Riskier Than ProjectsYou all know that projects don’t scaleThe larger and the longer the program, the more risky it isThe 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. 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. 7. Why Use Agile For Programs?Agile provides fast feedback You know where you are every iterationTimeboxes provide urgency and focusIt’s clear early if anyone is having troubleIt’s clear early if the architecture is not going to work,assuming you use good tests 7 © 2011 Johanna Rothman
  8. 8. What About Your Teams?All the teams are cross-functional and collocated teamsAll the teams are cross-functional and they are geographicallydistributedSome teams are cross-functional. Some people are dispersedAll people are organized by function and all people are collocated.All people are organized by function and all are distributed ordispersed.My program is something else 8 © 2011 Johanna Rothman
  9. 9. Making Risks TransparentMany people say, “Just do Scrum-of-Scrums” Scrum-of-Scrums has its place, and it’s not for everyone 9 © 2011 Johanna Rothman
  10. 10. Traditional Program ManagementProgram 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 managerAnyone else you need who can Speak for that function Commit people Manage risks Commit other resources 10 © 2011 Johanna Rothman
  11. 11. How Agile Changes Program ManagementTeams commit, not functional managersProduct owners manage the what-to-build riskThe teams manage The how-do-we-build-our-features risk Collecting and explaining their statusProgram management Helps make the between-teams risks transparent Collects and explains program status 11 © 2011 Johanna Rothman
  12. 12. Issues in Program ManagementEspecially in concurrent projects, how do you manage, what do youmanage when you have 4, 7, 18, 25 teams of people all working on thesame 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. 13. Dirty Little Secret of Program ManagementIf 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. 14. One Approach to Programs I’ve Used for Decades (Not Agile) 14 © 2011 Johanna Rothman
  15. 15. Organizing the Program 15 © 2011 Johanna Rothman
  16. 16. Communication in an Agile TeamPaths = (N(N-1)/2 16 © 2011 Johanna Rothman
  17. 17. Communication Problems on a Program 17 © 2011 Johanna Rothman
  18. 18. Managing Status, Risks, Architecture, BacklogS-o-S works for small programs, of up to, say, 7 teams. Whatabout more teams? There are too many people for a daily standup Possibly too many risks for the program team to manageNeed to collect software risks (or any other group of teamsthat’s relatively independent) as a delegate to the programteam 18 © 2011 Johanna Rothman
  19. 19. Program Organization 19 © 2011 Johanna Rothman
  20. 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. 21. Program ManagementAt 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. 22. Starting an Agile ProgramIteration 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. 23. Program ManagersGenerate the program charterStart the drumbeat for the programCreate and update landing zonesMake sure there is a feature roadmapDecide about technical debtWatch for failure points Multitasking Design that’s too far ahead Testers too far behind Frameworks without features 23 © 2011 Johanna Rothman
  24. 24. Backlog and Architecture 24 © 2011 Johanna Rothman
  25. 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. 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 velocityArchitecture 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. 27. When You Have HardwareNothing 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. 28. Make the Program’s Progress VisibleAgile 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. 29. Product Backlog Burnup Chart 29 © 2011 Johanna Rothman
  30. 30. Thermometer May Work 30 © 2011 Johanna Rothman
  31. 31. Last vs. MostResponsible Moment 31 © 2011 Johanna Rothman
  32. 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 updateSoftware as a Service (SaaS) Negligible 0 0 As late as responsible Boxed (Shipped) software Minimal 0 Total As late as responsibleFirmware upgradeable in the Low to Last responsible moment, 0 Minimal field manageable but not later As early as responsibleHardware or other difficult- High Varies Significant because of program risks to-upgrade product (development and delivery) 32 © 2011 Johanna Rothman
  33. 33. Program Management is DifficultAgile provides transparencyUse a combination of techniques, and move to agile as you canNo 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. 34. References and ReadingManage It! and Manage Your Project Portfolio have a number of how-to’s onprograms 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×