PRINCE2 Agile
What are the PRINCE2 THEMES?
1) Business case 2) Organisation 3) Quality 4) Risks: (focus on identifying, assessing and controlling risks) 5) Plan (what to do, who to do it, how to do it Change 6) Progress (ensure project is progressing as per the plan)
What are the PRINCE2 PRINCIPLES?
1) Continued Business Justification 2) Learn from Experience 3) Defined roles and responsibilities 4) Manage by Stages 5) Manage by Exception 6) Focus on products 7) Tailor to suit the project environment
How is the "Continued Business Justification" PRINCIPLE interpreted in an Agile environment?
1) FORECASTING the justification is HARDER because an Agile product is not fully specified upfront BUT 2) TRACKING the justification is EASIER, because of the Frequent Releases
What does PRINCE2 Agile recommend in terms of the planning approach for a PRINCE2 Agile project?
1) Having product-based plans, rather than process-based ones. This means planning the features and functions, rather than steps such as specification and design. 2) Involving the team in planning. The plans are more realistic, and greater team buy-in. 3) Planning as late as possible. Product-related plans should be done as late as possible, so as not to block adaptation, and the need the product to evolve during the project, based on the feedbacks. The value-based and strategic plans are better done as soon as possible.
What are the four Agile "Values"?
1) Individuals and Interactions over Processes and Tools 2) Working Software over Comprehensive documentation 3) Customer Collaboration over Contract Negotiation 4) Responding to Change over Following a Plan
What would be considered typical Agile Concepts?
1) Prioritising what is delivered 2) Working iteratively and incrementally 3) Not delivering everything 4) time-focussed 5) Limiting Work in Progress
What are the PRINCE2 levels of planning?
1) Project Plan The Project Plan should be formal, based on values and strategies, and since it's about very high-level items, some dependencies can be expected among them. 2) Stage Plan The Stage Plan is likely to be formal, in a less or more traditional way. 3) Release Plan Specific to PRINCE2 Agile, and located between the Stage Plans and Team Plans. Each release is a set of iterations, when their output is supposed to be put into operation. Release Plans will likely be in a backlog format rather than classical diagrams. If required, each Stage can be tailored into a Release. In this case, the Stage Plan and Release Plan would be the same. 4) Team Plan / Iteration Plan Team Plans are optional in PRINCE2, but cannot be considered optional in PRINCE2 Agile; while they would be really simplified. They are usually in a backlog format. In case of using Scrum, the Sprint Backlog is the Team Plan.
What would be considered typical Agile behaviours?
1) being collaborative 2) self organising 3) customer focused 4) empowered 5) trusting not blaming
Kanban system
A 'pull system' implemented by limiting the number of Kanban (cards) in circulation.
Kaizen
A Japanese philosophy that literally means 'good change' but is widely understood to refer to continual improvement. It involves everyone contributing on a regular basis to make many small beneficial changes that build up over time to improve the efficiency of the way a team or organization works.
Gantt chart
A commonly used technique for planning work activities against time in the form of horizontal lines or bars showing when the activities start and end. This can then be used to schedule dependencies between the activities. This is unlikely to be of use for a timebox or sprint where time is fixed and the work is ordered dynamically by the team.
Emergent
A concept in Agile that refers to creating solutions and making decisions in a way that gradually converges on an accurate solution and doesn't involve a lot of upfront work. The opposite would be to spend time and try to predict how things will happen. An example would be 'emergent architecture' whereby a lot of work could be done in advance to decide how the product will be built, or work could be started on the product and then the best architecture would emerge as the product develops.
Product description
A description of a product's purpose, composition, derivation and quality criteria. It is produced at planning time, as soon as possible after the need for the product is identified.
Configuration management strategy
A description of how and by whom the project's products will be controlled and protected.
Communication management strategy
A description of the means and frequency of communication between the project and the project's stakeholders.
Product roadmap
A diagram or document that shows the intended development path for a product. This would typically be a long-range plan that may cover several months if not years. It exists outside a project context but could be used to trigger project work.
Plan-Do-Check-Act (PDCA)
A four-stage cycle for process management, attributed to Edward Deming. Plan-Do-Check-Act is also called the Deming Cycle. Plan - design or revise processes that support the IT services; Do - implement the plan and manage the processes; Check - measure the processes and IT services, compare with objectives and produce reports; Act - plan and implement changes to improve the processes.
Information radiator
A general term used to describe the use of walls or boards containing information that can be readily accessed by people working on the project. It can contain any information, although it would typically show such things as work to do and how work is progressing
Feature
A generic term that is widely used to describe something a product does, or the way it does something. A feature can be at any level of detail (e.g. It is waterproof, it makes a tone when switched off) and can relate to a specific requirement, user story or epic. Another similar term is 'function'.
In Agile, what is an Epic?
A high level definition of a requirement that has yet to be fully defined and understood.
Epic
A high-level definition of a requirement that has not been sufficiently refined or understood yet. Eventually, an epic will be refined and be broken down in to several user stories/requirements.
Project plan
A high-level plan showing the major products of the project, when they will be delivered and at what cost. An initial project plan is presented as part of the project initiation documentation. This is revised as information on actual progress appears. It is a major control document for the project board to measure actual progress against expectations.
Backlog
A list of new features for a product. The list may be made up of user stories which are structured in a way that describes who wants the feature and why.
Project initiation documentation (PID)
A logical set of documents that brings together the key information needed to start the project on a sound basis and conveys the information to all concerned with the project.
Lean
A management process aimed at eliminating waste in the supply chain.
Kano
A model, developed by Noriaki Kano, which is used to help understand customer preferences. The Kano model considers attributes of an IT service grouped into areas such as basic factors, excitement factors and performance factors.
Change authority
A person or group to which the project board may delegate responsibility for the consideration of requests for change or off-specifications. The change authority may be given a change budget and can approve changes within that budget.
Benefits review plan
A plan that defines how and when a measurement of the achievement of the project's benefits can be made. If the project is being managed within a programme, this information may be created and maintained at the programme level.
Acceptance criteria
A prioritized list of criteria that the project product must meet before the customer will accept it, i.e. Measurable definitions of the attributes required for the set of products to be acceptable to key stakeholders (PRINCE2 definition). The term is commonly used in Agile for assessing whether a user story has been completed.
Checkpoint report
A progress report of the information gathered at a checkpoint, which is given by a team to the project manager and which provides reporting data as defined in the work package.
Configuration item record
A record that describes the status, version and variant of a configuration item, and any details of important relationships between them. See configuration item.
Baseline
A reference level against which an entity is monitored and controlled.
Issue
A relevant event that has happened, was not planned and requires management action. It could be a problem, benefit, query, concern, change request or risk that has occurred.
Lessons report
A report that documents any lessons that can be usefully applied to other projects. The purpose of the report is to provoke action so that the positive lessons from a project become embedded in the organization's way of working and the organization is able to avoid the negative lessons on future projects.
Constraint
A restriction or limitation that a project is bound by. It may be challenged during an mov study.
Business ambassador
A role in DSDM that is the pivotal role (but not the only role) in understanding the business view of a project.
Definition of 'ready'
A set of criteria that is used to determine if a piece of work is ready to be started.
Definition of 'done'
A set of criteria that is used to determine if a piece of work or a collection of work items are completed. Something is either 'done' or it is 'not done'
Exception
A situation where it can be forecast that there will be a deviation beyond the tolerance levels agreed between project manager and project board (or between project board and corporate or programme management).
Manage by exception
A technique by which variances from plan that exceed a pre-set control limit are escalated for action - for example, where spends exceed budget by 10%.
Burn chart
A technique for showing progress (e.g. Such as with a timebox) where work that is completed and work still to do is shown with one or more lines that are updated regularly/daily.
Product-based planning
A technique leading to a comprehensive plan based on the creation and delivery of required outputs. The technique considers prerequisite products, quality requirements and the dependencies between products.
Brainstorming
A technique that helps a team to generate ideas. Ideas are not reviewed during the brainstorming session, but at a later stage. Brainstorming is often used by problem management to identify possible causes.
Project
A temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case.
Early adopter
A term given to a customer who is one of the first to buy or use a product. They typically may like innovative products and therefore may expect to pay more for them although these products may not be to a level of quality that later customers will receive. This type of customer is very useful for early feedback on the product.
Kanban
A term that often carries multiple meanings at the same time. Written in kanji (Chinese characters), it means 'sign' or 'large visual board.' Written in hiragana (Japanese characters) it means 'signal cards' (singular or plural). In technical presentations of the mechanics of Kanban systems it usually means the latter. Used informally, it refers to the use of Kanban systems (visual or otherwise) and the Kanban method.
Highlight report
A time-driven report from the project manager to the project board on stage progress.
Kanban board
A tool used in Kanban to visually display the work in the system (or timebox). It is usually made up of a series of columns and possibly rows where work items move from left to right as they move through various states in order to be completed.
In Agile, what is a User Story?
A tool used to write a requirement, takes the form of who, what, why.
Disruptive
A widely used term that has more than one definition but in general terms refers to situations where there are high degrees of uncertainty (e.g. With product innovation) and the product being developed will significantly disrupt (intentionally or accidentally) the existing environment or marketplace (e.g. 3D printing).
How is the "Manage by Exception" PRINCIPLE interpreted in an Agile environment?
Agile teams should be empowered. Manage by Exception is PRINCE2's way of empowering different layers of project. In PRINCE2 Agile, enough authority should be given to the development team to ensure that it doesn't block Agility. This is done by setting proper tolerances.
Dynamic Systems Development Method (DSDM)
An Agile project delivery framework developed and owned by the DSDM consortium.
Gap analysis
An activity that compares two sets of data and identifies the differences. Gap analysis is commonly used to compare a set of requirements with actual delivery.
In PRINCE2 Agile, what is "Flow-based" working?
An approach that avoids the use of time boxes and uses a queue where work is continually pulled into the system and moves the various work states until it is done.
Configuration item
An entity (asset) that is subject to configuration management. The entity (asset) may be a component of a product, a product or a set of products in a release.
Backlog item
An entry in a backlog. This may be in the form of a user story or task and may be held in many forms such as in a spreadsheet or displayed on a whiteboard.
Kanban method
An evolutionary approach to change described by David J. Anderson in Six Core Practices and Four Foundational Principles.
Experiment
An investigation into something that is carried out in a series of specific steps (which may involve research) in order to prove or disprove a theory or idea. This can be used to validate an idea or to try and improve something such as the way a team is working.
How does PRINCE2 Agile view Agile?
As a family of behaviours, concepts, frameworks and techniques.
How is timeboxing typically described in PRINCE2 Agile?
As a technique.
How is the "Organisation" THEME interpreted in an Agile environment?
Because Agile teams are self-organized they should find their own way instead of following orders. A complete self-organization is possible only with a flat organization such as Scrum. However, we should still give more authority to the teams in PRINCE2 Agile. The "Manage by Exception Principle" is about delegating power to the lower levels of the project organization; however, the level of authority is up to the management team, and can be very low if they decide so. Even though it limits the project. In PRINCE2 Agile, the level of authority delegated should be higher. The empowerment should be supported by the whole system, and for example, the Baselines should be high-level enough to allow the team to decide on more changes.
Why might an Agile project sometimes need upfront plans?
Because many suppliers cannot afford to lose customers who insist on having a fixed-price contract. It's therefore common to see Agile projects that do have upfront plans. In this case, the customer and the supplier will have a swapping / trading system to enable changes in the project.
Why is an Agile contract different to those of a more predictive project?
Because the work can't be described in detail and is likely to change over the course of the project.
Class of service
Broadly defined category for different types of work. The classes influence selection decisions, in that different classes of service are typically associated with qualitatively different risk profiles, especially with regard to schedule risk and the cost of delay. Four generic classes of service are widely recognized: 'standard', 'fixed date', 'expedite' and 'intangible'.
What would be considered typical Agile techniques?
Burn Charts, User Stories, Retrospectives, Time Boxing, Measuring Flow
How is the "Focus on Products" PRINCIPLE interpreted in an Agile environment?
In Agile environments the product is not clear, and usually focuses on the OUTCOMES and VALUES. The main concern in the original PRINCE2 principle is to avoid focusing on "work", which is a very common problem. Any project is done for its BENFITS and the BUSINESS VALUE it creates. These can be translated into the OUTCOME (expected results). In predictive environments, it's also possible to translate the outcomes into the product, and that's why focusing on the product is good advice. However, this translation is not possible or effective in Agile.
Why is tracking the business justification of an Agile project EASIER than with a predictive project?
In Agile, the product is not fully specified upfront so everyone has to shift focus to the business value at the end of each iteration.
Minimum viable product (MVP)
In a PRINCE2 Agile context the term MVP broadly aligns with the Lean Startup view that it is a 'version of the final product which allows the maximum amount of validated learning with the least effort'. This should not be confused with the viability of the project as a whole. Typically, an MVP would be delivered as early as possible during the project. It is important to note that an MVP is about learning and may not go into operational use; it may be in the form of a simple experiment or prototype.
Lead time/cycle time
Interpreted differently by many in the Kanban community (some see these two terms as representing different things) but in simple terms it refers to how long a work item takes to go through the system or timebox.
How is the "Manage by Stages" PRINCIPLE interpreted in an Agile environment?
Most Agile methods use iterations, during which development processes are repeated for a subset of features, and a new version of working output (increment) is created. PRINCE2 uses stages for MANAGEMENT purposes to make it easier to plan and control the project. PRINCE2 Agile uses the following combination by default- Stage -Release --Iteration --Iteration --Iteration --Iteration The Releases and the Iterations / Sprints are below the Stage level. This means that there are more levels of detail involved in the project, and this also helps with the Manage by Exception Principle. It's possible to simplify this system by merging the Releases and Stages together, or even merge the Iterations, Releases, and Stages.
What apects of PRINCE2 CAN'T be tailored in PRINCE2 Agile?
None of the PRINCE2 Principles can be tailored if the project is to be a true PRINCE2 project
How is the "Tailor to Suit the Project Environment" PRINCIPLE interpreted in an Agile environment?
PRINCE2 Agile needs tailoring, just like PRINCE2. PRINCE2 Agile is a tailored form of PRINCE2 that is more compatible with Agile delivery methods. However, the level of tailoring presented in PRINCE2 Agile is far from enough, and a lot remains for the practitioners.
How is the "Plans" THEME interpreted in an Agile environment?
Predictive projects are planned upfront, and the goal is to follow the plan. Upfront plans are not used in Agile projects the same as predictive ones. Agile projects are still planned but don't use limiting up-front plans.
How is the "Defined Roles and Responsibilities" PRINCIPLE interpreted in an Agile environment?
Roles and responsibilities in Agile tend to use a completely flat organization. However, they still have defined roles and responsibilities. Projects using PRINCE2 Agile should be careful to ensure there are no conflicting responsibilities.
Discovery (phase)
See sprint zero.
In PRINCE2 Agile, what does Project level planning focus on?
Sets of Features and intended releases
Demonstration (demo)
Short for 'demonstration' this is an event where a product or interim product, in whatever state of readiness, is shown to a person or group (e.g. To a customer) in order to get feedback and show progress. The product being 'demoed' could be static (e.g. A paper design) or dynamic (e.g. A working prototype).
In PRINCE2 Agile, what is a Feature?
Something a product does, or the way in which a product does something.
Contingency
Something that is held in reserve, typically to handle time and cost variances, or risks. PRINCE2 does not advocate the use of contingency because estimating variances is managed by setting tolerances, and risks are managed through appropriate risk responses (including the fallback response that is contingent on the risk occurring).
Project brief
Statement that describes the purpose, cost, time and performance requirements, and the constraints for a project. It is created pre-project during the Starting up a Project process and is used during the Initiating a Project process to create the project initiation documentation and its components. It is superseded by the project initiation documentation and not maintained.
Configuration management
Technical and administrative activities concerned with the creation, maintenance and controlled change of configuration throughout the life of a product.
How is the "Quality" THEME interpreted in an Agile environment?
The Agile delivery method helps the team deliver higher quality since fine tuning is not left until the end as in a Waterfall approach, where external pressures may not allow the developers to do so. As a result, quality is somewhat compromised with the Waterfall approach. Because Agile requires smaller pieces of product to be delivered incrementally, this provides the chance to spend more time on all quality activities. So, quality is not compromised in Agile, and this should be reflected in a PRINCE2 Agile product as well.
Agilometer
The Agilometer is a tool that assesses the level of risk associated with using Agile in combination with PRINCE2. This allows PRINCE2 to be tailored in such a way that best mitigates the level of risk. The Agilometer should evolve to suit the needs of each organization.
What is the PRINCE2 Agile definition of a Release?
The Set of products in a handover
What is the difficulty with PRINCE2's "Business Case" THEME in Agile environments?
The difficulty with the Business Case in Agile environments is that it's based on the benefits derived from a "product", while the product is not certain in Agile projects. Because the product is DEVELOPED (and probably DELIVERED) INCREMENTALLY in Agile projects, the justification can be CHECKED IN THE REALITY, instead of being forecasted using a Business Case. When the iterations are as short as a few weeks, risks of continuing an unjustifiable project is very low.
Business case
The justification for an organizational activity (strategic, programme, project or operational) which typically contains costs, benefits, risks and timescales, and against which continuing viability is tested.
Benefit
The measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders, and which contributes towards one or more organizational objective(s).
Level of quality
The overall quality level of a product as defined by the project product description (customer's quality expectations and acceptance criteria).
Planning horizon
The period of time for which it is possible to plan accurately.
Project manager
The person with authority and responsibility to manage a project on a day-to-day basis to deliver the required products within the constraints agreed by the project board.
Project assurance
The project board's responsibilities to assure itself that the project is being conducted correctly. The project board members each have a specific area of focus for project assurance, namely business assurance for the executive, user assurance for the senior user(s), and supplier assurance for the senior supplier(s).
Product owner
The role assigned to managing the product backlog in order to get the most value from it by ordering and prioritizing it.
Executive
The single individual with overall responsibility for ensuring that a project meets its objectives and delivers the projected benefits. This individual should ensure that the project maintains its business focus, that it has clear authority and that the work, including risks, is actively managed. The executive is the chair of the project board. He or she represents the customer and is responsible for the business case.
How is the "Learn from Experience" PRINCIPLE interpreted in an Agile environment?
There's no real difference in learning from experience in Agile projects and predictive ones. The only point worth mentioning is that Agile teams are usually more serious about this principle, and take more advantages from it.
Flow-based
This avoids the use of partitioning work into timeboxes and manages work by using a queue. Work is then continually pulled into the system (which may itself be a high-level timebox) and moves through various work states until it is done.
Iteration/iterate
This term takes many forms in Agile and is perhaps best avoided when using PRINCE2 Agile as it may be a source of confusion. To some it refers to a form of low-level timebox like a sprint. To others it is either an aggregated timebox or a section of a timebox.
Empirical/empiricism
Using evidence to make decisions as opposed to reasoning or intuition.
Project kick-off
Usually, a single event to start off a project where visioning may take place and the team comes together of he first time. These events can be run as workshops and require preparation to ensure that time is used as effectively as possible.
Which aspect of a traditional project management approach is necessary when PRINCE2 Agile is applied?
[]
Devops
devops is a movement, inspired by Lean methodology and Agile development practices, which aims to achieve seamless workflow for product synchronization between all possible organizational functions - especially development and operations groups. A devops approach tries to reconcile the different priorities and processes of these groups, all for the purpose of facilitating greater business agility and delivering more value to the end user.
