Get Started. It's Free
or sign up with your email address
Rocket clouds
PRINCE2® Agile - Official Agile extension to PRINCE2® by Mind Map: PRINCE2® Agile - Official Agile extension to PRINCE2®

1. Interactive PRINCE2 Agile® Glossary

1.1. Interactive PRINCE2 Agile® Glossary

2. Classic PRINCE2® structure

2.1. PRINCE2® method has 4 integrated elements

2.1.1. Principles

2.1.2. Themes

2.1.3. Processes

2.1.4. Project Environment

2.2. "Magic number 7"

2.2.1. 1. - 7 Principles

2.2.1.1. seven guiding rules / orders

2.2.2. 2. - 7 Themes

2.2.2.1. seven areas of project management knowledge

2.2.3. 3. - 7 Processes (types of processes)

2.2.3.1. seven groups of activities, describing what to do in the project life cycle

2.2.4. 4. Project Environment

2.2.4.1. PRINCE2® methodology adaptation to the environment of the project

2.2.4.2. This means min. the introduction of specific terminology / language

2.2.4.3. Adaptation of the documentation for the needs / requirements of the organization

2.2.4.4. Adaptation of the project in the context of the industry (eg. IT, engineering, etc.) - PRINCE2 methodology is fully general

2.3. What PRINCE2® does not provide?

2.3.1. Specialists aspects

2.3.2. Detailed techniques

2.3.2.1. PRINCE2 is purely general in nature, not industry/domain specific

2.3.2.2. PRINCE2® doesn't cover every aspect of project management.

2.3.2.3. PRINCE2® doesn't specify the use of specific techniques.

2.3.2.3.1. Only techniques that have a specific PRINCE2® approach are described such as product based planning and the quality review technique.

2.3.2.3.2. For detailed project management techniques (see PMBOK Guide)

2.3.3. Leadership capability

2.3.3.1. Even though it is very important that we have leadership on our project and we are motivating the team, how we do that is not addressed in PRINCE2®.

2.3.3.2. Leadership capability, how you lead and motivate your team will vary depending upon circumstance.

2.3.4. Soft-skills

2.3.5. Communication techniques

2.3.6. Human resource management

2.3.7. Contract negotiations

2.3.8. Software for project management

2.3.9. …

3. This freeware, non-commercial mind map (aligned with the newest version of PRINCE2® Agile) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the PRINCE2® Agile method and as a learning tool for candidates wanting to gain PRINCE2® Agile qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

3.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Feel free to visit my website: www.miroslawdabrowski.com

3.1.1. http://www.miroslawdabrowski.com

3.1.2. http://www.linkedin.com/in/miroslawdabrowski

3.1.3. https://www.google.com/+MiroslawDabrowski

3.1.4. https://play.spotify.com/user/miroslawdabrowski/

3.1.5. https://twitter.com/mirodabrowski

3.1.6. miroslaw_dabrowski

4. PRINCE2® Agile consists of: 7 Principles, 7 Themes, 7 Processes, 5 Agile Behaviours, 10 Project Roles, 4 Quality Assurance Roles, 2 Techniques, 2 Procedures, 3 Budget Types, 5 Project Factors, 6 Project Performance Factors (effectiveness aspects), 26 Management Products (divided on 3 types)

5. PRINCE2® Agile - an Agile extension to one of the most popular project management methodologies - PRINCE2®. PRINCE2® Agile describes how to configure and tune PRINCE2® with Agile behaviours, concepts, frameworks and techniques. It gives a guidance for project managers and leaders to incorporate Agile into classic PRINCE2 environment. PRINCE2® Agile is one of the 12 recognized globally and practically proven management standards from AXELOS® Global Best Practice family of UK standards.

5.1. PRINCE2® Agile was published in 06.2015.

5.2. How PRINCE2® Agile fits into AXELOS® Global Best Practices family of UK standards.

5.3. AXELOS® Global Best Practices family of standards from UK.

5.3.1. PRINCE2® Agile

5.3.1.1. see PRINCE2® Agile mind map

5.3.2. ITIL®

5.3.2.1. see ITIL® mindmap

5.3.3. M_o_R® - Management of Risk

5.3.3.1. see M_o_R® mindmap

5.3.4. MoV® - Management of Value

5.3.4.1. see MoV® mindmap

5.3.5. MoP® - Management of Portfolios

5.3.5.1. see MoP® mindmap

5.3.6. MSP® - Managing Successful Programmes

5.3.6.1. see MSP® mindmap

5.3.7. PRINCE2® - PRojects IN Changing Environments

5.3.7.1. see PRINCE2® mind map

5.3.8. P3O® - Portfolio, Programme and Project Office

5.3.8.1. see P3O® mindmap

5.3.9. yet remember - "In reality there are no such things as best practices. There are only practices that are good within a certain context."

5.4. Since 2000 the Office of Government Commerce (OGC), former owner of PRINCE2® (and other Best Management Practices) has been the custodian of the portfolio on behalf of UKG. In June 2010 as a result of UKG reorganisation the Minister for the Cabinet Office announced that the PRINCE2® functions have moved into Cabinet Office.

5.4.1. AXELOS are a new joint venture company, created by the Cabinet Office on behalf of Her Majesty’s Government (HMG) in the United Kingdom and Capita plc to run the Best Management Practice portfolio, now called AXELOS Global Best Practice

5.4.2. https://www.gov.uk/government/publications/best-management-practice-portfolio/about-the-office-of-government-commerce

6. Agile fundamentals

6.1. Agile Manifesto

6.1.1. http://agilemanifesto.org/

6.1.2. 17 It industry veterans met at Snowbird Resort on February 11-13 2001 and created Agile Manifesto

6.1.2.1. Introduced 4 Values and 12 Principles defining Agile for Software Development

6.1.3. disciplines that gave rise to the Agile Manifesto

6.1.3.1. Extreme Programming, SCRUM, Dynamic Systems Development Method (DSDM®), Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming.

6.2. Agile Alliance

6.2.1. http://www.agilealliance.org/

6.3. Agile currently is buzzword, a marketing term

6.3.1. Agile is like any other newly introduced popular concept. “… Everybody is talking about it. Very few are doing it and those who are, are doing it badly” (James O. Coplien)

6.3.2. Agile as a word by it's own simply means - nothing more than merketing term.

6.3.2.1. there are so many Agile methodologies, Agile standards, Agile techniques, Agile tools, Agile good / best agile practices, Agile frameworks etc., that 'Agile' word itself is to general

6.3.2.1.1. see Agile World mind map

6.3.3. Agile is a generic description of a “Style of Working” and Philosophy.

6.3.3.1. Not only style of working on project but rather culture in ENTIRE organization including also it's management level, clients and partners

6.3.3.2. ‘Agile Project Management’ is perhaps an oxymoron

6.4. The Agile Mindset, Values and Principles

6.4.1. 4 Agile Value

6.4.1.1. 1. Individuals and interactions over processes and tools

6.4.1.2. 2. Working software over comprehensive documentation

6.4.1.3. 3. Customer collaboration over contract negotiation

6.4.1.4. 4. Responding to change over following a plan

6.4.2. 12 Agile Principles

6.4.2.1. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

6.4.2.2. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

6.4.2.3. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

6.4.2.4. 4. Business people and developers must work together daily throughout the project.

6.4.2.5. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6.4.2.6. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

6.4.2.7. 7. Working software is the primary measure of progress.

6.4.2.8. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

6.4.2.9. 9. Continuous attention to technical excellence and good design enhances agility.

6.4.2.10. 10. Simplicity - the art of maximizing the amount of work not done - is essential.

6.4.2.11. 11. The best architectures, requirements, and designs emerge from self-organizing teams.

6.4.2.12. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

6.4.3. The unlimited number of Agile Practices

6.4.3.1. The 'forest' of Agile Methods, Frameworks, Standards ...

6.4.3.1.1. see Agile World mind map

6.4.3.2. Being Agile vs Doing Agile

6.5. Agile is a umbrella term enclosing different methodologies, tools, techniques, practices and frameworks

6.5.1. In Agile community umbrella symbolizes different approaches in implementing Agile Manifesto but yet all from them are "Agilelish"

6.5.2. SCRUM, Lean, KANBAN, XP are not ‘Agile Project Management’ practices but rather team level practices

6.5.2.1. No Project Manager role

6.5.2.2. No project definition and etablished project / programme governance

6.5.2.3. ...

6.5.3. see Agile World mind map

6.6. Plan-Driven Projects vs. Change-driven Project Projects

6.6.1. Traditional (waterfall or sequential) Project Management metaphor

6.6.1.1. Railway metaphor

6.6.1.1.1. Moving forward, based on delivering predicted upfront requirements in accepted tolerances with limited tolerance to change, destination (final product specification) is known upfront and it will hardly change to any other destination

6.6.1.1.2. Changing course of train based on requirements

6.6.1.2. a.k.a. Plan-driven

6.6.1.2.1. build around paradigm of process

6.6.1.3. defined process control model

6.6.1.3.1. All work is understood before execution

6.6.1.3.2. Given a well-defined set of inputs, the same outputs are generated every time

6.6.1.3.3. Follow the pre-determined steps to get known results

6.6.2. Agile (iterative + incremental + adaptive) Project Management metaphor

6.6.2.1. Sailing metaphor

6.6.2.1.1. Embracing change of requirements, finding TRUE value for stakeholders by experimenting, testing, changing status quo.

6.6.2.1.2. Adapting / changing course of sailing based on business TRUE business needs and priorities, which could be different than requirements

6.6.2.2. a.k.a. Change-driven

6.6.2.2.1. build around paradigm of change / adaptation

6.6.2.3. empirical (adaptive) process control model

6.6.2.3.1. Frequent inspection and adaptation occurs as work proceeds

6.6.2.3.2. Processes are accepted as imperfectly defined

6.6.2.3.3. Outputs are often unpredictable and unrepeatable

6.7. Agile is best for complex projects

6.7.1. Simple (straightforward)

6.7.1.1. Everything is known and predicatable

6.7.1.2. Characteristics

6.7.1.2.1. Repeating patterns and consistent events

6.7.1.2.2. Clear cause‐and‐effect

6.7.1.2.3. Well establish knowns

6.7.1.2.4. Fact based management

6.7.1.3. Leader’s/Manager’s job

6.7.1.3.1. Use best practices

6.7.1.3.2. Extensive communication not necessary

6.7.1.3.3. Establish patterns and optimize to them

6.7.1.3.4. Command and control

6.7.2. Complicated

6.7.2.1. More is known than unknown

6.7.2.2. Characteristics

6.7.2.2.1. More predictability than unpredictability

6.7.2.2.2. Fact‐based management

6.7.2.2.3. Experts work out wrinkle

6.7.2.3. Leader’s/Manager’s job

6.7.2.3.1. Utilize experts to gain insights

6.7.2.3.2. Use metrics to gain control

6.7.2.3.3. Sense, analyze, respond

6.7.2.3.4. Command and control

6.7.3. Complex

6.7.3.1. More is unknown than known

6.7.3.2. Characteristics

6.7.3.2.1. More predictability than unpredictability

6.7.3.2.2. Fact‐based management

6.7.3.2.3. Experts work out wrinkle

6.7.3.3. Leader’s/Manager’s job

6.7.3.3.1. Create bounded environments for action

6.7.3.3.2. Increase levels of interaction and communication

6.7.3.3.3. Servant leadership

6.7.3.3.4. Generate ideas

6.7.3.3.5. Probe, sense, respond

6.7.4. Chaotic (unpredictable)

6.7.4.1. Very little is known

6.7.4.2. Characteristics

6.7.4.2.1. High Turbulence

6.7.4.2.2. No clear cause‐and‐effect

6.7.4.2.3. Unknowables

6.7.4.2.4. Many decisions and no time

6.7.4.3. Leader’s/Manager’s job

6.7.4.3.1. Immediate action to re‐establish order

6.7.4.3.2. Prioritize and select actionable work

6.7.4.3.3. Look for what works rather than perfection

6.7.4.3.4. Act, sense, respond

6.7.5. See also Cynefin framework (by Dan Snowden)

6.7.5.1. different view on Cynefin Framework

6.7.5.1.1. Five domains

6.7.5.1.2. Can be used to assess the output, outcome or benefit

6.7.5.1.3. Can be used to assess the project environment

6.7.5.1.4. Collaboratively assessed to avoid people’s natural tendencies.

6.7.5.2. https://www.youtube.com/watch?v=N7oz366X0-8

6.7.6. Relating Complexity and Management Style

6.8. Agile is about delivering "best possible value" not maximum possible value

6.8.1. VALUE is NOT the same as BENEFIT

6.8.1.1. Benefits

6.8.1.1.1. Benefit is about outputs

6.8.1.1.2. Benefit is a objective

6.8.1.1.3. Benefit is an advantage to stakeholders (internal or external to the organization)

6.8.1.1.4. Benefit can be financial and non financial

6.8.1.1.5. Benefit can be ...

6.8.1.1.6. Benefit MUST be measurable and observable

6.8.1.1.7. Benefits are identifiable and quantifiable

6.8.1.1.8. Benefits SHOULD have baselines

6.8.1.1.9. Benefits SHOULD have priorities

6.8.1.1.10. Benefits types:

6.8.1.1.11. in general benefit = delivered requirements on time, on budget, within scope etc.

6.8.1.2. Value

6.8.1.2.1. Value is about outcomes

6.8.1.2.2. Value is subjective

6.8.1.2.3. Value can be measurable (if required but not natural to use such techniques in any Agile approach)

6.8.1.2.4. Value can be ...

6.8.1.2.5. Values SHOULD have priorities

6.8.1.2.6. in general value = designed fit for purpose, as small as possible solution

6.9. Agile is about focusing on business value / outcome, not strictly project plan / output

6.9.1. Focusing on value delivery not on fixed product definition or strict adherence to plan

6.9.1.1. That's why most Agile approaches define Project Vision

6.10. Agile respects the urgency and importance of priorities conveyed by the customer / user, most prominently by incremental delivery and flexible sequencing

6.11. Agile respects the common sense that all requirements can not be known at the outset, particularly when the outcomes are intangible and subject to an evolving understanding.

6.11.1. “People don’t know what they want until you show it to them” (Steve Jobs, 1955 - 2011)

6.12. Agile is about empowering people, treating them as intellectual individuals

6.12.1. “You have to learn to manage in situations where you don’t have command authority, where you are neither controlled nor controlling. That is the fundamental change.” (Peter F. Drucker)

6.13. Agile is about working closely and constantly (active two side collaboration) with customer throughout (including more than just feedback loops)

6.13.1. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)

6.14. Agile is about change, constant change which leads to better value

6.14.1. “If a process is too unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach (measure and adapt) is the method of choice“ (Ken Schwaber)

6.14.2. "Move Fast and Break Things" Mark Zuckerberg, Facebook

6.14.3. "Change is the only constant." Heraclitus, Greek philosopher

6.15. Agile thinking / approach often requires mind change and cultural shift

6.15.1. Not every organization is ready for that change!

6.15.2. "It is quite difficult for a highly structured and seniority-based organization to mobilize itself for change, especially under noncrisis conditions. this effort collapses somewhere in the hierarchy" (K. Imai, I. Nonaka, H. Takeuchi)

6.15.3. "Scrum exposes every cultural dysfunction that impedes developing software [...] It is not an approach or process that can be modified to fit the existing organizational culture; the culture must change to enable Scrum" (K. Schwaber, J. Sutherland)

6.15.4. “We cannot become what we need by remaining what we are.” (John C. Maxwell)

6.16. Why Agile Works

6.16.1. 1. The customer's representative is in the driver's seat

6.16.2. 2. Quick reaction to the changing market and needs

6.16.3. 3. More visibility

6.16.4. 4. Ideal environment for development

6.16.5. 5. Self-manged teams

6.16.6. 6. Removes confusion and distraction

6.16.7. 7. No fortune tellers; Plan as you go

6.16.8. 8. Issues are less disruptive

6.16.9. 9. Continuous improvement

7. PRINCE2® Agile Behaviours (5)

7.1. Transparency

7.1.1. The most important elements of this principle come in the form of the common Agile values of honesty, trust, integrity and respect.

7.2. Collaboration

7.2.1. It is more than just cooperation.

7.2.1.1. Empowered, self-motivated teams work as one unit.

7.2.2. Collaboration is about sharing any problems and taking a common approach to find the best solution.

7.2.3. Collaboration does not only mean internal to the team.

7.2.3.1. It is also external, mainly with stakeholders, users and business representatives to make all of them responsible for the success of the project.

7.3. Rich communication

7.3.1. Rich communication is more about face-to-face communication (if teams are not located in one place, then using some high tech communication channels if possible with video camera).

7.3.2. It is generally known that more than 70% of communication is non-verbal, so the advantage of face-to-face communication is in fast and clear understanding, immediately solving problems, etc.

7.4. Self-organization

7.4.1. Means trusting the team to organize the work since they know best how to get the job done.

7.4.2. empower and facilitate the project team.

7.5. Exploration

7.5.1. Is about learning and feedback.

7.5.1.1. It is usually by using experiments, prototypes, and spikes that help better understand the customer expectations, get quick feedback and reduce the impact of mistakes.

7.5.1.2. Faster feedback to the team means that quicker progress can be made.

7.5.1.2.1. The sooner the team solves “known unknows” and uncovers “unknow unknows”, the sooner they can arrive at the right destination.

7.5.2. In order to create the right thing, it is necessary to first know what the right thing is.

8. PRINCE2® Agile cake (a.k.a. layered cake)

8.1. PRINCE2® Agile cake represents the three levels of a project and the important point of the metaphor is that both PRINCE2® and agile have their strengths and we need to play to those strengths

8.2. PRINCE2® is kept on top

8.3. Agile at the bottom

8.4. The middle layer in between them is where the two actually mix

9. PRINCE2® Agile structure

9.1. PRINCE2® has the name to be waterfall method, but is in origin very agile:

9.1.1. 1st priority is the added value for the client

9.1.2. Focus on deliverables and not on activities

9.1.3. Formal split between management and delivery

9.1.4. Specify as late as possible

9.1.5. Priority features (with MoSCoW)

9.1.6. Frequent review deliverables throughout the project

9.1.7. Install a change authority

9.1.8. Implement minor changes informal

9.1.9. Phased delivery

9.1.10. Project manager facilitates

9.1.11. Learn from experience

9.2. Above classic PRINCE2 structire, PRINCE2 Agile touches (on different level of details):

9.2.1. Agile behaviours

9.2.2. Agile focus areas

9.2.3. Agile techniques

9.2.4. Agile concepts

9.2.5. Agile frameworks

10. PRINCE2® Agile Hexagon

10.1. Previous version of PRINCE2 varies time and cost whereas agile does not - therefore they could have been said in the past to be incompatible.

10.1.1. PRINCE2 to embrace agile by applying the six aspects and very importantly their tolerances in an agile friendly way

10.2. Time

10.2.1. Zero tolerance for extra time on all levels of plan

10.2.1.1. Considering that negative tolerance (the project should finish sooner) is not relevant, because the project should deliver “SHOULD” or “COULD” components in the remaining time.

10.2.2. Fix

10.3. Cost

10.3.1. Zero tolerance for extra cost on all levels of plan

10.3.1.1. The project cannot exceed the agreed budget.

10.3.2. Fix

10.4. Quality

10.4.1. Not all acceptance criteria and quality criteria are of equal importance, so they can be prioritised

10.4.1.1. It is necessary to fix essential customer quality expectations, but FLEX-ing those acceptance criteria is more desirable.

10.4.2. Fix and flex

10.5. Scope

10.5.1. Not everything the project aims to create is of equal importance, so they can be prioritised

10.5.1.1. There is zero tolerance (FIX) for essential products, but other products which are of lower priority might not be delivered.

10.5.2. Fix and flex

10.6. Risk

10.6.1. Tolerance to be defined to the needs of the Project Board and Project Manager as this depends on the specific situation

10.6.1.1. Tolerance to be defined according to the needs of the project board and Project Manager as this depends on the specific situation.

10.6.2. Fix or flex

10.7. Benefit

10.7.1. Zero tolerance for the level that is defined as ‘minimum viability’ in the Business Case

10.7.2. Tolerance may be used above the level that is defined as ‘minimum viability’ in the Business Case

10.7.3. Fix or flex

11. PRINCE2® Agile Official publications

11.1. PRINCE2 Agile

11.1.1. ISBN-13: 978-0113314676

11.1.2. Published: 2015

11.1.3. Pages: 360

11.1.4. http://www.amazon.com/PRINCE2-Agile-Axelos/dp/0113314671/

11.1.5. The most important, key position on PRINCE2 Agile® Practitioner exam.

12. PRINCE2® Agile Agilometer

12.1. The task of Agilometer is to best estimate different areas of risk when applying Agile project management.

12.2. The Agilometer consists of six key areas to be used in the assessment of the application of agile within the project.

12.2.1. The project manager performs this analysis and looks for each key area for possible or necessary improvements and gives insight how agile the project can be established.

12.3. This Agliometer is comparable with the agile project questionnaire from DSDM® or AgilePM®.

12.4. The six key areas are:

12.4.1. Acceptance of agile;

12.4.2. Advantageous environmental conditions;

12.4.3. Ability to work iteratively and deliver incrementally;

12.4.4. Ease of communication;

12.4.5. Level of collaboration;

12.4.6. Flexibility on what is delivered.

13. PRINCE2® Agile Targets (5)

13.1. They introduce a way of thinking which, although common in agile, are perhaps not always at the forefront of more traditional project management approaches.

13.2. 1. Be on time and hit deadlines

13.2.1. Being on time and hitting deadlines using time-boxing techniques is already familiar to many agile practitioners and this enables the earlier realization of benefits for the customer.

13.2.2. Why this is important?

13.2.2.1. Early realisation of benefits

13.2.2.2. Helps with planning

13.2.2.3. Gives confidence

13.2.2.4. There may be no choice

13.2.2.5. Reduce the likelihood of cost overruns

13.2.2.6. Improves reputation

13.3. 2. Protect the level of Quality

13.3.1. Protecting the level of quality of the delivered product(s) reduces their overall cost of ownership and increases user engagement.

13.3.2. Why this is important?

13.3.2.1. Damaging effects result from:

13.3.2.1.1. Reduced testing

13.3.2.1.2. Incomplete documentation

13.3.2.1.3. Sub-optimal design

13.3.2.1.4. Lack of appropriate training

13.3.2.1.5. Non-compliance to standards

13.4. 3. Embrace change

13.4.1. Embracing change enables the delivery of products better able to meet users’ needs - so bringing about more beneficial business outcomes.

13.4.2. Why this is important?

13.4.2.1. It is inevitable

13.4.2.2. A more accurate final product is more likely

13.4.2.3. Can be handled by flexing what is delivered

13.5. 4. Keep teams stable

13.5.1. Keeping teams stable enables teams to work more efficiently.

13.5.2. Why this is important?

13.5.2.1. Changing team members can have a detrimental affect such as:

13.5.2.1.1. Time spent bringing new team members up to speed

13.5.2.1.2. Number of communication lines in the team grows exponentially

13.5.2.1.3. An opportunity cost incurred to the areas providing the new people

13.5.2.1.4. The team dynamics change and need to be re-established

13.6. 5. Accept that the customer doesn’t need everything

13.6.1. Accept that the customer doesn’t need everything which was defined on the project at the start. As the project progresses it is typical for users to evolve their understanding of what is required and the project needs to reflect this.

13.6.2. Why this is important?

13.6.2.1. Usually, not everything defined at the start must be delivered

13.6.2.2. Many functions and features are rarely, or never used

13.6.2.3. It is the safest area to compromise on

13.6.2.4. This helps when trying to hit deadlines and protect the level of quality

13.6.2.5. Delivers what the customer really wants more quickly

14. PRINCE2® Agile Guidance Points (8)

14.1. 1. PRINCE2 (2009 version) is already enabled for use with Agile

14.2. 2. PRINCE2 is suitable for any style of project and is not a 'traditional' project management approach as is typically contrasted to Agile

14.3. 3. PRINCE2 Agile is for any project and not just for IT projects

14.4. 4. IT only' frameworks and techniques are mentioned in PRINCE2 Agile but not extensively

14.5. 5. There is much more to Agile than the Scrum framework. Agile is not Scrum

14.6. 6. The most 'commonly used' Agile approaches are Scrum and Kanban, but they are not suitable for managing a project in isolation. However, they can be effectively used in a project context.

14.7. 7. The term Agile (in this manual) refers to a family of behaviours, concepts, frameworks, and techniques

14.8. 8. Using Agile on a project is not a question of 'yes or no'. It is about 'how much'