The Program Office on a diet

LYSSA ADKINSAUGUST 30, 2007

As I move further into the world of Agile, I reflect on my previous lives as a manager of program, project and portfolio offices and I’ve been thinking a lot about program offices, in specific, lately.You know, a program – that thing with a big scope and vision that needs several projects under it to carry out the work.That’s the kind of program I’ve been contemplating.

If the projects “under it” are now run using Agile and those are high-performing teams delivering value often, what’s the job of the program?It used to be schedule management, resource management, contract management, scope management, interdependency management, change management and on and on with a bunch of phrases that all end in the word “management.”  I think there are still many worthwhile jobs the program can offer, so don’t imagine me carrying a placard reading, “Abolish all Program Offices, Now!”That’s not what I’m saying and maybe my next blog will be about all those worthwhile services, just to prove it to you.

In the meantime, here are some things I’m pretty sure should be very thin or non-existent in an Agile Program Office:

• Risks and Issues Management
• Lessons Learned
• Interdependency Management

Built into the fabric of Agile teams is the immediate identification and removal of impediments (impediment = risk or issue).Agile has you covered there.Same with lessons learned.Agile’s built-in Retrospectives (which I like to call Lessons Learned, but with a purpose) ensure the team is learning.No more does the program office have to beg the team to “capture” lessons learned.Interdependencies are also covered by Agile practices.If an interdependency no one saw coming arises in a sprint, it’s an impediment.Otherwise, the product owner uses the product backlog and release plan to anticipate and smooth-over future interdependencies.Gotcha covered.

So, what does the Program Office do instead?First of all, spend your main effort ensuring you have healthy Agile teams.  If so, then maybe instead of “managing” these things the program can be primed and ready to move with lightening speed to help bulldoze impediments the team can’t resolve themselves (IF the team asks for help). With interdependencies, help the product owner understand any at the program level and be aware (but not vigilantly watching for) the possibility of gaps between the project teams.In general, though, trust that interdependencies are being handled and give the teams that respect.For lessons learned, do nothing.Lessons learned are not all that usable between teams anyway and if one team thinks they have a great lesson learned, they will likely tell people on other teams because healthy Agile teams can’t keep themselves from sharing.

This is one person’s opinion.Would love to hear yours.