Blending P2PM with Agile
Part One – P2PM Agile Environment Overview
P2PM has been designed to work within any environment any industry and any size or complexity of the project, and this includes Agile which is simply another common environment that P2PM can work effectively within.
The term agile refers to a collection of approaches that originally evolved from the software industry going back originally to the 1990s. Examples of such approaches would include rapid application development (RAD), the dynamic systems development method (DSDM), and scrum.
Back in 2001, a consortium of experts in agile approaches published the Agile Manifesto which outlined the four principles of an agile approach:
>> individuals and interactions are valued more than processes and tools
>> working products are valued more than comprehensive documentation
>> customer collaboration is valued more than contract negotiation
>> responding to change is valued more than following a plan
But agile is no longer seen as a method or framework just used for software development, as over the last decade agile approaches have started to be used successfully in many industries for projects of all sizes and levels of complexity.
My objective here is not to teach you agile but to make you familiar with some of the common ideas in terms of agile to understand how P2PM can be blended or tailored for it.
Agile approaches deliver their products over a series of iterations rather than all at the end of the project (also known as The Big Bang approach!).
Such iterations are often referred to as Sprints or Timeboxes, and these are typically quite short – no more than four weeks in duration. In a typical agile project, you may find several sprints performed in series that together make up a release.
Such sprints bring several benefits:
Even though the clients will not get everything they want in earlier releases, at least they do not have to wait too long until they get some useful products
Releasing in short bursts avoids the situation where if a deadline is a long way off, the natural human tendency is to prevaricate and work more slowly
The deadline for a release is always only a few weeks away which motivates the team to get down to their work
There is always the risk that whatever the teams are creating at the moment, may not really be what the client wants
Clients will do their very best to put across and define their requirements, and suppliers can do their best to understand them, but very often the only time when a client can really see if the supplier understood them is when they are handed the final product
Agile calls this failing fast since it’s obviously better to know you’re doing the wrong thing as quickly as possible.
Finally, the client can give feedback to the teams when they start using products from earlier releases, which can help the team create better products in later releases
Rather than planning everything up-front which is what traditional projects do, there are two techniques often used together which need clarification:
The first is called iteration or iterative development
This acknowledges that we will probably get things wrong before we get them right and that we will do things poorly before we do them well. In this way, iterative development is a planned rework strategy using multiple passes to improve what we are building so that we can converge on a good solution.
Iterative development is an excellent way to improve the product as it is being developed.
The second is called incremental development
Which simply means “build some of it before we build all of it”. In this way, we avoid having one large Big Bang-style event at the end of development where all the pieces come together, and where the entire product is delivered.
Instead of that, we break the product into smaller pieces so that we can build some of it, learn how each piece is to survive in the environment in which it must exist, adapt based on what we learn, and then build more of it.
Incremental development gives us important information that allows us to adapt our development effort, and to change how we proceed.
The scrum method (one of the many agile frameworks) for example, leverages both iterative and incremental development by using both ideas within a Sprint.
P2PM is entirely compatible with this agile iterative way of delivering
Indeed, one of the P2PM principles is managing the project by stages, where the project team could release products at the end of each stage if required.
Similarly, you can see that this focus on delivering regularly is aligned with the P2PM principle of focus on products.
The use of sprints or timeboxes is another agile concept
With an agile approach, it is quickly found out if there’s been a miscommunication about requirements and this will save more time and money than if everything is delivered at the end of the project.
Whereas a traditional project will agree on the requirements, project scope, cost, and timescale up front, an agile project via the sprints, would prioritize the requirements from the customer benefits perspective, then convert these requirements into one or more products within each Sprint.
But here’s the trick.
Each Sprint has an agreed-upon completion date (remember, no more than four weeks in duration), with a fixed team (and hence fixed cost), leaving the scope of the Sprint to be varied if needed.
NOTE: In case you are wondering what happened to quality as a variable, don’t worry. As each sprint is planned (by the specialist team), they agree for each product on what “Done” means. This is in concert with the P2PM product description management product containing the product quality criteria.
Put simply, the product is not “Done” until and unless it meets its quality criteria.
What this means in practice, is that the scrum team working inside the Sprint will complete what products they can by the end of the Sprint, and any partially built products or products not yet started, are returned to the prioritized requirement list.
The Product Backlog
This prioritized requirement list is known as the product backlog, and as I’ve suggested above, each requirement forms part of a prioritized list with the most beneficial requirements to the customer being at the top of that list.
These are also the most clearly understood and defined products since they are to be completed first.
Whereas User Stories/requirements near the bottom of the prioritized Product Backlog will be those of less customer value and those whose definitions/requirements are not yet known or defined in sufficient detail.
So, as you can see, the team must be given some flexibility on the scope of the work that they need to create.
There is an element of P2PM called “tailoring the progress theme”, describing how you can use scope tolerances and the P2PM principle of managing by exception to implement this agile idea.
Returning to the product backlog for a moment.
Although I’ve used the word requirements since you understand what that means, agile prefers to use a different term to suggest flexibility around what the customer wants, so agile approaches use the term User Stories.
The typical construction of a User Story is:
“As a (user role) I want to (goal) so that (benefits)”
User stories are a better word because they describe the particular journey that a user would take with the products.
The advantage here is that user stories as the name suggests, restate the requirement in terms of who the user is, what they want to do with it, and the benefits obtained.
If these user stories are big, it can be referred to as epic.
Focusing on what to deliver by prioritizing the value is directly aligned to the P2PM principles of focus on products and continued business justification.
As you will learn later, one of the principles of P2PM is defined roles and responsibilities while many of the agile approaches also have certain defined roles. I will later describe how such roles can work together.
Let’s meet up again in Part Two of Blending P2PM with Agile where you and I will look at the Agile environment, and how it works with the P2PM organization.
Would you prefer a P2PM ex-examiner to personally coach you one-to-one to become a P2PM Practitioner?
One to One P2PM Coaching with Dave Litten
P2PM Coaching with a personal touch
You get a personalized study and exam preparation plan, containing all agreed schedules and time periods. Regular P2PM study assignments and scheduled regular skype calls – you will blaze your way to become a P2PM Practitioner. Your own personalized P2PM coaching program with an ex-examiner!
Step 1 – Talk to the P2PM COACH
Before you join the course, talk to Dave directly. He can explain what is covered, how he can help you guarantee your P2PM PASS. with Dave Litten as your very own personal P2PM STUDY COACH
Step 2 – Join the P2PM 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 P2PM Masterclass with your 1-to-1 P2PM Mentor
Enjoy your personal one on one coaching with Dave Litten – P2PM MENTOR. There will be only ONE outcome: Pass The Prince 2 Exam!