Agile programmanagement


Published on

At Oredev 2011, I had a chance to talk to the Sweden PMI group (at least, the Malmo section of the Sweden PMI). I gave my updated talk on Agile Program Management

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile programmanagement

  1. 1. Agile Program Management:Managing Risks and Business Value Johanna Rothman New: Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects @johannarothman 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. 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 3 © 2011 Johanna Rothman
  4. 4. 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 testsAgile or lean reduces overall project risk 4 © 2011 Johanna Rothman
  5. 5. What Kind of Program Are You Working On?Who here is working on a program? Up to 3 teams? 4-7 teams? More than 7 teams? 5 © 2011 Johanna Rothman
  6. 6. What About Your Teams? 6 © 2011 Johanna Rothman
  7. 7. Making Risks TransparentMany people say, “Just do Scrum-of-Scrums” Scrum-of-Scrums has its place, and it’s not for everyone 7 © 2011 Johanna Rothman
  8. 8. 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 8 © 2011 Johanna Rothman
  9. 9. 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 9 © 2011 Johanna Rothman
  10. 10. 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 10 © 2011 Johanna Rothman
  11. 11. Dirty Little Secret of Program ManagementIf you’ve ever managed programs successfully, you have used “agile”approaches: Timeboxes 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 11 © 2011 Johanna Rothman
  12. 12. One Approach to Programs I’ve Used for Decades (Not Agile) 12 © 2011 Johanna Rothman
  13. 13. Organizing the Program 13 © 2011 Johanna Rothman
  14. 14. Program Management of Concurrent Projects: Core Team 14 © 2011 Johanna Rothman
  15. 15. Communication Problems on a Program 15 © 2011 Johanna Rothman
  16. 16. Team Size MattersCommunication Paths=(N*N-N)/24 people, (16-4)/2=65 people, (25-5)/2=106 people, (36-6)/2=157 people, (49-7)/2=218 people, (56-8)/2=249 people, (81-9)/2=3610 people (100-10)/2=45 16 © 2011 Johanna Rothman
  17. 17. Program Management of Concurrent Projects:Technical Team 17 © 2011 Johanna Rothman
  18. 18. 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 18 © 2011 Johanna Rothman
  19. 19. 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 19 © 2011 Johanna Rothman
  20. 20. Backlog and Architecture 20 © 2011 Johanna Rothman
  21. 21. 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 works with its product owner to selects its backlog items from the product backlog (no cherry-picking the backlog) Each team estimates and commits Each team builds their iteration’s backlog, with the local architect as a regular member of the team Continuous integration 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 21 © 2011 Johanna Rothman
  22. 22. 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 22 © 2011 Johanna Rothman
  23. 23. 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 23 © 2011 Johanna Rothman
  24. 24. 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 24 © 2011 Johanna Rothman
  25. 25. Product Backlog Burnup Chart 25 © 2011 Johanna Rothman
  26. 26. Thermometer May Work 26 © 2011 Johanna Rothman
  27. 27. Last vs. MostResponsible Moment 27 © 2011 Johanna Rothman
  28. 28. Product Delivery and Architecture Decisions 28 © 2011 Johanna Rothman
  29. 29. 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!! 29 © 2011 Johanna Rothman
  30. 30. References and ReadingLook for my upcoming book, tentatively titled Agile and LeanProgram Management: Collaborating Across the OrganizationManage It! and Manage Your Project Portfolio have a number ofhow-to’s on programs Tons more on 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 30 © 2011 Johanna Rothman