Learn About PRINCE2 7 in Agile environments
Over the last decade, agile approaches have started to be used successfully in all sorts of agile environments. PRINCE2 is entirely compatible with the agile iterative way of delivering. Learn how here!
Agile approaches deliver the products over a series of iterations rather than all at the end of the project, and such iterations are referred to as sprints. In an agile world, the deadline for release is always only a few weeks away, which motivates the team to get down to their work.
The agile focus on delivering regularly aligns perfectly with the PRINCE2 principle of focus on products.
AGILE ENVIRONMENTS
Agile is another common environment that PRINCE2 works effectively within. The Agile Manifesto outlines the four principles of the agile approach:
Agile is another common environment that PRINCE2 works effectively within. The Agile Manifesto outlines the four principles of the agile approach:
- Individuals and interactions are valued more than processes and tools
- Working products are valued more than comprehensive documentation
- Customer collaboration is valued more than contract negotiation
- Responding to change is valued more than following a plan
The Agile Approach
Over the last decade, agile approaches have started to be used successfully in all sorts of industries. Agile approaches deliver the products over a series of iterations rather than all at the end of the project, and such iterations are referred to as sprints.
Sprints are quite short, anything from 1 to 4 weeks in duration. Although the client will not get everything they want in the earlier releases, at least they do not have to wait too long until they get some useful products.
There is always the risk that what the teams are creating is not really what the client wants, and …releasing in short bursts avoids the situation where, if a deadline is a long way off, the natural human tendency is to prevaricate and work more slowly
In an agile world, the deadline for release is always only a few weeks away, which motivates the team to get down to their work.
Clients can do their best to put across their requirements, and suppliers do their best to understand them, but often the only time when the client can see if the supplier understands them, is when they are handed the final product.
Agile approaches discover misconceptions about requirements much quicker and so save more time and money than if everything is delivered at the project end.
Agile calls this failing fast since it is something better to know you’re doing the wrong thing as quickly as possible The client can give feedback to teams when they start using products from earlier releases, which can help teams create better products in later releases
PRINCE2 7 is entirely compatible with this iterative way of delivering
One of the PRINCE2 7 principles is managing a project by stages, and the project team could release products at the end of each stage if required. The agile focus on delivering regularly is aligned with the PRINCE2 principle of focus on products.
Another agile concept is timeboxing. This is where a sprint of work is fixed to a certain amount of time and if the delivery team falls behind in their work, rather than slip the deadline, they must deliver less.
For timeboxing to work, the team must be given some flexibility on the scope of work that they need to deliver. This can be done within PRINCE2 by using scope tolerances and the principle of managing by exception to implement this agile idea.
Agile Environment terminology
Another agile term is backlog. The backlog is a list of prioritised requirements that the customer wants to see in the finished product, however, agile approaches often use the term user stories because they describe a journey that the user would take with the product.
The items in a backlog should be ordered by the value that they will provide to the customer, and this helps Agile Change to prioritize which user stories to work on the early releases and which to eliminate if they are running out of time within the sprint.
This is aligned with the PRINCE2 principles of focus on products and continued business justification.
Agile and PRINCE2 7 Environments
PRINCE2 has roles that manage and control teams, whereas agile has team’s that organize themselves – there is no team manager.
However, the PRINCE2 and agile approach is to managing people can work together very effectively.
Frameworks such as scrum recommend a servant leadership approach to delivery teams since terms like ‘manager’ or ‘management’ imply an autocratic approach to leading teams and a lack of trust and team members.
Servant-leader support their teams by using facilitating and collaborative stars have leadership. Servant-leaders provide a range of management services such as:
- Removing impediments for the team
- Helping the team run progress meetings
- Providing tools and techniques to enable teams to work better
Blending Agile Environments with PRINCE2
The key to blending agile environments with PRINCE2 7, is getting the balance right between the need to control and manage the project (which increases the likelihood of project success), and allowing the delivery teams to be self-organizing, collectively responsible for their work, empowered, and thereby increasing motivation and engagement of the team.
The PRINCE2 7 Project Manager and the Agile Team
The first consideration when blending with agile, is to consider whether you need someone called the team manager to liaise with the project manager. For a start, using the word ‘manager’ with agile is not a good idea!
What is important, however, is that the responsibilities of the PRINCE2 Team Manager are covered.
Team manager responsibilities include:
- Planning, monitoring, controlling and managing progress
- Liaising with the project manager
- Managing issues and risks
- Liaising with other stakeholders
Handover of the PRINCE2 7 Agile products
In a highly agile environment with effective teams, the project manager might review the ‘team manager’ responsibilities with the agile team and make sure they agreed to cover them collectively.
This infers that the project manager may need to communicate with more than one person.
Maybe in a scrum environment, the project manager may just liaise with the scrum master.
Agile teams require a high degree of autonomy to work effectively and therefore work best when they don’t have to constantly refer upwards for a decision that is instead left until work without interruptions.
The PRINCE2 principle of management by exception helps to create autonomous teams.
PRINCE2 and Agile management by exception
Another agile approach is that the teams need to be small, between 3 to 9 people. If the teams are bigger, the project manager might consider breaking up the work to create two or more smaller teams.
Such things must have people with the right range of skills to complete the work, although such individuals may come from different functions within the organization.
The Agile Product Owner and PRINCE2
Many agile approaches represent the user and customer view in a different way to PRINCE2 7.
Agile and Scrum define the role of the Product Owner.
There is only one product owner individual and they are accountable for collating the list, requirements and features that are needed by the users and customers. Somewhat similar to the PRINCE2 senior user. But not quite.
Having one individual represent the customer and business views, works fine when the project is focused on one product and doing regular upgrades on that product.
But this does not work well for larger more complex projects where there is often a wide range of views and perspectives about how the product will be used.
Another consideration is that some customers have a strategic view of requirements, whereas other customers have a more detailed, specialist view on the products requirements.
One way of resolving this, is if the Senior User on the project board could be seen as a ‘Super Product Owner’. This role would direct the work of individual product owners operating within each delivery team.
Subject-matter Experts within Agile
Each delivery team might have several customer subject matter experts, acting for all views from a specific customer or user of the products.
These customer subject matter experts are similar to that of Product Owners, and could also sit on the project board as Senior Users. They can also be some specialists, often called business analysts or requirements engineers, who are trained in understanding:
- Business requirements
- Mapping out business processes
- Translating these processes into product designs
Such individuals might be team members within a requirements-gathering team, or spread out across the number of other teams.All these approaches can be blended together to create a workable representation of the customer business issue within a PRINCE2 7th edition and agile environment.
Agile Scope
The agile environment often allow flexibility around the scope of the project.
When a request for change is issued, the change authority needs to understand what flexibility exists around the scope of the work.Because such changes will normally be raised during the sprint itself, then the agile team are empowered to manage such changes.
As part of the sprint agile philosophy, if such change requests were to increase the scope of that sprint, then either the team could agree that change could be managed within the sprint, or the change, if agreed, would be added to the prioritised product backlog.
In this event, it is the Product Owner who would ultimately decide when such an approved change should be implemented – this would be a future sprint.
The Agile Business Case
In an agile environment, the project scope and the associated benefits that will bring, will probably be more fluid than in a more traditional project environment.
At the start of an agile project, the project team will list all the new feature products, estimate the costs and time of implementing each feature, and forecast the measurable benefits that each feature would provide for the users.
This list is called a product backlog and could serve as an agile version of the business case.
The backlog is a list of features, and the scrum team would review the product backlog and decide which features to deliver within the next sprint that would bring the highest benefits to the users first.
The backlog is continually ‘groomed’ as the business environment will often change during the project as well as the need to incorporate feedback from real users and customers.
In this way, the product backlog is continually revised and updated – some features are added, and some features might be removed.
This process of constantly re-evaluating which features to deliver at the beginning of each sprint means that both scope and business benefits will continually change.
In order to adapt to this situation, the PRINCE2 Business Case should specify acceptable benefit tolerances. A way of doing this is to use a technique that forecasts the best case, expected case, and worst case for the project benefits.
The initial business case (created in the PRINCE2 starting up a project process), might also show the minimum amount of benefits that the project needs to deliver, to make the overall initiative viable.
When calculating an investment appraisal within the full PRINCE2 Business Case, consideration should be given to the return on investment gains by users getting beneficial products earlier and the delivery of incremental subsequent sprints.
The business case should also consider a potential cost of releasing a new product every month or so and the disruption this may have to the organization’s operational areas.
The Agile Environment and PRINCE2 Planning
As you are aware, the product backlog is a list of requirements which agile called user stories – these are the project deliverables.
Each user story describes the feature in a measurable, testable way and gives an indication of the value of the item.
Just like the Project Product Description and the Product Breakdown Structure (PBS) within PRINCE2, the product backlog identifies the main output of the project, and so might replace those PRINCE2 management products.
The normal approach for an agile or scrum project manager, is to create a high-level Vision Statement and Product Roadmap within the PRINCE2 Starting up a Project process.
Both the vision statement and the product roadmap would play the same role as the project product description by providing the overall purpose of the products to be delivered and a high-level description of what they are.
In the PRINCE2 Initiating a Project process, the project manager would create the product backlog thereby providing more details on individual requirements or user stories that may be delivered, along with an indication of the value and priority of each one.
Agile Sprints and PRINCE2 Stages
Each PRINCE2 management stage might contain one or more streams of work, where a working release would be handed over to the users at the end of each sprint.For each sprint, a sprint planning process takes place.
Here, the project management team would work together to plan which requirements from a product backlog to deliver in the upcoming sprint.As part of a sprint planning, the team would take into account the resources available and the priorities of the requirements.
The user stories selected from the product backlog form what is known as the sprint backlog.If PRINCE2 product descriptions were created, the initial versions of each, would likely only address the purpose and quality criteria of the products – with the product description details added during the execution of the work package and/or sprints.
Note that if there were only one sprint within a specific stage, this sprint planning would be the equivalent of stage planning carried out within the Managing a Stage Boundary process of PRINCE2.
If the stage contained more than one sprint, then the above stage planning would be based on the initial estimates for the likely scope of the stage, including some idea of a Minimum Viable Scope.
This Scope would be refined and adapted as the project team performs sprint planning on each sprint within that PRINCE2 management stage.
Managing PRINCE2 Quality within Agile
Within agile, product descriptions might be written as user stories or epics.In addition to including the “who, what, and why” format of the user story, it is important that the product descriptions meet all the other PRINCE2 requirements.
An example here is the PRINCE2 product description should contain a list of quality criteria, which agile normally calls acceptance criteria, in addition to indicating the skills and resources needed to implement the user story.
Most agile and scrum attach a value to each user story which is different from the PRINCE2 approach. The nearest PRINCE2 term to an agile value, is benefit.In PRINCE2 projects, such benefits or only set up at project level within the business case.
Therefore, I recommend that each PRINCE2 Product Description includes such product value/benefit.When an agile team first generate user stories, it is quite natural to have some large user stories that have not yet got enough detail and are ill-defined at this point.
These ‘super-user stories’ are called epics, which are compatable with the PRINCE2 Project Product Description.When carrying out the PRINCE2 initiating a project process, several of these epics may be refined into user stories and/or product descriptions as mentioned above.
PRINCE2 Stages and Agile Iterations
During the PRINCE2 managing a stage boundary process the project manager and team can create more detailed product descriptions of most products to be delivered within the upcoming stage.
This aligns well with the agile philosophy evolving the requirements for products throughout the project.
The PRINCE2 mindset could help avoid chaos by baselining or freezing high-level product descriptions at a reasonable point in time, while allowing lower level product descriptions to evolve without impacting the high-level requirements.
Because agile delivers products across a series of iterations, this will often involve a higher frequency of quality checking than in a traditional project. Ultimately, product acceptance within an agile project, is during each sprint review, where the product is demonstrated to the customer or user.
Feedback from such a review will provide product improvement – usually carried out in the next sprint.
This too contributes to the higher frequency of quality checking.
It is therefore important that the PRINCE2 project management team needs to carefully plan and budget for a higher frequency of such quality checking with the purpose of delivering robust products within a short period of time.
Agile and PRINCE2 Change Control
The general philosophy of agile approaches is to respond to and embrace change, whereas PRINCE2 talks about controlling change.
Despite this, both can work together effectively on a project.It is important that the project management team avoid over-exactness when creating product descriptions. This can be achieved by specifying product quality criteria precisely, but only when it is necessary.
This reduces the number of requests for change that need to be treated formally to the issue and change control procedure.
The product management team should try to baseline only quality criteria for the purpose of the product (rather than for example performance related criteria).It is vital that any request for change is raised during a sprint are dealt with speedily so as not to slow down the development of the products.
Change control will often take place during the daily scrum standup meeting, and so is important that the change control process can often be carried out verbally with the decision being captured by the project manager or product owner, thereby leaving the implementation to the team themselves.
Of course, if a change is authorized, it is vital that the product backlog and in its priorities are updated to reflect such a change.
Agile and the PRINCE2 7 Progress Practice
Within agile, products are delivered in the number of sprints, the rule here is that once a sprint starts, it cannot be shortened or lengthened. In a traditional project, the traditional constraints on time, cost, and scope. In addition, the Scope is normally fixed and non-negotiable.
It is therefore not a surprise that traditional projects tend to come in late and over budget, since those are the only criteria that the project can control.It is no accident therefore, that PRINCE2 recommends setting time and cost tolerances since no estimates can be 100 per cent accurate.
Such a tolerance will give the project manager some leeway to manage product progress.
Within the agile however, each sprint is a time-bound and so rather than increase cost, the team reduce scope.For this reason, agile project managers focus on how much scope is being delivered rather than time or cost overruns.
Once a sprint is planned, the number of people, and hence the cost, are unlikely to increase due to the fixed duration of the sprint.The message here is that agile project management needs to focus on measuring projects progress via delivered scope.
Agile and Controlling a Stage and Managing Product Delivery
For large complicated projects, the work package might be a formal set of instructions, and the converse is true for simple projects.
Whatever the size, the project manager should use the PRINCE2 7 work package’s product description as a checklist to ensure that all relevant information is present.
Within an agile project, the PRINCE2 highlight and checkpoint reports might be more informal and could simply be verbal updates.
Again, within an agile project, the project manager or the team manager might facilitate the daily standups meetings, which is where the teams can report progress and examine project issues.
Rather than using reports, information radiators are the usual way of communicating project information. These easy-to-read wall charts show in a visual and pictorial way, information about the projects progress, issues, risk, and goals.
Common forms of information radiators are the Kanban Board and Burndown chart.
The Kanban Board tracks the work that has been assigned to each person and the current status of each task.
The Burndown chart tracks how much work remains against the sprint timeline.
Within an agile/scrum sprint, the sign-off of the products could be done by giving reviews and demonstrations to the customer at the end of each sprint.
After such a demonstration, the project manager or team manager will run a sprint retrospective, these are like lessons learned meetings within PRINCE2, and these can help the team learn useful experience for future work.
The frequency of PRINCE2 highlight and checkpoint reports make changes to the risk profile and the products been created within a specific sprint. This flexibility should be documented in the communication management approach.
Also, the highlight and checkpoint reports may contain additional information such as progress against certain key performance indicators.
Rather than the traditional ‘command and control’ approach to project management, agile and scrum projects are based on the ‘servant leadership’ approach.This will have a fundamental change to the way that the activities within the PRINCE2 controlling a stage process occur.
We have already discussed the way in which work packages are initiated and closed, as well as the way in which highlights and checkpoint reports are used.
Agile environment and PRINCE2 7 Controls
It is worth making a few points on the remaining typical activities of the project manager within an agile environment.
Capture and examine issues and risks/yake corrective action. These are likely to arise within the dynamic environment of the development team and such corrective actions will be carried out by the team themselves.Therefore, the project manager will only need to deal with such issues, and risks, and required corrective actions, should they be escalated by the team themselves.
Progress Control. Progress feedback can be obtained by the project manager observing the daily standups meetings.
Review the stage status. As a minimum, the project manager should review and update the business case and risk register on a regular basis. Progress information is used by the project manager and the agile team.
PRINCE2® 7 Foundation and Practitioner
Learn PRINCE2® 7 Foundation and Practitioner Online
** Enhance your PRINCE2 career now **
PRINCE2® Masterclass gives you the skills necessary to manage projects effectively and achieve your objectives.
Get 7 days a week 12 months one to one coaching with ex PRINCE2 examiner Dave Litten.
PRINCE2® is a globally recognized project management framework. By completing both the Foundation and Practitioner courses through our self-paced e-learning, you will develop an understanding of the methodology and learn how to effectively adapt it to any project.
The PRINCE2® 7 Foundation and Practitioner Masterclass is PeopleCert Accredited and guarantees to take you from PRINCE2 Novice to PRINCE2 Practitioner with our famous video learning, study guides and practice exams.
What Does the Masterclass Cover?
The PRINCE2 Foundation examination assesses your knowledge and comprehension of the PRINCE2 project management methodology as detailed in the syllabus. The PRINCE2 Practitioner examination, on the other hand, gauges your ability to apply and tailor the PRINCE2 method. Candidates who pass the Practitioner exam should be able to start implementing the method on an actual project with some guidance. However, their effectiveness may differ based on their experience in project management, the complexity of the project, and the level of support they receive in their work environment.
