PRINCE2 and Scrum, Integration

Published Categorized as Agile Project Management, Featured, PRINCE2, Scrum
prince2 and scrum
prince2 and scrum

There are some papers out there that reference a possible integration between PRINCE2 and SCRUM. While I do agree and feel that it is possible and even recommended I feel that the subject has net been treated with sufficient depth. Most of the papers suggest that the PRINCE2 process ‘Managing Product Delivery’ is place where the two fit together. Whilst I do agree with that I feel that this is not enough.

As you will see there are more aspects that need to be considered if you plan to integrate PRINCE2 and SCRUM, and I will list them below.

Is there a need to combine PRINCE2 and SCRUM?

PRINCE2 does not set any requirements for a particular product development methodology to be used by the teams. On the other hand it does require that the work to be done must be specified in advance, that it is tracked and all products satisfy its quality criteria. PRINCE2 focuses on the management and governance of the project. It is in no way dictating how a team should work or what work should be prioritized. After defining the work packages it relinquishes power to the team to find a way to best complete the work and deliver it.

This is where Scrum can be considered as a solution. Scrum is a framework focused on product development and provides a structure that can help the team in delivering the work package. After grouping functionality into Work Packages against which progress will be measured, the development team is empowered to select for itself the best way to complete the work defined in package. Scrum provides a framework to the development team for most effectively delivering the work package.

The big question: should PRINCE2 and SCRUM be integrated?

It seems a merger of the two could create an optimum solution for product development as well as maintaining a level of governance.

Project Governance is required because questions like the following must be answered:

  • Are the goals and objectives of the suggested idea in line with company strategy?
  • Do we have the capability to deliver?
  • Who has the final decision rights to approve the go ahead and apportion company budget to a project?
  • Under what framework will the project be governed?

Agile principles and processes do not help in answering these questions so appropriate governance must operate so that risk is minimized, avoid ambiguities, provide structure etc. Of course these are all provided by PRINCE2.

Agile provides a mechanism to deal with change or maintain a close collaboration with customers. It also helps productivity by shielding the development team from bureaucratic processes.

PRINCE2 recognizes that estimates are educated guesses and provides a mechanism to handle that. It makes use of budget tolerances and schedule estimates but on the other hand Scrum uses velocity (an estimate of the pace the team was able to deliver a finished product) that is adjusted at the end of each Sprint.

PRINCE2 and Scrum roles

The key development related roles in PRINCE2 are Senior User, Project Manager and Team Lead. In Scrum the roles are Product Owner, Scrum Master and Development Team.

Scrum roles

Each role has different responsibilities and all have good reason to be part of the project. How to combine those roles it will very much depend on the skills of each individuals.

The Scrum Master has the responsibility of facilitating the project team so that it can develop and reach a state where it can self-organize and self-direct. Individuals with a command and control style of management would find it very hard to adapt to Agile.

Project Managers are associated with the work package level but they have far more responsibilities above that level and tend to leave a lot of accountability to the team leader to deliver the work package. It may be possible to map the Scrum Master role onto the Project Manager role but only if the individual has practical experience in both positions. The clash resulting from the difference between the two approaches can cause problems for the project. As stated PRINCE2 preaches a more command and control style of management, meanwhile Scrum gives a lot of freedom to the team.

Even in Scrum someone must keep track of costs, report to management, and handle exceptions which all fall outside the Scrum Masters’ responsibilities. Using this information we can safely propose that the Scrum Master and Project Manager roles should be handled by two different persons.

Controls

Scrum as a form of control

Scrum is used for a product development team as a response to an uncertain situation where the project scope is not fully specified but rapid delivery if required. By scoping a Sprint based on the team velocity acquired the result that is going to be achieved in subsequent Sprints if more easily predictable.

Dealing with uncertainty

PRINCE2 uses tolerances to give the Project Manager freedom to react to uncertainty. Scrum scopes the future Sprints based on the team velocity achieved with the available resources. Scrum admits that accuracy can only be accomplished through experience and not better techniques for estimating.

Dealing with change

Both methodologies recognize that change if unavoidable but they manage change differently. PRINCE2 change approval may change scope, duration or the budget of a Stage but in Scrum the duration of a Sprint is immovable, and change can only affect scope or budget.

It is likely that not all items present in the Sprint Backlog get completed, the Scrum Master can reduce scope by removing items that are less important. On the other hand if the team is to deliver more than estimated more items can be added to the Sprint Backlog.

PRINCE2 approach is more formal, involving more stakeholders, and may take more time and work. Approvals, for adding or removing items, may require changes to the length of the stage and its budget. Here the product owner has the final say in all change requirements.

Dealing with issues and exceptions

PRINCE2 Issues include all problems relating to the product development. An exception is raised in the situation where a tolerance if about to be breached. It is recorded as an Issue. When an Exception is raised the current stage is terminated and an impact analysis is done establishing if a new plan is required.

Scrum issues that impact the product development are called impediments. Where an impediment threaten the completion of a Sprint and it cannot be removed than the Sprint is ended.

In both methods exceptions are intended to return control to the governing body so that decisions can be made and corrective actions taken.

Overlaying process models

A PRINCE2 Product description defines the product specification. Each stage product must have a Product Description. Scrum allows the team to revise scope at the start of each Sprint in a Stage, based on the team velocity achieved in subsequent Sprints. If there are more Sprints within one Stage than the question of how to define the product of a Stage in this environment of flexible scope.

Furthermore, the necessity of adequate testing still remains as well as the need of properly handling artifacts, developed by the team, which carry the requirement of stating the Quality Criteria and other completion criteria. PRINCE2 mitigates this by using the completion criteria linked to the Product Descriptions. The solution is to include the Release Backlog into the Product Description document, and if change affected the Release Backlog than both methods will incorporate the change as one.

PRINCE2 planning strategy lines up with Scrum in focusing on product creation and using an incremental approach. This means that planning starts by defining what is needed and a product can be called finished when it is tested and approved.

PRINCE2 product based planning technique does not contain a Product Backlog but it does have a Product Checklist. However a Product Backlog as defined by Scrum can easily be deployed here.

Requirement definition and product planning occur on a stage by stage basis in PRINCE2. (See the figure below)

First two processes presented make sure that agreement is achieved over high level requirements for the products, and also back the project Business Case. But, development of more detailed requirements takes place at the end of each stage, as the development team prepares the next stage. At the core of each stage is the “start or stop” decision of the Board, who must represent the client’s interest.

Stages occur one after the other and have no specifics defined. Stages are time boxed or can run as one or more Sprints following the Scrum method. Also PRINCE2 makes use of the “MoSCoW” prioritization technique to evaluate change requests and scope stages.

Scrum insists on the team being self-organized. PRINCE2 on the other hand recommends that planning should be done by those who will do the work.

Controlling a stage process ensures that a stage remains within stated tolerances. If these tolerances are threaten than the Project Manager must escalate the issues to the Project Board.

Various options and possibilities for integrating PRINCE2 and Scrum have been presented above. Emphasis was put on the PRINCE2 process model and how it could accommodate Scrum.

Conclusion

When using PRINCE2 and SCRUM, or other agile framework, we must address the following ‘traditional management behaviors’:

  • A ‘contract’ being created by a waterfall-driven specification and then delivered through a ‘project manager’ who becomes a contract negotiator between customer and supplier; the agile team consists of customers (product owner) and suppliers (development team) working collaboratively together to achieve clearly defined sprint and release goals.
  • Agile project managers do not command and control; instead they facilitate, enable and protect delivery teams.
  • Agile project boards do not command and control project managers; instead they facilitate, enable and protect them.
  • Estimates are forecast guesses based on the best information available at the time (i.e. baseline plans); forcing delivery against a fixed contract defined early in the project will achieve a significantly incorrect outcome if the delivery environment is changing.
  • Delivery should be made in the form of short vertical slices of working software (or product) delivered in weeks or months, not in long stages.

We must also enable and consistently encourage the values and principles described in the Agile Manifesto.

  • The above list of ‘traditional management behaviors‘ is not exhaustive, but it does indicate where behaviors in the use of PRINCE2 need to be inspected and adapted to enable effective agile.
  • PRINCE2 and SCRUM overlap in certain areas. However agile is typically compared and contrasted with the waterfall approach to delivery, whereas PRINCE2 is a framework for managing projects.
  • PRINCE2 has been designed to be used as a management wrapper for any delivery approach. PRINCE2 manages stages of projects and manages the delivery of products. It does not describe what delivery
    products will be produced or how; and it certainly does not mandate a waterfall delivery approach.
  • Scrum is without doubt the most implemented version of agile worldwide.
  • Scrum contains a product backlog of items; typically ‘stories’ and defects, defining what needs to be done, and this is created by a product owner.
  • The development team then defines tasks that define how the stories will be done, to satisfy the stories within a short delivery ‘sprint’ of typically two to four weeks.
  • The development team always aims to deliver working product at the end of each two to four week sprint, and of a quality that could be implemented in a live environment. However if it is inappropriate to deliver to live from the sprint, the sprint increments could be grouped together and delivered in a later release.
  • PRINCE2 can wrap around any delivery approach and so scrum is no exception. Scrum provides the team delivery discipline and rigor, and PRINCE2 the project management governance.
  • Fundamentally, when assuring delivery within a waterfall delivery approach, it is about assuring that the appropriate products are created within the waterfall stage – always a difficult and risky task. In contrast to this, agile assurance is about assuring outcomes, delivered within short manageable sprints, with all sprint outcomes being of demonstrable value to the stakeholders.

As you can see PRINCE2 and SCRUM can be integrated. While there are some challenges in doing so there are some benefits too. Areas where the two complement each other, like governance, documentation and structure can reduce risks and increase your project success rat.

Please let us know of your opinion on the topic by posting your comments below.

Image courtesy of Freepik

By Alex Puscasu

I am a Project Management practitioner with more than 5 years experience in hardware and software implementation projects. Also a bit of a geek and a great WordPress enthusiast. I hope you enjoy the content, and I encourage you to share your knowledge with the world.

Exit mobile version