PMO?

A very common question you get is what do a PMO and Project Managers do in a agile world. The development team is self-managing, the Product Owning owns the backlog and each team should include both dev and QA. So we are done right? Time to update the résumé…

My retort is that there is a lot that a PMO can bring even when Development is humming along in a perfect agile process. Here is a short but high value list to start the conversation:

  • Strategy
  • Reporting
  • Release Manager

Strategy

One of the primary tenets of Agile is that the team should be working on the highest possible work at the present and the Product Owner should be sorting the backlog accordingly. Even if your product owners/teams are functioning at the highest level, one of the challenges to most companies is that they are still siloed by product. So a team could be working on a medium or low priority set of stories in one product when they could be working on another product with much higher priorities for the company. The idea is that you align at the portfolio level rather than the product level. The PMO’s job is to answer this question

What is the best use of our time to the company?

Once we have that answered and assuming the teams are aligned on sprint length and start/stop dates, Product Owners and teams can attack what brings the most value to the company right now. To the company, this brings additional value in that many developers are no longer being siloed into one product/technology and the company has many people cross-trained in multiple projects.

Reporting

Another critical tenet of agile processes is the idea of information radiators. These should be essential for distributing information thoughout the stakeholder community and amongst the teams. Information radiators are also essential to the success of any agile implementation. Management is used to seeing metrics for project status and especially during the early stages of agile will be nervous that everything is going to go to hell in a handbasket. Information radiators provide that status comfort but I have yet to meet a scrum master/product owner who was not happy (ok one but see previous blog post) to get help with presenting metrics that were understandable. The PMO lives in the world of gathering, analyzing, and presenting metrics on project status!

The second big reporting area that the PMO can help with is risk. How is it measured, tracked, and reported. There are many different ways to present risk. My favorite is a 5 x 5 scale where 1–5 ranks severity and probability with 5 being high. Multiply the numbers together and anything over a 10 gets tracked and anything over 15 gets reported. I have found that Development can easily provide information on this scale and Management can easily understand the scale.

Release Manager

Great, the software is complete! The team should congratulate itself and probably schedule happy hour to celebrate. However while it is a significant accomplishment that the software is done, is the rest of the company ready to ship? One of the areas where most companies that adopt agile struggle is integrating the fast-paced cycles of agile with a company that has not fully adopted agile across the board. So is everyone else (Marketing, Sales, Documentation, Finance, Legal) ready to ship? Usually, the answer is no…

Here is a task that falls right into the wheelhouse of a PMO, release management. I have successfully used both MS Project and a newer, more agile product called Trello. Trello is very adept at this because unlike building an aircraft carrier, release management is less linear and more an aggregation of disparate single tasks. Trello allows everyone to filter on their tasks and statues and allows everyone constant visibility on the overall process. The PMO is more the shepard who guides the flock in the right direction.

Good references

I have done the reading so you don’t have to read the bad books. I would highly recommend these books on Agile Portfolio Management:

Picking Scrum Masters

What: Dogmatic Scrum Masters may doom your implementation

Symptoms: If you witness any of the following behaviors, you have a DSM

  • Displays limited flexibility. The DSM may be usually enthusiastic believers in scrum but they view the world through a black/white prism. The DSM may tie up scrum of scrums for hours fighting tooth and nail against the team “bastardizing” Scrum.
  • Does not hold their team accountable but fights when others do that they are “bastardizing” the team’s independence. I have witnessed a DSM who championed his team when he should have been trying to figure out why his team was repeatedly not completing stories for multiple sprints. When questioned, the DSM would vociferously defend his team from outside interference rather than try to get to the bottom of the problem.

Results: The DSM causes a triple whammy. One, they may poison their team by not holding them accountable. The team then thinks this is normal and begins to repeatedly miss commitments that they themselves had made. Second, other teams see this and it quickly spreads. Finally, upper management will also notice during sprint reviews that stories taken were not completed repeatedly. This will directly lead to upper management losing confidence in the agile implementation.

Actions: My recommendation would be to try to work with them for a sprint or two (no longer than a month to six weeks) and if you don’t see the changes that are necessary, change scrum masters. I cannot stress how corrosive this is.