This brief introduction to PRINCE2 Agile is mainly based upon the PRINCE2 Agile manual from AXELOS (Amazon partner link).
Content
- What is PRINCE2 Agile
- The Rationale of using PRINCE2 Agile
- The PRINCE2 Agile Journey
- The Foundation of PRINCE2
- What to fix and what to flex
- The PRINCE2 principles
- The PRINCE2 processes
- Cynefin
- The Agilometer
- Agile Contracting
- PRINCE2 Agile Roles & Responsibilities
What is PRINCE2 Agile?
PRINCE2 Agile describes how to configure and adapt PRINCE2 so that it can be combined with agile behaviors, concepts, frameworks and techniques.
Since PRINCE2 is for use on projects only, so is PRINCE2 Agile. It is not suitable for Business As Usual, or BAU.
| Project Characteristics | BAU Characteristics |
|---|---|
| Temporary | Ongoing |
| Team is created | Stable team |
| Difficult | Routine |
| A degree of uncertainty | A degree of certainty |
When blending PRINCE2 and agile behaviors we combine the PRINCE2 strengths (project direction and project management) with the strengths of Agile (product delivery).
Who is PRINCE2 Agile for?
PRINCE2 Agile is suitable for two types of organizations:
- An organization which already uses PRINCE2 and sees an evolving need to apply agile techniques to their projects.
- An organization which already uses agile techniques and behaviors and wants to extend their body of knowledge towards PRINCE2 techniques.
The second type may also benefit from turning some BAU processes into projects and then utilize PRINCE2 Agile on these processes.
The Rationale for Blending PRINCE2 and Agile
- PRINCE2 is already enabled for use with agile.
- PRINCE2 is suitable for any style of project (“traditional”, or “agile”)
- PRINCE2 Agile is for any project, not just IT projects.
- There is much more to agile than den Scrum framework. Agile is not Scrum.
- The most commonly used agile approaches are Scrum and Knaben, but they are not suitable for managing a project in isolation.
- The term ‘agile’ should refer to a family of behaviors, concepts, frameworks and techniques.
- Using agile on a project is not a question of ‘yes or no’: It is about ‘how much’.
The PRINCE2 Agile Journey
In PRINCE2 Agile standard PRINCE2 measures cater for properly directing and managing the project, whilst on the team/product delivery level the agile methodology of choice will be applied.
In the following I will underline the aspects which relate to agile behavior.
The Pre-Project and Initiation Stage
- In the Pre-project stage the planning focusses on sets of features (product attributes) and intended releases.
- Planning and estimation is a collaborative team effort.
- The specific agile approach will be mandated/recommended to the project board.
- Product descriptions will be captured as high level user stories (AKA epics).
- Via the benefits management approach it will be made clear how this project intends to deliver value.
Remember that these two phases require some theoretical work, but must not be seen as ‘big design up-front’ like in waterfall.
Pre-project and initiation stages should be regarded as enough design up-front (or EDUF).
The Subsequent Stages
- Work assignments are collaboratively set by creating work packages in a self-organized way.
- Progress will be reported via burn charts.
- Quality criteria (including tolerances) will be continuously monitored.
- Information is changed via informal information radiators (e.g. Kanban boards), rather than formal project management registers.
Final Stage
- Basically, the customer is already in ownership of several products that may have transitioned into operational use and should now realizing the benefits. This is very similar to the sprint review concept.
- Some of the intended product items may have been delivered, some not, maybe some unforeseen features have been delivered (in accordance with the changed stories/epics).
- Tidying up and archiving is a routine task and should have taken place throughout the project.
- A retrospective is mandatory.
Post-project
A post-project stage mainly takes care of verifying that the project has contributed towards the intended/planned benefits realization. A post-project review should cater for:
- Confirmation of achievement of planned benefits
- Identification of not achieved benefits plus follow-up plan
- Identification of unexpected benefits and dis-benefits.
- Lessons (learned) for future projects.
The Foundation of PRINCE2
The PRINCE2 method addresses project management with four integrated elements:
- PRINCE2 principles: There are seven guiding obligations and good practices, known as PRINCE2 principles, and unless all of them are applied, it is not a PRINCE2 project.
- continued business justification
- learn from experience
- define roles and responsibilities
- manage by stages
- manage by exception
- focus on products
- tailer to suit the project
- PRINCE2 themes: they described seven aspects of project management that must be addressed continually throughout the project:
- Business Case: The principle measure to judge if the project is viable, desirable and achievable. Since what will be delivered may flex, the business case should show best, worst and expected case scenarios.
- Organization: Establish the project’s structure of accountability and responsibility.
- Quality: Define the means by which the project will verify the products are fit for purpose.
- Plans: Facility communication & control
- Risk: Identify, assess and control uncertainty.
- Change: Identify, assess and control any potential and approved change to the project baseline.
- Progress: Monitor and compare actual achievements against those planned.
- PRINCE2 processes: There are seven processes to direct, manage and deliver a project:
- Starting up a project (SP)
- Initiating a project (IP)
- Directing a project (DP)
- Controlling a stage (CS)
- Managing product delivery (PD)
- Managing stage boundary (SB)
- Closing a project (CP)
- The project environment: Organizations often want a consistent approach to managing their projects and tailor PRINCE2 to create their own project management method. This method is then embedded into the organization’s way of working. PRINCE2 Agile is one example of such tailoring.
What to fix and what to flex
Traditionally the dimensions time, cost and quality have been regarded as the competing constraints, pulling against each other (see “the magic triangle of project management”).
Instead of that PRINCE2 identifies six ‘aspects’ which need to be controlled. Some of these ‘aspects’ should be considered as having a zero tolerance (i.e. ‘fix’), some may have a certain tolerance (‘fix’ or ‘flex’), some should have an even larger tolerance attached to them.
In an agile context, AKA a PRINCE2 Agile context the tolerance guidance is as follows:
- Time: zero tolerance, i.e. fix.
- Cost: zero tolerance, i.e. fix.
- Quality: zero tolerance for essential quality expectations, some tolerance for the others, i.e. fix or flex.
- Scope: zero tolerance for essential product features, some tolerance for the others,, i.e. fix or flex.
- Benefits: : zero tolerance for MVP, some tolerance for the others, i.e. fix or flex.
- Risk: tolerance TBD, i.e. fix or flex.
- The risk tolerance defines the threshold levels of risk exposure which, when exceeded, require the risk to be escalated to the next level of management.
- It should define the risk expectations of corporate, programme management or the customer and the project board (cf. Appendix A.24.2 of the manual).
With regards to scope flexing keep in mind that PRINCE2 Agile is using the MoSCoW technique to prioritize the requirements, and this should be an ongoing exercise (invented by Dai Clegg, cf. https://en.wikipedia.org/wiki/MoSCoW_method).
- Must have?
- Should have?
- Could have?
- Won’t have for now?
Alternatively you may think of YAGNI which is just the opposite of feature bloat: You Ain’t Gonna Need It.
Here is an example: The washing machine
A washing machine could have been intended to have quite a lot of different wash cycle, e.g. for wool, synthetics, silk, etc. and a dial for the spin cycle, which could lead to quite a lot of combinations. When you no run out of time in developing the washing machine, consider to de-prioritize the buttons your customer will more less only will use everyday, sports and woolen settings anyway.
And here is another very important example: A boat trip from Dover to Calais.
If we are sailing from Dover to Calais (planned route), the team on the boat can change course in view of traffic or adverse weather conditions in the English Channel. But provided they arrive in Calais this is OK. Arriving in Oostende is not OK and would require a formal change control, with the project board (the stakeholders) involved.
PRINCE2 Agile targets
PRINCE2 Agile is built upon the concept of flexing (or: prioritizing) what is delivered. There are five aspect called targets, which give us some reasons for flexing. So, here is the rational behind flexing what to deliver:
| PRINCE2 Agile Target | Description |
|---|---|
| Be on time and hit deadlines | Being on time helps delivering early realizations, provide easier planning, give pace, cadence, synchronization. It reduces the likelihood of cost overruns when resources are fixed. |
| Protect the level of quality | The level of expected quality is protected and well guaranteed for the most important features. This will reduce TCO. And it help engagement with the user community. |
| Embrace change | Change is not only inevitable, but also has a positive influence on the project, since it leaves us with the possibility to learn, improve, optimize. This target allows for a more accurate final product, since we can adjust to the changing necessities of the product users. It is achieved by setting the project baseline at the correct level. |
| Keep teams stable | This will remove the temptation to add people if timelines are slipping, etc. |
| Accept that the customer does not need everything | Concentrate on the product features which will add the highest value. The ability to redirect your product development can save lives. As any decent go player can tell you (a common Go strategy proverb: “Make urgent points before big points!”). https://senseis.xmp.net/?UrgentPointsBeforeBigPoints |
Tip: To deliver more, deliver less!
PRINCE2 Agile Manual
Agile and the PRINCE2 Principles
The seven PRINCE2 principles introduced above do not conflict with any agile practice. Since they are very important, let us repeat them first:
- continued business justification
- learn from experience
- define roles and responsibilities
- manage by stages
- manage by exception
- focus on products
- tailer to suit the project
Here is our idea on how they could be used in an agile context:
| PRINCE2 principle | Guidance | Example |
|---|---|---|
| Continued Business Justification | The terms “benefit” and “value” are interchangeable. Think about the MVP concept and how this impact the business justification. | Create a simple landing page and try to attract visitors. If the number of visitors is rather low then there may be no point going further. |
| Learn from experience | Almost all agile methods are retrospective methods. They learn from the past. But keep short feedback loops in mind. | Retrospectives could lead to training needs, adjust velocities, different sprint lengths, improved DoD, adding specialists to the team, etc. |
| Defined roles and responsibilities | Agile roles should be very carefully mapped to PRINCE2 roles. Be clear about delivery manager (Product Owner) roles vs. customer representatives (AKA Senior Users). See the Organisation theme. | In larger contexts consider to use the SAFe role “Business Owner”, establish a good and effective communication between the the users and the POs. |
| Manage by stages | Stages are natural time boxes for a set of sprints, which may be then called “releases”. | The product roadmap consists of planned releases, a release can be synced with intended sprint results, AKA “potentially shippable software”. |
| Manage by exception | This concept is the heart of agility: empowered, self-organized people with management responsible for governance, high level decisions and resolution of conflicts which cannot be resolved on the team level. | The combination of expected results and tolerances results in an effective generation of customer value. And a clear indication when to involve management, because the result is not achievable anymore. |
| Focus on products | The old product based planning technique fits very good to a prioritized backlog. | MoScoW leads to a high level prioritization. The SAFe WSJF method could help as well. Finally we have a customer value maximizing product. |
| Tailor to suit the project environment | PRINCE2 Agile has been developed to be tailored to your organization’s needs, agile methodologies, etc. | Adapt to working environments you cannot change: Fairs, customer events, competitor’s announcements & campaigns, new technology. |
PRINCE2 Agile talks about desirable agile behaviors:
- Transparency: Clarity and openness even if the news is not so good leads to honesty. Burn-down charts on an office wall may help you. Transparency ensures that things are out in the open.
- Collaboration: Motivated and respectful teams are more efficient than others.
- Rich communication: Consider face-to-face as being more effective then email bombing.
- Self-organization: leave as much freedom as possible to the people “below” you.
- Exploration: e.g. Spiking & experimentation. Cf. https://www.scaledagileframework.com/spikes/
Maybe it is a good idea to regularly think about a traffic light report for these five dimensions. Red means “exception report”, yellow means “watch out”, green means “continue measurement”.
How an agile behavior dashboard could look like.
Agile and the PRINCE2 themes
| Theme | Tailoring Ideas |
|---|---|
| Business Case | The principle measure to judge if the project is viable, desirable and achievable. No changes needed, but the BC will deliver a very good insight into the purpose of the agile activities. The MVP concept could be very helpful. |
| Organization | Establish the project's structure of accountability and responsibility. No changes required, but agile delivery-level roles will be added. A senior user may act like a super product owner (or: product manager in SAFe terms). |
| Quality | Define the means by which the project will verify the products are fit for purpose. The definition of 'Done', the definition of 'Ready', acceptance criteria should be very well established, continuously monitored and improved. quality checks go very well together with DevOps. |
| Plans | Facilitate communication & control. No changes required. Typically plans can be a bit more low-tech and informal. Gantt charts are not popular in the agile community for good reasons, especially since low level planning is based upon empiricism. |
| Risk | Identify, assess and control (plan risk responses, implement risk responses) uncertainty. Risks typical for agile approaches should be tackled. Examples: - customer engagement - bad architecture (https://www.scaledagileframework.com/agile-architecture/) - lowering velocity - side effects See the Management of Risk Guidance for Practitioners (Amazon Partner-Link). |
| Change | Identify, assess and control any potential and approved change to the project baseline. No change needed. Agility embraces the change concept very well. Consider establishing a separate change authority to manage changes, consider the effect on configuration management. |
| Progress | Monitor and compare actual achievements against those planned. Progress is tracked quite rigorously in agile methods. Velocity, lead time, customer value delivered are examples. Burn charts are used extensively. Burn-Down-Charts are tracking work done, compared to assumed (linear progress). Burn-Up-Charts allow to report agains total work to be done (which could change over time). Information radiators (Kanban boards) are a key element to visualize progress. But be aware: Timesheets and cost tracking is not at the heart of agile. It is kind of out of scope. |
Agile and the PRINCE2 processes
Here the birds eye’s perspective of PRINCE2 processes, aligned with the common PRINCE2 project stages:
Excursus: The Cynefin Framework
The Cynefin framework categorizes project situations into five domains and gives guidance on the solution approach depending on the domain.
- The Simple domain allows for best practice approaches AKA “S-C-R”, which stand for Sense – Categorise – Respond.
- The Complicated domain asks for a cause and effect analysis of a person with expert knowledge, “S-A-R” means Sense – Analyze – Respond.
- The Complex domain renders a cause and effect analysis impossible, meaning we should rely on probing, and emerging techniques. “P-S-R” = Probe – Sense – Respond.
- Within the Chaotic domain, cause and effect are unclear. “A-S-R” = Act–Sense–Respond. Goal is to turn a chaotic system into a complex system.
The black/brown bit in the middle is the the fifth domain: the Disorder domain.
“The way out of this realm (remark: the Disorder realm) is to break down the situation into constituent parts and assign each to one of the other four realms. Leaders can then make decisions and intervene in contextually appropriate ways.
https://en.wikipedia.org/wiki/Cynefin_framework
During starting up the project Cynefin can be used to understand the complexity of the project, both with regards to the product and the project environment.
If the analysis shows a complex or chaotic situation, a Lean Startup approach may be appropriate, making PRINCE2 process durations as short as possible. The project could more feel like an experiment or a series of experiments.
Check out the spiking concept as SAFe sees it: https://www.scaledagileframework.com/spikes/
In a complicated situation we may use very long time boxes or even consider to not use PRINCE2 at all, since a BAU situation may be more appropriate.
Checkout Dave Snowdon’s Introduction to Cynefin.
Starting up a project & initiating a project
The purpose of starting up a project is to ensure the prerequisites for the next process (initiating a project) are met, by answering this question:
- Do we have a viable and worthwhile project?
This includes answering questions in the following tasks or sub-processes:
- Appoint the executive and project manager.
- Capture previous lessons.
- Design & appoint project management team.
- Prepare the outline business case.
- Select project approach.
- Assemble project brief.
- Plan the initiation stage.
This process also ensures that poorly conceived projects are not initiated.
During this stage requirements are possibly represented by a maximum of ten bullet points in the ‘composition’ field of the project product description.
If these tasks are done, the project manager requests the board to initiate the project (which is a ‘Directing a project’ task).
Initiating a project
This process will lay down the foundation for the project on order to deliver the product(s) successfully, why we do so, how we do so. And it will define all responsibilities.
The project board will then be informed and will decide wirth or not the project is aligned with other activities.
Agile approaches often do not cater for pre-project activities like these. Two concepts are quite frequently used in agile contexts:
- project chartering or visioning
- sprint zero (AKA discovery phase).
In a PRINCE2 Agile environment the level of formality might be reduced quite drastically, but still, we have to answer the simple questions (Why, who, how?) with standard PRINCE2 activities.
The same holds true for the extensive list of PRINCE2 artifacts, which could be replaced by less formal information radiators, but they still have to exist in some form.
Requirements are typically documented within the range of ten to a hundred product descriptions or epics.
An epic in this sense is a high-level description of a requirement that has not been sufficiently refined or understood yet.
Directing a project
The ‘Direcing a project’ process enables the project board to take over accountability for the success of the project by making key decisions, exercising overall control while delegating all other things to the project (and/or the project manager).
Especially in an agile context the PRINCE2 principle of ‘management by exception’ is vital to the success of the project.
Since we reduce the amount of formal communication and enhance informal communication, we would see the project board to show up on key demos, retrospectives, etc. instead to receiving lengthy progress reports.
Controlling a stage
Within the ‘Controlling a stage’ process we assign work to be done, monitor this work, deal with issues, report these to the project board and take corrective actions when the issues leave the project within the defined tolerances.
- Management products are controlled.
- Risks and issues are controlled.
- The business case is kept under control.
- The quality of the product components to be delivered in this stage is kept under control.
- The tolerances are kept.
A stage may be regarded as a high-level time box containing some releases which in turn contain some sprints/iterations.
With regard to the ‘controlling a stage process’, the concept of a management stage is different from a release in that it focusses on the commitment of resources and the authority to spend
In Agile work will be pulled by the teams not assigned by the team lead or project manager.
Managing product delivery
Within the managing product delivery process we synchronize the team activities (and deliverables) with the project level activities (and deliverables).
Work packages and the ‘managing product delivery’ process represent the vital management product interface between project management and product delivery.
Thus through the ‘controlling a stage’ process the team manager(s) receive the ‘authority to deliver a work package’ from the project manager, accepts this work package, executes this work package and delivers it. The project manager then receives the completed work package and controls the content again within the controlling a stage sub-process.
In an agile context this process is absolutely vital, since we have to combine the strengths of PRINCE2 with the strengths of Agile (the product delivery).
One of the major activities in PRINCE2 Agile is to map PRINCE2 activities and artifacts to the activities and artifacts of the chosen agile methodology.
Here comes a typical (but not set in stone) mapping:
| PRINCE2 activities and artefacts | Potential agile activities and artefact |
|---|---|
| Within Accept a work package: - create team plan - update risk register - update quality register - approve work package | Artefact(s): release backlog, sprint backlog Event(s): release planning, sprint planning |
| Within Execute work package: - create specialist product - update quality register - update config item record - update team plan - create checkpoint report - update issue register - update risk register obtain approval records | Artefact(s): Sprint Backlog, Knaben board, burn charts Events: daily stand-up |
| Within Deliver a work package: - update work package - update team plan | Artefacts: release backlog, sprint backlog, potentially shippable increment Events: sprint review, release review |
Agile Concepts and techniques: Kanban and the Kanban method
Kanban has evolved from the Toyota Production System (Taiichi Ohno, 1942) and is used whenever an organization wants to improve flow (both short term and long term).
Keep in mind that when using Kanban in a PRINCE2 context we talk about projects.
The Kanban method consists of six core practices:
- Visualize (the flow): E.g. use a Kanban board, accessible by everyone.
- Limit the work in progress (WIP): Let the worker pull a limited number of work items from the to do list, reduce task switches.
- Manage the flow: Maximize the customer value by constant flow improvements.
- Make policies explicit: Define how everybody works. Build & improve collaboratively
- Implement feedback loops: Check if customer value is generated and correct if potential improvements are found.
- Improve collaboratively, evolve experimentally: Build hypothesis about the best system, experiment in a safe-to-fail (i.e.: limited effect on the overall systems health) manner.
Progress could be tracked via cumulative flow diagrams (CFD). CFDs track all work items and stack them dependent of progress status (e.g. ready, build, test, ready to deploy, deployed).
The lead time is the time between work arriving and work done (delivered). Thus in a CFD this is the horizontal difference between the two curves.
The work in progress (WIP) is the difference between the number of work items arriving and number of work items done. Thus in a CFD this is the vertical difference between the two curves.
Agile Concepts and techniques: Lean Startup
The Lean Startup is very well explained in the book of its inventor Eric Ries. Amazon partner pink: https://amzn.to/2IVz422.
Although invented for startups, the method has been applied to much more mature contexts, basically wherever product innovation in uncertain markets is needed. The core concepts are:
- build, measure, learn.
- create a minimum viable product (MVP), the MVP may take the form of a simple experiment or prototype on order to promote learning.
- fail fast (not only in PRINCE2 eco systems this shall be coupled with learn fast…).
- validated learning.
Managing a stage boundary
Be a management stage comes to an end, the manage a stage boundary process kicks in to provide the project board with information to
- review the success of this stage,
- approve the next stage plan,
- review an updated project plan,
- confirm the updated business justification and accept the updated known risks.
In an PRINCE2 Agile context this step is rather critical, since the teams might work effectively and deliver good looking releases, but they might not know about the overall customer value generated, or about changed boundary conditions.
The checkpoints at the end of a stage should not interrupt the flow of the teams.
This process could be seen more like a large scale ‘inspect and adapt’.
Closing a project
From the ‘controlling a stage’ process we know that the project will come to an end soon. Thus we need some kind of a planned closure. This includes:
- prepare and plan closure
- hand over products
- evaluate the project
- recommended project closure
This closure recommendation will then be communicated to the ‘directing a project’ process, in order to let the project board actually close the project.
During the ‘closing a project’ process the product description is used
- to validate that the acceptance criteria have been achieved,
- to check that the project has delivered what is expected.
In a PRINCE2 Agile context a good amount of product handovers have taken place already. This artifacts and the evaluation of the project should be accessible through earlier shipments and the historical burn reports.
The Agilometer
Overview
In order to taylor PRINCE2 (or any other framework) in the most efficient way you have to know where we are.
The Agilometer thus is a tool which helps us to assess our Agile environment. In a PRINCE2 context Agile suitability is specifically assessed during
- the pre-project stage
- the initiation stage
- throughout the project (e.g. in retrospectives)
The Agilometer shows where there are risk areas and benefit areas with using agile:
The Agilometer sliders in more detail
In the following we will try to explain what a level 5 condition would imply, thus it leaves it up to you to decide when to rank this dimension 1 to 4.
Flexibility on what is delivered
In a level 5 environment we would expect shareholders to welcome change, flexibility and uncertainty. This includes, for example:
- Details may change, significant changes should be controlled.
- All requirements are prioritized, e.g. by the MoSCoW technique.
- Flexing of what is delivered protects timelines and product quality.
- Change, including de-scoping is a team effort, driven by the customer.
- Embracing change produces better products.
Level of collaboration
In a level 5 environment we see that all parties communicate on a very high level. There is a one-team culture, working relationships with good trust and a desire to help others, both internally and externally.
- One-team approach, partnership approach, trust, listening, helpful.
- No ‘silos’, no ‘turf war’.
- No blaming. No ‘cc:mail’.
- Acceptance that mistakes happen.
Ease of communication
In level 5 situations it should be very easy to communicate amongst all parties involved. A ‘communication-rich’ environment with a lot of face-to-face communication will be present.
- Visibility & transparency of information (e.g. plans on walls)
- Co-location
- Less ideal situations are softened an communication risks mitigated (e.g. video conferencing)
- A lot of informal communication, limited formal communication
Ability to work iteratively and deliver incrementally
Here it will be very easy to deliver benefit/value to the customer by regular partial deliveries of the final product.
- The team is willing to experiment.
- It is understood that things are rarely correct at the first time.
- The project can be broken down to small chunks.
- A ‘lesson learned’ approach is used throughout.
- ‘Little and often’ is a delivering pattern.
- Delivering incrementally is giving good and fast feedback.
Advantageous environmental conditions
The working environment is supportive of working in an agile way. People are fully assigned to the team and their work.
- People are dedicated to the project.
- Teams are stable.
- Team members are qualified.
- Contracts support agile behavior.
- The environment is conductive to agile.
Acceptance of agile
All stakeholders closely involved are fully aware of the behaviors, concepts and techniques of agile thinking and working.
- Everyone accepts the agile philosophy and understands the difference to the traditional way.
- People are trained.
- The surrounding eco systems do not block agile working, e.g. quality assurance and procurement understand Agile as well.
You may want to google ‘ agile health radar’ or click on https://www.scaledagileframework.com/metrics/#T4, to get different views on appropriateness of agile approaches in your environment.
PRINCE2 Agile roles & responsibilities
The roles and responsibilities are defined in Appendix B of the manual.
PRINCE2 role: Project board
The project board is accountable to corporate or programme management for the success of the project, and has the authority to direct the project within the remit set by programme management as documented in the project mandate.
The project board typically consist of one or more senior users, an executive and a senior supplier.
PRINCE2 role: Senior user
The senior users is responsible for specifying the needs of those who will use the project product, for user liaison with the project management team, and for monitoring that the solution will meet those needs within the constraints of the business case in terms of quality, functionality and ease of use.
PRINCE2 role: Executive
The executive is ultimately accountable for the project, supported by the US senior user and senior supplier.
Throughout the project, the executive is responsible for the business case.
The project board is not a democracy controlled by votes. The executive is the ultimate decision maker.
PRINCE2 role: Senior supplier
The senior supplier represents the interests of those designing, developing, facilitating, procuring and implementing the project product.
PRINCE2 role: Project manager
The project managers accountable to the project board and ultimately the executive and has the authority to run the project on a day-to-day basis, within the constraints laid down by them.
The project managers prime responsibility is to ensure that the project produces the required products within the specified tolerances of time, cost, quality, scope, benefits and risk.
The project manager is also responsible for the project producing the results capable of achieving the benefits defined in the business case.
PRINCE2 role: Team manager
The team manager’s prime responsibility is to ensure production of those products defined by the project manager to an appropriate quality, in the set timescale and at a cost acceptable to the project board.
PRINCE2 Agile role: The customer representative
A customer subject matter expert (CSME) is assigned to the delivery team and plays an active part by acting as a representative of all of the customer stakeholders with a responsibility for ensuring that the project product and its components is understood and this is correct at the detailed level.
PRINCE2 Agile role: The supplier subject matter expert (Supplier SME)
A supplier SME is assigned to the delivery team and provides the appropriate technical skills to build and initially quality check the project products and its components.
PRINCE2 Agile role: The customer subject matter expert (CSME)
The customer subject matter expert (CSME) is assigned to the delivery team and plays an active part by acting as a representative of all of the customer’s stakeholders with a responsibility for ensuring that the project’s products are understood and are correct at the detailed level.
The person carrying out the small probably wants, or needs, the final product and is motivated for the project to succeed yesterday are impacted by it.
Miscellaneous PRINCE2 Agile roles
Customer representatives and supplier representatives may be assigned to the delivery team to consult on specific topics.
Within QA we see customer QA (CQA) and supplier QA (SQA) roles contributing to the team’s QA performance, mainly to check if the product delivered is fit for purpose.
A QA coach could boost overall quality. A QA role on the project level could manage QA.
Miscellaneous Topics
Requirements
A requirement is a term used to describe what a product does and/or how to do it.
A user story is a tool to describe a requirement in the form of who, what, why.
A feature (in the PRINCE2 Agile sense…) is something a product does or the way it does something. It can be at any level and can relate to a specific requirement, user story or epic.
A function is a similar term to feature.
Requirements should be defined in a hierarchical way. As SAFe likes to express itself: The higher requirements level is realized by the lower level.
Cf.: https://www.scaledagileframework.com/safe-requirements-model/
In a PRINCE2 Agile sense, we may compose a requirements hierarchy as:
- The project product description, representing the final output from the project (highest), consisting of
- Product groups, representing kind of the “boulders“, high-level requirements, or epics of the project.
- An intermediate level in the product description realm, AKA “rocks“, 10 to 100 of these.
- Low-level requirements in the form of text (a detailed requirements list) or user stories, this is AKA as “gravel” level.
| Level | Preferred PRINCE2 Agile term | Alternative term |
|---|---|---|
| Highest | Project product description | Vision, SAFe: Epic |
| High | Product group, Project product description composition, high-level requirement | Epic, feature, function, theme, scope, SAFe: Capability |
| Intermediate | Product description, Intermediate level description | Epic, feature, function, coarse-grained user story, SAFe: Feature |
| Low | Product description, Sub-project, Detailed product description | User story, fine-grained user story, SAFe: User Story |
Prioritization of requirements through MoSCoW
- Must have: Must be satisfied, because without it, either the product won’t work or is not worth it.
- Should have: This is highly desirable or very important, but is not a must have.
- Could have: Could be satisfied because it is desirable, but is not a should have.
- Won’t have: won’t be satisfied by the end of the sprint/release/stage/project.
Rich communication
Rich communication requires choosing the most appropriate communication channel. Examples are:
- written word in documents, emails, messaging,
- visualizations in the from of photos, figures, graphs,
- verbally, by telephone,
- verbally, face-to-face.
A lot of persons seem to find it difficult to process large amounts of written text. Parts of the text might not be read or misunderstood. Interaction between the reader and the writer is indirect and complex.
Agile concepts and behaviors
Running a workshop to achieve a common objective is very common in Agile. It would be a 2-3 hours workshop run by a facilitator. Basics:
- Have a clear workshop objective.
- Make clear who should attend the workshop and why.
- Have clear coordinated agenda.
- Make sure logistics questions are managed.
- Make clear to the audience which preparation (pre-reading, etc.) is needed to contribute/benefit most to/from the workshop.
Some workshop techniques:
- SWOT analysis: Focus on strength, weakness, opportunities, threats
- impact/effort grid: four quadrants to asses problems
- rich pictures: draw funny pictures together
- prioritization with dots
- gap analysis: where are we? where should we be? how do we get there?
- brainstorming
- visioning
- the five why’s: A questioning technique to find the root cause
- Dr Edward de Bono’s Six Thinking Hats: https://youtu.be/UZ8vF8HRWE4
Frequent releases
Traditionally, projects would deliver the final product at the end of a waterfall process. This could be longer than 10 years after the initial ideation phase took place. During this time the priorities of your customers, your users, boundary conditions, legal situations may have changed drastically.
So, in combination with a fully operational change management, it is mandatory to have frequent releases to achieve the following
- fast feedback loops
- reduce risk through reducing uncertainty about the correctness of the product
- give positive feedback and confidence to project members that we do the right thing
- foster engagement of stakeholders
- make the release a common practice and thus much easier.
A two weeks planning horizon instead of a twelve month planning horizon reduces uncertainty.
Agile contracting
Traditional contracts would force a supplier to deliver a specific solution based upon
- a specific set of requirements,
- a set of milestones,
- a set of quality expectations and contractual obligations.
This set of contractual items then gets a price tag.
Agile contracts do not work in that way, because on the product delivery level the requirements, the milestones, the quality expectations may change over time.
Here are some guidelines for agile contracting:
- your existing master contract would be suitable to a certain extend for the directing and project management level.
- On the product delivery level concentrate on outcome (i.e. customer value/benefit) rather then on output (artifacts).
- Define the collaboration level and relationship, including responsibilities, customer engagement, etc.
- Create several time-based deliveries as part of the main contract (based around sprints or releases) and use this as a trackable project baseline.
- Allow for the project to be stopped at any time. This translates to “early termination clauses”.
- Buy amounts of time, rather then output.
- Relate incentives to the amount delivered.
- Prioritize stories and identify the MVP/MMP.
- Maybe a “sprint zero” can be used to close issues regarding the contracts.
- Consider a “growing” contract, thus a phased project approach regarding the contract coverage.