- Rich communication
- Self-organization (means that the team finds its own way instead of receiving orders. Well, at least to a level)
- Exploration (basically means adaptation)
Our next topic is tailoring themes, and we’ll start tomorrow with the first theme: Business Case.
What should we consider for Business Cases in Agile? What would be different?
Levels of requirement specification
A very high-level understanding of the product is required in the pre-project period, and the result will be the Project Product Description. It has to be more outcome-oriented rather than product-oriented, and really high-level. If it’s not high-level enough, it will block out adaptation (Agility).
Then we turn our initial definition into more elaborated Product Descriptions in the Initiation stage. Again, you should make sure they are not too detailed. The Product Descriptions will be later broken down into smaller items during the delivery stages, and they will probably form a Product Backlog. Well, it’s really up to you, and if you want, you can have your Product Descriptions in your Product Backlog; it all depends on your tailoring.
PRINCE2 Agile considers the higher-level requirements as baselines and their changes as “negative”; which means changes in those high-level requirements need traditional change control mechanisms. However, the team is free to change the detailed (smaller pieces of) requirements to match the expectations. In order to facilitate it, and also support adaptation and timeboxing, we need to prioritize the requirements.
PRINCE2 Agile accepts different types of priritization, but prefers the Atern’s approach: MoSCoW. That’s when we consider each requirement a “must have”, “should have”, or “could have”.
We need to adapt in Agile environments and adaptation is impossible without proper communication. That’s why we have a “rich communication” focus area in PRINCE2 Area. Can you mention some of the communication tools, techniques, or guides that are common in Agile?
Some parts of the PRINCE2 Agile manual are exact copies of the PRINCE2 manual, which are differentiated with a light blue background. The rest of the manual explains 3 main topics:
- Generic Agility concepts, and the way PRINCE2 Agile is supposed to be used
- Tailoring (principles, themes, and processes)
- Focus areas, which are the extra things you need to have in mind when you want to further tailor the standard and use it in your environment
I’ll start with the focus areas, because I think it will make it easier for you to proceed to the tailoring part.
These are the focus areas:
- The Agilometer
- Rich Communication
- Frequent Releases
- Agile Contracts
- PRINCE2: project management methodology
- MSP: program management methodology
- MoP: portfolio management methodology
- P3O: a standard about PMOs
- MoV: a standard about value management
- M_o_R: a standard about risk management
- P3M3: management maturity model
- ITIL: IT service management
- RESILIA (also new): preventing and detecting cyber attacks
like an extension to the mature and old standard, PRINCE2. This first
edition can be seen as the first step in a long path we have ahead of us
for creating a great Agile methodology.
PRINCE2 Agile is not authored by a team, as we usually expect from standards. It has been authored by Keith Richards. Lawrence Cooper has helped him as a mentor, 19 other experts as advisors, 9 others as supporters, and 13 people, including me, as reviewers.
The starting idea for PRINCE2 Agile was that PRINCE2 is neutral on the delivery method and can be used both in traditional and Agile environments. However, people do not know exactly how to use it in Agile environments, and that’s the reason we have this new standard.
What approach do you expect from PRINCE2 Agile? Should it be compatible with PRINCE2, or should it be something just similar to PRINCE2 that is different in the fact that it’s Agile? Let’s talk about it tomorrow.