Blending PRINCE2 and Agile – Part Four
The quality and risk themes
In PRINCE2 the approach to quality is mainly dealt with by the project product description, the individual product descriptions, the product-based planning technique, the quality register, and ensuring that quality checks/audits involve customer and user representation along with independent authorization and approval.
In an agile environment, product descriptions might be written as user stories or epics. The typical format for a user story is “As a (name of role), I want to (description of function), so that (description of benefits)”.
In addition to including the “who, what, and why” format of the user story, it is important that the product descriptions meet all other PRINCE2 requirements.
For example, a product description contains the quality criteria (which agile approaches may call acceptance criteria, in addition to the skills and resources needed to implement the user story.
So we can see here, that a blend of product descriptions and user stories would enhance the blended approach to quality.
Returning for a moment to the PRINCE2 product-based planning technique (let’s say at the project level rather than stage level for the moment), the idea of having a focus on products rather than just activities, aligns very well with the creation and prioritization of the agile product backlog.
The concept of first agreeing on acceptance criteria at a project level, then going on to breakdown and brainstorm the complete list of products required within the project, creating individual product descriptions along with their quality criteria, and finally taking those products and forming a sequence of product creation, is a good one.
There is some scope here for improvement, in that the product flow diagram showing the sequence of creation of the products within the project normally has a focus on logic – that is, which product should be created first, which second, and so on.
This would result in a diagram showing complex interconnections of products being formed in series and parallel combinations. Again, doing this at the project level is not the agile way to go, as such detail will not emerge/change until the creation of sprints and releases occur throughout the project.
The agile concept of customer value is important, but the decision/prioritization of the user stories based on their value in the product backlog is normally the result of several aspects.
Due to this, the use of a product flow diagram during such a brainstorming session may help bring clarity and structure to the agile process.
The product owner is solely responsible for prioritizing the user stories within the product backlog but will seek advice from the specialist team and customers when doing so.
Harnessing the power of the product-based planning technique with the addition of prioritization can be seen as a good blend of PRINCE2/Agile.
The PRINCE2 planning method does not include any real emphasis on product priority/value, whereas agile does via the creation and continual grooming of the product backlog.
Most agile approaches also attach value to each user story. This is different from the PRINCE2 approach. PRINCE2 would use the word benefit rather than the word value.
One advantage of blending PRINCE2 /agile could be where the project management team attaches a value to each product description, which could help them understand how to prioritize and flex what is to be delivered.
In agile, a form of product breakdown structure is created with products often thought of as super-user stories, or a group of requirements – these are called epics.
Epics can be seen as a group of requirements that are not yet defined, and need to be broken down into more detail. The PRINCE2 project product description could be seen as an epic.
A user story also contains confirmation information in the form of conditions of satisfaction.
These are acceptance criteria that clarify the desired behaviour. They are used by the development team to better understand what to build and test, and by the product owner to confirm that the user story has been implemented to their satisfaction.
In PRINCE2, the project management team would use the product-based planning approach throughout the project to create more and more detailed product descriptions.
In the starting up a project process, the project manager creates a broad high-level description of the main outputs of the project, which is the project product description.
In the initiating a project process, the project manager creates product descriptions of the major products, which describe the outputs at a medium level.
Then in managing a stage boundary, the project manager creates more detailed product descriptions of products to be delivered within the upcoming stage.
You can see how this aligns well with agile with its idea of evolving the requirements for the products throughout the project.
An approach that would be helpful here, would be to baseline or freeze higher-level product descriptions at a reasonable point in time while allowing lower-level product descriptions to evolve as long as their evolution does not impact those higher-level requirements.
Agile delivers the products across of series of iterations called sprints typically no more in four weeks duration. Such a way of working will often involve a much higher frequency of quality checking than in a non-agile environment.
Agile will normally run several sprints for what they call a release, where a high level of customer involvement and feedback will occur, so the project management team will need to plan and budget for this higher frequency of quality checking that is needed to deliver robust products in a short period of time.
To create complicated systems within a relatively short period of time, automated tests are used that can quickly test a lot of aspects of the system when the project is delivering IT/software-type products. this may be difficult to recreate when projects are in a different industry.
In PRINCE2, the project plan states the number of management stages to be undertaken during the project, and this could be aligned easily so that each management stage includes several sprints culminating with a significant release.
Perhaps some form of PRINCE2 “stage product description” could be used here to clarify the acceptance criteria of one or more releases within a stage.
The risk theme
The PRINCE2 Official manual says very little about the treatment of risk within a PRINCE2 agile project, and probably with good reason. After all, many project risks stem from stakeholders and the general project environment, particularly business risks.
A PRINCE2 Project manager would still see risks at the stage/release level when using agile, and so the detailed advice given within the risk theme would still need to apply.
However, the types of risks would change at the delivery level when using agile.
When it comes to creating the project plan, many risks are associated with constraints and assumptions which would still apply with an agile project.
Because the gathering of requirements and planning is done at the start of a traditional waterfall approach project, there are many risks associated with estimating and assumptions made. Each assumption and constraint should be seen as a risk.
And the main risk of a waterfall-style project is the cost of changes and rework due to the large commitment upfront of planning and estimating.
By way of contrast, because agile uses iterative and incremental approaches, this will greatly reduce such risk due to constant customer involvement, welcoming change, and early feedback from the various products, sprints, and releases.
So, spending time considering requirements and designing a solution might lead to a really well-designed solution, but in a dynamic environment there is a risk that customers might change their minds or technologies might change after the requirements have been gathered and documented.
The project management team might not find this out until after they have spent a lot of time designing a solution, building, and testing a product, and finally showing the products to the customer.
This would suggest that a PRINCE2/agile approach should schedule regular meetings with the clients during the design, build, and test phases to ensure nothing has changed.
The agile approach often requires very close collaboration with the customers throughout the project’s life allowing the teams building the product to get a very good idea of what the clients want.
There is always a risk that this close collaboration with the customer does not happen because the customer may not be able to commit much time to the project, and this risk might suggest a way should be determined to communicate with clients quickly and regularly, such as by the use of video conferencing.
Go Here for part five of Blending PRINCE2 with Agile
Is it vital for you to pass your PRINCE2 Practitioner on the first try?
Find out more about my one-to-one personal coaching program ALL my students pass!
One to One PRINCE2 Coaching with Dave Litten
5.0
PRINCE2 Coaching with a personal touch
You get a personalized study and exam preparation plan, containing all agreed schedules and time periods. Regular PRINCE2 study assignments and scheduled regular skype calls – you will blaze your way to become a PRINCE2 Practitioner. Your own personalized PRINCE2 coaching program with an ex-examiner!
Step 1 – Talk to the PRINCE2 COACH
Before you join the course, talk to Dave directly. He can explain what is covered, how he can help you guarantee your PRINCE2 PASS. with Dave Litten as your very own personal PRINCE2 STUDY COACH
Step 2 – Join the PRINCE2 Coaching Program
Once you’ve spoken to Dave and have gotten a solid understanding of what Personal Coaching entails, click the button below to pay for your personal coaching.
Step 3 – Absorb the PRINCE2 Masterclass with your 1-to-1 PRINCE2 Mentor
Enjoy your personal one on one coaching with Dave Litten – PRINCE2 MENTOR. There will be only ONE outcome: Pass The Prince 2 Exam!
The Projex Academy
related posts: