Many agile enthusiasts are completely sold to the idea of self-directing teams.
In an agile team, there is a continuous search for process improvement and reduction of wasteful activities. It is logical that they see many of the old project management procedures as waste. Take the project board for instance. Why would a product owner and scrum master want to spend 2 hours in a meeting reporting about planning, budget, scope and risks? They manage this almost every day, during their standups, planning meetings, demos and retrospectives. It feels like they don’t need a project board to get things done. While in a traditional project, the project board was important to get an update on the project status, in an agile project, you can get this every day by looking at the task board or product backlog.
A project board is often highly politically. A project manager explaining why things got delayed by reasons out of their control, stakeholders discussing priorities and resources.
In an agile organization, the PMO has to organize project boards differently. Why would an agile team need a project board and how can they benefit from it?
Most importantly to have a forum to discuss issues out of their control. For instance when the agile team has a dependency on another team which suddenly has shifted priorities and is no longer able to provide their piece of software in time. Because the PO and SM roles are project specific, they have no hierarchical power in the organization and cannot negotiate the shifted priority. In a project board, you will have the necessary management present to resolve this issue, or at least get the discussion started.
Secondly to manage expectations. Each project starts with certain expectations concerning time, scope and budget. When we have determined the major constraint, we know how to manage changes. But even with this agreement at the start of your project, you still have to keep your management informed. Each and every project board you show them what has changed. If you have a fixed scope, show the changes in timing and budget. If timing is fixed, show the changes in scope and budget. If budget is fixed, show the changes in scope and time. Of course the product owner has a mandate to manage these constraints, but only to a certain degree. The PMO can help him to find a suitable way to report about these changes in the project board, for instance by using visual aids such as a product burn-up chart.
Third is to openly discuss risks. These are risks which the PO and SM see for the future which can endanger the success of the project. If the right people are present in your project board, you will automatically feel the value of discussing risks. Management will help you find solutions or at least mediations.
So from a PMO perspective you have 2 important responsibilities when organizing a project board for an Agile team:
- Provide a structure for reporting about the 3 main focus areas: issues, change and risks.
- Select the appropriate audience. Every impacted department should be represented, as well as external suppliers.
What is a good frequency to host a project board? I prefer once every month and a half. So if your project progresses in iterations of 2 weeks, you will have the history of 3 iterations to discuss, each project board. In most cases this is a good rhythm, but it may vary according to your situation.
Image by universityymca
SkyCoach 
Hi Nick,
Product Owner actually has the highest role and all of the other stakeholders respect his decision. A PMO that is going to override PO decision is not the best setup.
Joshua,
A Product Owner only has a mandate to represent the stakeholders. He can decide on an operational level, but has to make sure big decisions are carried by his stakeholders. It is a fine balance, but not to be underestimated.
The PMO is indeed not in a position to override a decision, only stakeholders are. Where did you read that?
Thanks for the feedback!
Hi Nick. Based on my personal experience and it is sort of implied inside Scrum Guide.
If Product Owner is only going to act as a proxy, accountability in the organisation is lost.
I think that’s clear. The agile ecosystem breaks down if the product owner is not really accountable.
Nick, we could also think about who should be present at the project board.
– All business stakeholders involved, represented by the product owner
– All IT stakeholders involved (development, operations, testing, release mgt, infrastructure …)
– All other stakeholders involved (legal, compliance, etc)
The project board could/should “report” and take action regarding any organisational improvements (basically impediment removal or process improvements the team or Scrum Master / team coach cannot resolve on this own). (the issues). I’d like to see managers (we cannot fire them all) as capability builders.
The project board could also discuss:
– portfolio management (prioritisation and evaluation of projects)
– funding (rolling wave budgeting) (in real life budget is never infinite)
– resources (if new skills, people are needed)
Frederik,
Very true! Organizational improvements are often not within the power of the team and are worth addressing in the project board.
In my opinion portfolio management and funding are not part of a project board, since the focus is restricted to the project.
Thanks,
Nick
Nick, yes, indeed. I rather mentioned these topics in the context of a PMO, cf. your previous article.
Regarding budget. Often the PO is handed a bag of money and the PO has the responsibility to spend that money wisely. As it should, the increments of the product or service being built are evaluated regularly (ROI). But when the bag of money is spent, and the PO decides it’s viable to continue, he’ll needs to request the next slice of money. (I don’t think the PO always has the sole authority for funding, unless he’s the direct sponsor). These kind of funding questions, where are these discussed?
Nick, regarding risks.
I am thinking: some risks in a agile project are of a different nature than in a traditional sequential project. A project board could focus on those risks in a standardised way.
Frederik,
Indeed, discussions about the budget of the project are of course to be tackled in the project board, but preferably more often 🙂