• The Executive is accountable for the project's Business Case.
• The Senior User represents the people whom will use the product. He is accountable that the product meets the needs of these people.
• The Senior Supplier represents the people whom will create the product. He is accountable for the quality of the product.

The project manager is NOT accountable for the project's success. He is only accountable for managing the project's process. His job is to execute the plan agreed on by the Project Board. As long as the project manager does not exceed his authority the Project Board is very helpful. Why?

• Accountability is not transferable It just isn't so. You might assign other people within the project. The fact remains that if something goes wrong, the people which are accountable bare the consequences. Not the project manager but his boss, not the team but the supplier's director.
• Accountability creates responsibility The project manager executes the project plan as approved by the Project Board. If something goes wrong the Project Board has the resposibility and also the 'power' to help out. Problems shouldn't be the project manager's problem. In fact they are the Project Board's problems, because these people are accountable. A bit of an oversimplification maybe, the project manager still has problems, but the principle is sound and very effective.
• The Project Board process is mostly an informal process The 'Directing a Project' process within PRINCE2 describes a number formal documents and procedures. It describes only the formal part of directing a project. The formal part isn't that important and should be executed as light (agile) as possible. The real process take place informally, in meetings and discussions and only if needed ('management by exception'). So this process doesn't take much time if executed properly.

To me Project Boards are agile because:

• they are the ultimate impediment removers;
• they let me focus on the project's process;
• take only a little bit of my time, since the process is mostly informal and would be executed anyhow (if the Project Board wouldn't exist the same progress reports would be asked);
• the distinction between Executive and Senior User for me is a much better fit than only a Product Owner (however sometimes the Executive and SU role can be combined within one person);
• the Scrum scoping and reporting processes are a perfect fit from a Project Board point of view, so there's very little need to amend the Scrum method.

I've managed a PRINCE2/Scrum project for 8 months now and the Project Board is really helping me out when problems arise. It's great!

The business side of Scrum however is almost blank. Only assigning a Product Owner is not enough. There’s a lot more to projects than only the Product Backlog and ownership of the Product Owner. That’s why there is so much discussion concerning the implementation of Scrum. You do need to fill in the gaps.

The most obvious gap with Scrum is the management of stakeholders.

With Scrum there’s only a Product Owner. This task can be delegated to someone else (the ‘proxy Product Owner’) or to multiple persons. The problem here is that Scrum needs a ‘single wringable neck’, which is difficult when it’s not one person or when the actual ownership lies somewhere else.

Then there’s the problem of the differences in interests. PRINCE2 makes the distinction between Senior User and Executive. The Senior User is the ultimate user, the person whom will accept and use the finished product. The Executive is responsible for the Business Case. He needs to balance costs and benefits. (By the way, the Business Case is a gap in itself!). Only in small projects these roles can be combined, in that case the Product Owner is both. In most projects the roles can not be combined. That creates a problem with Scrum. A process needs to be in place to manage differences in interests.  Scrum does not have such a process.

Another example occurs with projects with a commercial customer/supplier relationship. If there’s some risk involved then the party whom bares the risk needs some kind of control. Not only on an operational level but also on the executive level. Scrum does provide some level of control with the Burndown charts and Product Backlog, but there’s no process in place to manage progress and issues on an executive level.

These gaps are manageable. Also there is not a single solution that fits all. A lot of Scrum Masters (or project managers) have found a lot of solutions to cope with stakeholders. For me PRINCE2 complements Scrum very well. I use Scrum for the Delivery process and PRINCE2 for everything else. The team doesn’t notice PRINCE2 at all, they use Scrum. The customer notices the differences compared to a traditional PRINCE2  project, but the main processes remain the same. So again, Scrum sucks at some areas but combined with PRINCE2, I couldn’t live without it.