One of the most common questions we get from PMO practitioners when talking about delivering projects with Agile techniques is “how do I assure Agile projects?”. Assurance is one of the most important services a PMO can provide an organisation, and for many, it seems like projects with Agile delivery cannot be assured. Is this really the case? Here we will argue that it is absolutely possible to do assurance on projects with Agile delivery, but as a PMO (or another assurance practitioner) you may need to tweak your thinking and approach, both to get value from doing assurance and also to make sure you do not stop the project delivered with Agile from being Agile (after all… there must be a good reason Agile methods have been chosen to deliver the project… right?!)
Why is there tension between projects delivered with Agile and doing assurance?
Assurance is a process done to give confidence to the organisation and stakeholders that the project is managed in a way that is likely to result in the outputs we need to achieve outcomes. In a traditional/linear/waterfall/predictive (there are many names for projects with non-Agile delivery!) project we can do assurance by verifying key deliverables exist, are of suitable quality and are being reviewed and updated regularly.
Typical deliverables in ‘traditional’ assurance include:
- Scope statement clarifying what is in and out of scope
- A schedule detailing when all work required to deliver the scope will be done and by whom
- RAID logs detailing risks and how they will be managed
- Budget documents explaining what money will be spent and where
- Benefits realisation plans
- …As well as other items depending on the needs of the organisation’s governance
Why would this be a problem for a project with Agile delivery? Well, at the heart of the matter is this fact: Projects with Agile delivery are fundamentally different from Linear/ Waterfall/ Predictive projects (Note: we’re talking “real Agile” here, not a waterfall project that has borrowed a couple of words from Scrum methodology and claim to be Agile).
As an Assurance Practitioner there are two key factors you must understand:
1) Agile requires a fundamentally different approach to project management
In a Waterfall project, it is vital that there is a clearly defined and documented statement of scope on which all plans, deliverables and work are based. In other words: we figured out what we are supposed to deliver, then we figure out what resources and time we need to make that happen.
It is in situations where it is not possible to define scope upfront that Agile is appropriate. Whether it is because the project is so new or innovative that it is impossible, or because we expect so much change that there is little value in detailing our scope and subsequent schedule upfront, Agile provides a structure for how to move forward with discipline and rigour to ensure the project still delivers value.
So, by its very definition, a project with Agile delivery will not have a scope statement (if we are able to define scope up front and we work in an organisation that values “traditional” assurance then Agile is probably not a suitable delivery approach for the project!) and if there is no scope statement we cannot build a detailed schedule or budget for the entire project upfront.
2) Project with Agile delivery value documentation differently
Because of the different approaches to scope management teams that work with Agile must have an ongoing, close collaboration with the customer/ end-user to continuously re-evaluate and learn what is the most important thing to work on and deliver. In order for this to be smooth and swift (some would call it… agile…) interactive tools such as Kanban boards are used to track work, and traditional tools such as schedules and Gantt charts are avoided.
For this reason, a project delivered with Agile is not likely to have or maintain the deliverables typically reviewed in “traditional” assurance.
This approach to working was first outlined with the publication of the Agile manifesto (below). It is important to note that the manifesto does not say that there can be NO documentation. It is simply saying that collaboration, interactions and working software (or product) is more important than solid documentation.
The Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
So assurance and Agile projects, is it an impossible match? No, absolutely not! But if you are an assurance practitioner you may need to tweak your thinking and approach to make sure you get the assurance you (i.e your organisation’s governance) need and that the organisation still gets the expected value from delivering projects with Agile.
Three ways to deliver assurance and Agile projects successfully:
1) Ensuring Agile is done right
You will need to learn about the Agile artefacts and ceremonies and the values that underpin them to understand what good looks like but at a minimum you should be able to see a structure and discipline in the team’s ways of working and how and when value is released to the customer.
In terms of activities (ceremonies) you should see:
- Evidence of work being structured in sprints or timeboxes
- Evidence of backlog grooming/ refinement
- Evidence of sprint planning
- Daily stand-ups/ Daily scrums
- Sprint reviews
- Retrospectives and evidence of ongoing learning and improvement
- Evidence of collaboration with the customer
In terms of artefacts/ deliverables you should see:
- A prioritised backlog
- Well written user stories
- Evidence of planning and progress tracking such as Kanban boards, Information radiators or Burn charts
2) Ensure Agile is right for this project
Agile methods can improve collaboration, speed of delivery, quality of delivery and ability to deal with change for most types of projects – but not all! In order to say with confidence that the Agile project will lead to desired outcomes, it is important to be sure that it is suitable for Agile delivery.
|Suitable for Agile delivery
||Unsuitable for Agile delivery
|It is impossible to define scope upfront, and/or there is a lot of flexibility and uncertainty around the scope
||The scope can be defined upfront and it is vital the entire scope is delivered exactly as defined
|We have a dedicated team that will work together throughout the project
||Team members will come and go or are only available for short periods of time
|The customer/user is dedicated and available for continuous testing and feedback
||The customer/user is not available to test or give feedback
|The organisation understands the implications of using Agile delivery methods and is willing to tweak standard processes such as assurance, resource allocation, benefits realisation and potentially accounting/billing
||The organisation is not willing to tweak any processes and requires rigid documentation and adherence to standard processes throughout the project.
This assurance can be done with questionnaires or coaching (for example from the PMO) at project initiation, and this can be verified as part of independent assurance activities once the project is in motion.
3) Find a compromise
There must be a reason why Agile delivery was chosen for the project (if a reason cannot be defined perhaps that is a signal that it be a Linear delivery…) so don’t make the mistake of forcing the project to comply with your assurance mechanisms – by doing that you might restrict the project and reduce the value gain from Agile delivery.
Treat the challenge posed by the Agile project as an opportunity to review (and potentially streamline) your assurance practices. Is everything you do (and everything you ask projects to do) really adding value? At all times aim to ask for the MVB – Minimum Viable Bureaucracy. Perhaps you can prioritise what is most important and ask the Agile project team to produce that particular deliverable? And if you are able to prioritise some aspects as important and others as not important why not carry that over to all projects?!
There has to be an element of give and take between your assurance needs and the project with Agile delivery. At the heart of the Agile method is the drive to deliver Value (at all times focus on the work and features that add value, and cut everything else out). So if there is an aspect of your assurance practice that is vital for the organisation it is in the interest of the Agile project to align with it. Do not forget – the last sentence in the Agile Manifesto (yep, it may be worth scrolling back up and reading it again) is
“While there is value in the items on the right, we value the items on the left more”.
That means the Agile project should value and focus more on collaboration and working software (product) than contracts and documentation, but it does not mean they do use or produce documentation at all! It should therefore be possible to find a compromise that suits both the assurance needs and the needs for flexibility and agility in the project with Agile delivery.
What is confidence? The Oxford Dictionary defines it as “the feeling or belief that one can have faith in or rely on someone or something”.
Considering that Assurance is about giving confidence that a project is proceeding as expected, changing our mindset, and identifying the appropriate approaches will help us to gain that confidence; maybe without the ‘traditional’ documents, we might have expected to see before Agile became one of the approaches to delivering our projects.
Psychologically, confidence = safety.
Providing we utilise the pragmatic tools and visual aids that Agile provides, of course, it is perfectly possible to make out Sponsors and Customers feel safe in the hands of our delivery.
However, a new perspective might be that considering Agile projects require consistent and regular contact with the Customer (and any internal Sponsors), confidence in a safe pair of hands should be implied and felt by the very nature of the work our teams are doing.
The Wellingtone APM Accredited Agile for PPM Professionals is a course designed for Practitioners by Practitioners who are not working in a fully Agile environment; helping to bring Agile skills and practices to a realistic environment where hybrid is the way forward.
Our #HumanFirst approach means that our training is practical, fun, and supported by our DrPMO Clinic; free access to a 30-minute appointment with one of our Specialists who can help you find a way through the Agile conversation.