Introduction to the five focus areas
Any implementation of PRINCE2 Agile that combines the flexibility and responsiveness of agile with the defined governance of PRINCE2, demands a clear understanding and consideration of five focus areas. Each of these focus areas in PRINCE2 Agile is important in managing the project effectively and ensuring the successful delivery of project goals in a flexible, agile environment.
The Agilometer
This focus area aims to guide how one can evaluate an agile environment for the optimal customization of PRINCE2. Each project varies due to factors such as customer-supplier trust, technology in use, or levels of uncertainty. Thus, pre-planning on leveraging these variables for project success is crucial from an agile standpoint.
To reap the most rewards from PRINCE2, it’s important to modify it to match the context and conditions. PRINCE2 Agile introduces a tool which is useful to measure the suitability of a project to the use of Agile is the Agilometer. The Agilometer offers additional guidance concerning agile considerations, establishing a level of control and predictability without being overly rigid.
Imagine you’re driving a car, which is equipped with many features to ensure a safe journey. However, the driver’s decisions are essential for appropriate control under varying conditions. Similarly, assessing the conditions in advance of a project improves the chances of successful, effective execution.
When to assess suitability
Agile suitability is assessed throughout the project, specifically during pre-project and initiation stages. The findings of these assessments are incorporated into the project brief and the project initiation documentation to inform the project board, enabling them to make informed decisions on areas of potential risk or benefit.
What is assessed
The Agilometer evaluates six key areas, and the project manager gathers input from the main stakeholders on how to score each category. It is important to see the Agilometer as a decision-making tool but not a decision-making one. Each category should be considered independently without creating an average score across all areas.
Identifies risks and benefits of using agile
The Agilometer is designed to identify potential risks and benefits of using agile. A correct usage example could be, “The collaboration score is low: how can we enhance it?” while an incorrect usage might be, “The average score is 3.9, thus the context is agile-friendly.” It’s crucial to realize that averaging the scores can mask valuable information.
Any application of Agile must suit the project’s context and conditions. As an example, applying agile while constructing a nuclear submarine will differ significantly from introducing a new chocolate bar for a confectionary company. PRINCE2 Agile emphasizes the factors that must be considered and provides possible action plans. Customization is crucial, as no two projects are alike.
If conditions are too risky for substantial agile use, the Agilometer will suggest considering other approaches. This could occur even during the project, warranting exception handling. The ultimate goal in tailoring the approach to a project is to determine “How much agile can we use?” rather than a binary decision. In PRINCE2, projects exist on an agile spectrum, reflecting varying degrees of agility.
Requirements
This focus area emphasizes the methods of identifying and ranking requirements or user stories to facilitate agile methodologies.
PRINCE2 Agile interprets requirements from multiple perspectives:
- Tasks, required to meet a requirement or generate a product, can show up on a team plan or sprint backlog, but PRINCE2 Agile does not consider them as requirements.
- Requirements are either functional (what the product does) or non-functional (how effectively it does it).
- Various terms like function, feature, user story, requirement are often used synonymously within PRINCE2 and agile communities, though they might not denote the same thing.
- ‘Requirements,’ ‘product descriptions,’ and ‘user stories’ are frequently used interchangeably as they often point to the same thing. The term chosen depends on the context.
Requirements in agile
In an agile setting, requirements act as the ‘currency’ for the agile team. The focus shifts from managing time and cost to handling and trading requirements.
Defining a requirement is crucial. Good requirements ensure the accurate depiction of the product. This process needs relevant technical skills and techniques like interviews and process modelling.
For instance, consider a project to deliver a new kitchen. The requirements help define what the customer envisions as ‘a kitchen’. The importance of requirements is also evident in product-based planning in PRINCE2, which, like Scrum‘s ‘done’ and ‘acceptance criteria’, focuses on the product’s end state.
When blending PRINCE2 with agile, it’s vital to detail product descriptions appropriately and let them evolve over time. Excess or lack of detail can hamper the fluid nature of agile, leading to misunderstanding, rework, delays, and frustration.
Defining requirements at the right level
Ensuring that requirements are defined at the right level for each project stage is key. This usually follows a three-step process, akin to just-in-time inventory management, with high, medium, and detailed requirements being defined at the pre-project, initiation, and delivery stages, respectively.
Prioritising requirements
Continual prioritisation of deliverables and work is critical in using PRINCE2 in an agile context. Two common prioritization approaches are MoSCoW and ordering (1, 2, 3 … n), employed as per the uncertainty level of the work. The choice of approach is dictated by the level of uncertainty of the work being undertaken, with MoSCoW often serving as the default approach.
To ascertain if a requirement is a ‘must’, you can ask if the product is operational without it. This not only determines the necessity of features but also highlights the project’s overall objective. Some features may be essential, others not, and there could be alternatives for non-essential features.
Dealing with changes
Change is a constant in projects. PRINCE2 Agile distinguishes two types of change: detail and baseline. Changes that refine the final product are positive, whereas changes that alter the project product description impact the project’s baseline. Dealing with scope creep requires proper governance and defining quality criteria as a spectrum, rather than a binary condition.
Regularly prioritizing requirements or user stories is integral to agile methodologies. The act of prioritization, essentially ‘maximizing the amount of work you are not doing’, allows you to meet deadlines, maintain product quality, and adapt to changes for a more accurate end product.
Rich communications
This focus area aims to mitigate the many prevalent communication issues on projects and identify the optimal methods for effective information exchange among project stakeholders. Recurring communication challenges in projects can often pose the greatest hindrance. Since potent communication is integral to agile project management, it requires deliberate efforts and strategic management.
Types of communication
Numerous forms of communication are employed across different levels of a project. It could be as simple as sharing meeting timings via email, or as complex as discussing a team member’s performance issues. Information exchange can occur through various mediums such as written documents, calls, videoconferencing, or in-person meetings. Furthermore, it encompasses several formats from raw data to knowledge and wisdom, following the DIKW (data, information, knowledge, and wisdom) hierarchy.
Successful communication
For successful communication within a project, it is important to choose the most suitable methods and timing. Communication is the lifeblood of a project, but ensuring smooth communication in a project can be challenging. Whilst a small co-located team working on a single product can communicate efficiently due to the speed and clarity of their exchanges, a newly formed project team working on a complex project is prone to communication hitches.
PRINCE2 Agile pays special attention to this situation as maintaining seamless communication is pivotal for project success. Breakdowns in communication within an agile context can be detrimental.
Communication efficiency
Improving communication efficiency involves choosing the most suitable medium for message delivery. Teams often employ diverse communication methods such as written documents, emails, instant messaging, visual illustrations, and verbal exchanges over calls or face-to-face interactions.
Maximizing the effectiveness of PRINCE2 and optimizing project management entails channelling communication through the most efficient means. Face-to-face communication, ideally supported by visual aids, is one of the most effective methods. This is why a team room, where everyone is co-located and has easy access to information, is considered ideal.
Communication hurdles
Nevertheless, project complexity, involving numerous teams and individuals, can create hurdles for communication. Therefore, it’s vital to prioritize swifter, clearer communication channels such as phone calls rather than emails, and in-person interactions over phone calls.
Technological solutions, like webcams and collaboration tools, should be evaluated for their potential to simplify and enhance communication. The project management team needs to agree on the nature, frequency, and formality level of communication. Understanding when to use informal channels and when to officially document decisions is crucial. These guidelines should be outlined in the communication management approach, which could be informally displayed as part of an information radiator.
Frequent releases
The essence of this focus area is to underscore the significance of regular releases in the agile framework and deliberate on factors to consider during release and project planning. This area also discusses managing situations where immediate operational deployment of a release is not feasible. This facet has a close association with the plans theme and configuration management.
Regular delivery
Regular delivery of useful components is a fundamental tenet of all agile methods. Regular delivery enables early benefit realization for the customer, feedback acquisition, risk reduction (such as delivering an incorrect product), assurance through visibility and proof of project progress, stakeholder engagement, and simplifying the release process.
Strategizing for regular deliveries and planning requires thoughtful consideration due to the multiple trade-offs involved. In traditional projects, the final product was often delivered using a linear or waterfall approach where technical phases led to a complete product delivery at the project’s end.
Planning for regular delivery
However, agile uses plans which are based on features and requirements instead of technical phases. In the project initiation stage, PRINCE2 Agile contemplates how to partition the final product into manageable portions and which sections can be delivered earlier to harness the benefits.
Product-based planning can be employed for release planning, and quality criteria can be established for various product ‘states’, aligning with releases. Alternatively, products can be assigned to a release backlog as necessary. This latter approach may be more fitting for projects with multiple releases and substantial changes in release content.
Incorporating release planning into PRINCE2 plans is important. Both project and stage plans should clearly outline expected releases, their timelines, and featured content. All levels of planning should be aligned with release planning.
The release content and timing should not be trivialized or viewed as incidental. The gradual product release will directly impact benefit realization and justify the project’s continuance. Release planning’s importance should be understood not just by the delivery team but also by the project board.
Lean Startup approach
The Lean Startup approach emphasizes a release strategy that maximizes product viability and encourages ‘fast failure’, if inevitable. A well-structured release plan can generate early feedback and present opportunities for swift responses.
The frequency and regularity of releases (creating a ‘heartbeat’ or cadence) should be collectively decided by key project stakeholders. Rapid product delivery might overwhelm the customer, leading to operational disruptions.
In an ideal scenario, each release should enter the operational environment to leverage the advantages of frequent delivery. However, this may not always be achievable or desired. If a release doesn’t enter operational use, it may not generate benefits or tangible customer feedback. The agile approach may be limited if a different company or department handles the release process and its impacts due to contractual obligations or other stakeholder needs.
Frequent releases of products and sub-products offer significant advantages and are vital to iterative and incremental approaches that distinguish agile from traditional product development methods. Approaches like Kanban and Lean Startup strongly advocate frequent customer delivery to exploit these benefits, with the ultimate objective of continuous release if conditions permit and the advantages are realized.
Creating contracts
Agile methodology, in essence, champions collaboration and shared risk between a client and a service provider, a concept that sometimes conflicts with the typical contract setup, which often appears combative with stipulations for legal recourse in case of difficulties. For a project using PRINCE2 Agile, there is a choice to be made between employing current practices or adopting an alternative structural setup more compatible with the agile approach.
Traditional contracts
Traditional contracts, as a rule, detail specific solution or output delivery, defined by a set of comprehensive, and sometimes intricate requirements, along with a deadline and pricing. However, given the unpredictable nature of projects, it is likely that these detailed requirements might change over time, just as the estimated time for completion could shift.
Problems with traditional contracts
The primary challenge with such a contractual structure is the inevitability of alterations in requirements and workload understanding, and the ensuing negotiation over who bears the cost of these changes or incorporating this uncertainty as a contingency in the contract (for example, the service provider may inflate the price by 20%).
Agile is amenable to change
Agile, by design, is amenable to changes, considering them a natural course of action rather than a detrimental occurrence. If the changes lead to a solution better aligned with the client’s real needs, possibly delivering more value than initially intended, they are deemed positive. Consequently, the contract structure in an agile environment should foster collaboration between the client and the provider, optimizing the solution to maximize client value. A contract focused solely on the solution might not achieve this desired effect.
Contracts using agile
The cornerstone of structuring a contract compatible with the agile approach lies in understanding the level of trust and collaboration between the client and the service provider. Trust, a complex aspect to address in a contract, should ideally support collaboration (including incentives and commitment levels), since contracts typically cover potential issues. High levels of trust and collaboration could exist between a client and a provider with a longstanding relationship. In contrast, these factors might be uncertain and hard to gauge for a new supplier-client relationship.
Importance of trust and collaboration
These trust and collaboration levels matter greatly, as they determine the distribution of risk between the client and the provider, with the risk relating to project uncertainties. When unexpected factors emerge during the project, the cost of change becomes a point of contention—should the service provider bear it for not foreseeing it or the client for not specifying it? Or should the cost be shared, acknowledging the inherent uncertainties and unknowns in the project? More trust and collaboration between the client and provider decreases the chances of:
- The provider adding a contingency premium to the contract price, corresponding to the risk involved.
- The client overly detailing the project initiation to eliminate uncertainty, sometimes known as the ‘illusion of certainty’.
Can use existing frameworks
Adapting existing contractual frameworks to the agile methodology doesn’t necessarily entail creating an entirely new contract type. Existing frameworks in use by organizations may largely remain relevant (such as a master agreement). However, modifications at lower levels would be required to accommodate the agile approach (like changes in a Statement of Work (SOW), applicable to a time period like a sprint or a release).
Benefits of agile contracting structuring
In the context of agile, certain contract structuring guidelines are more likely to be beneficial for both parties compared to the traditional contract style:
- Where possible, shift the focus of delivery from ‘output-based’ to ‘outcome-based’. An outcome focus pertains to the benefits and value enabled by a project, allowing the client and provider to work together to adjust the output or product throughout the project to deliver something more valuable when the opportunity presents itself.
- Clearly outline the level of customer involvement needed during the project, defining time commitment from the client to benefit from the collaborative working relationship. A collaborative relationship between the client and provider in an agile setting will enable faster decision-making, accuracy of deliverables, and ownership of products.
- As part of the main agreement, create several time-based deliveries (like sprints or releases), which can be used to monitor the overall project against an agreed baseline relating to the project’s value delivery. This enables the client to gauge the project’s progress.
- Incorporate a provision for the project board to terminate the project at any point. This gives the client the flexibility to halt the project if feedback from early deliveries indicates that the project as a whole is no longer viable.
- Link incentives to the amount delivered. If the service provider delivers everything intended within a particular timeframe, they receive the full remuneration agreed (or more). Lesser deliveries could then be on a sliding scale.
- Define requirements at a high or intermediate level in the contract, not in detail. This allows the correct products to emerge during the project without the need to control and change the baseline created during project initiation.
- Prioritize requirements so that the most valuable ones are delivered first, and the less critical ones can be used as contingency to protect the quality of what is delivered and to meet deadlines.
- Handle requirement changes by ‘trading’ new ones for existing ones.
- Based on the trust level between the client and the provider, it may be agreeable to create a contract with minimal clauses and add more when needed.
An agile contract should ideally foster desirable behaviours; a shift from a solution-based view to one based around throughput or outcomes can help achieve these beneficial behaviours. Structuring a contract in alignment with the agile methodology is advantageous when using PRINCE2 Agile, as the client and provider should be continually responding to change to deliver the highest value possible within the defined timescale. This requires a contract that supports the objective of delivering value and allowing for change.
Summary of the five focus areas
Understanding and paying heed to these five focus areas when implementing PRINCE2 Agile is crucial to its successful execution. They collectively form the foundation for effective communication, understanding of requirements, risk management, frequent delivery of valuable results.
They also aid the creation of agile-friendly contracts which ensure a shared understanding and collaborative approach towards changes and uncertainty. This promotes shared risk ownership and a collaborative project environment. Together, these areas aid in building a responsive and successful project management environment in line with the principles of PRINCE2 Agile.