Is it possible to embed assurance in an agile way so that a project can manage up without stifling its innovation or delivery?
While they may not seem like natural bedfellows, agility and assurance are in fact critical for business and essential for successful project outcomes.
Agile is perceived to be the freeform, constantly adapting methodology that increases speed or production, focused on delivering what is needed by the customer. Assurance, on the other hand, is very often perceived as red tape, inflexible, and rigid.
If they look like opposing forces in the project delivery sphere, why are they in fact so essential to each other and is it possible to embed assurance into Agile so that it does become an agile process?
The answer: Yes.
The Myths of Agile
There are certain myths that seem to influence the decision making process about adopting Agile into business project delivery and the Wall Street Journal CIO Journal lists nine of them.
In the context of Agile and assurance, two of the WSJ myths stand out. The first is that Agile means no planning. For those of us who have the war wounds of Agile delivery, we know how this realistically translates. As the WSJ says:
One of the challenges of an incremental planning approach is the need to properly manage technical debt (cost of code quality) and willingness to revisit prior decisions as the project progresses and more information becomes available. To counter this challenge, it is important to capture both user requirements and system requirements and effectively prioritize each as part of the backlog grooming process.
In our experience, building the assurance component into an Agile project can ensure this happens seamlessly.
The second myth we often see is Myth 6, which is that Agile processes are less disciplined or structured than those of waterfall:
Agile requires more discipline because a project’s scope is actively managed from planning to launch, with stakeholders reviewing progress at set intervals and providing feedback every step of the way. The flexibility of this process includes built-in safeguards (e.g., suppressing the addition of new requirements or user stories in the middle of a sprint) to prevent never-ending release cycles.
This is a clear acknowledgement that the process of ‘reviewing’ a foundational assurance activity, is very much part of the agile framework.
But if Agile has its myths, so too does Assurance.
The Myths of Assurance
Assurance has its own set of myths that can render it little more than an exercise in red tape, yet the reality couldn’t be further from the truth. The top four we see are:
Myth 1 – It’s a box ticking exercise purely for compliance
Reality – Assurance is a critical step in the quality assurance process. Done correctly it sets the project up for success.
Myth 2 – Its about allocating blame
Reality – Assurance shines a light on the issues and challenges of the project and provides independent and objective insights on how to fix the issues. Usually issues are systemic, leadership and governance-related. Very rarely is it down to one person and it should not be used as input for a witch hunt.
Myth 3 – Assurance is only for Government and large organisations
Reality – Assurance done properly should be designed to be fit-for-purpose and tailored to add value independent of size of project and organisation. The cost of failure is much higher than the cost of early corrective action.
Myth 4 – Assurance and Agile don’t mix.
Reality – Assurance is adaptable and can take many forms. The review of each iteration in an agile process is a living form of assurance. The critical thing is to ensure the right questions are asked and the corrective action taken. Assurance, in its many guises, is perfect for this.
Whichever way you look at it, it must be fit-for-purpose
We are strong proponents of building in robust and fit-for-purpose assurance into Agile teams; it’s critical for project success. The review process in each iteration and cycle lends itself perfectly to a structured assurance process – it does not need to be standalone or require the ongoing engagement of an assurance specialist once it has been set up.
A specialist is valuable when a team is building the assurance process, because they offer valuable check point and insights, however once implemented, a specialist can step away and let the Agile team manage it moving forward. Regular reviews can ensure that the process is adding the value it was intended to achieve.
Agile & Assurance: Designed to Work Together
By their nature, Agile and assurance go together like cheese and wine: If you chose the right palette, you’ll know how well they fit pretty quickly.
When designed correctly, the discipline and structured nature of Agile pairs incredibly well with assurance’s integrated practices to help identify risks and issues in real time. Together, they ensure that the right project outcomes are being sought and achieved. Far from slowing the Agile process down assurance becomes just another process, albeit an important and necessary one, that will ensure Agile delivers successful and quality project outcomes.
We believe that quality thought leadership is worth sharing and encourage you to share with your colleagues. If you’re interested in republishing our content, here’s what’s okay and what’s not okay.
To speak to our team about how we can help your business deliver better projects, please contact us.