Agile programmanagement

  • 1,868 views
Uploaded 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

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

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,868
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
58
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Agile Program Management:Managing Risks and Business Value 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 ManagementOrganizing and coordinating several projects’ results intoone deliverable. That deliverable has the value to theorganization 2 © 2011 Johanna Rothman
  • 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. 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. 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. What About Your Teams? 6 © 2011 Johanna Rothman
  • 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. 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. 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. 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. 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. One Approach to Programs I’ve Used for Decades (Not Agile) 12 © 2011 Johanna Rothman
  • 13. Organizing the Program 13 © 2011 Johanna Rothman
  • 14. Program Management of Concurrent Projects: Core Team 14 © 2011 Johanna Rothman
  • 15. Communication Problems on a Program 15 © 2011 Johanna Rothman
  • 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. Program Management of Concurrent Projects:Technical Team 17 © 2011 Johanna Rothman
  • 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. 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. Backlog and Architecture 20 © 2011 Johanna Rothman
  • 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. 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. 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. 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. Product Backlog Burnup Chart 25 © 2011 Johanna Rothman
  • 26. Thermometer May Work 26 © 2011 Johanna Rothman
  • 27. Last vs. MostResponsible Moment 27 © 2011 Johanna Rothman
  • 28. Product Delivery and Architecture Decisions 28 © 2011 Johanna Rothman
  • 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. 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 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 30 © 2011 Johanna Rothman