There is a good chance that, despite your organization’s efforts to embrace an agile-based framework, it will still have to comply with some sort of traditional governance. It is one of the areas where agile projects cannot escape the workings of the greater organization, and there are methods to both satisfy governance needs without sacrificing governance principles.
A presentation by Andrew Craddock from nlighten and Chris Davies from AXA Personal Lines Insurance illustrated the key challenges with governance of agile projects. These were:
- Governance requires all kinds of documentation that agile methodologies might deem redundant or have no intrinsic value
- Governance and compliance is normally satisfied by upfront analysis and agreement on outputs, which is in conflict with agile principles
However, there can be a middle-ground, where agile project management principles are preserved, and governance and compliance requirements met.
Understanding Governance and Compliance Requirements
Before embarking on an agile project management methodology, it is important to understand what your organization requires from a governance and compliance perspective. What’s even more important is to engage with stakeholders and get to the core of the requirements.
For example, your organization may already have a structured approach to governance with defined documentation and procedures. The problem is you cannot just adjust the documents or the process – you need to get to the heart of the organizational needs and potentially alter the governance approach entirely towards your agile projects.
Those who manage governance and compliance are not trying to add a bureaucratic and unnecessary overhead to your project, but rather ensure that there is a safe and controlled environment for your project to operate in. They are normally concerned with only 6 major areas:
- Does the project align with current business needs?
- Does the project offer value to the business?
- Is the output clearly defined in terms of timing, cost and business requirements?
- Can the project be monitored and measured in a transparent manner?
- Are any risks clearly defined and managed?
- Is the project compliant with any regulatory requirements?
Simply looking at these questions, any agile project manager can derive approaches to satisfy these needs without compromising on agile principles. It might require your organization to be open to modifying some of their traditional approaches to project management governance in order to accommodate your agile methodology.
Business Needs Alignment
Looking at the first item, the business needs to be able to assess that the agile project will align with the strategic objectives of your organization. Considering that any agile project begins with a vision and project roadmap, it should be evident that your project had to be considerate of the business strategic needs as an input to both the vision and product roadmap.
While agile methodologies do not stress high volumes of documentation, they do not advocate no documentation. Thus, there should be documentation that is produced at the start of any agile project where the business objectives and strategic alignment are noted and considered in the project.
In fact, no matter the methodology, any successful project requires quantifiable objectives from business which can be measured at the end of the project to ascertain the project’s success. If you are an e-commerce site, the business objective could be to increase revenue by 20%. Therefore, your agile projects need to measure against this objective, and it would be noted in your project documentation that this objective is not only considered, but how this agile project will contribute or meet that objective.
Defining business value
The second question that auditors might need from your agile project is how the project will add business value. Similar to the first question, all of this should be addressed in both your project vision and roadmap documentation. However, what might be slightly different in this case is that you might have to provide additional steps that extend beyond the planning phase to constantly report back on iterative value after each release.
A great example is from the British National Audio Office report on agile governance in 2012, where one of their case examples was British Airways. The approach at British Airways is to fund their agile project teams for 6 months, with a key constraint being the delivery date, as delays reduce the value of the project. Thus, it forces the agile project steering committees to constantly evaluate which projects will deliver the most business value given the time constraint, and the business constantly puts pressure on the teams to deliver value.
An important principle here is that the stakeholders are both actively engaged with the project teams, and have provided them guidance in creating tools like a suitability matrix which is used to evaluate potential projects.
Remember that the business strategic stakeholders are the ultimate judge of business value, so it is critical that they are involved with the agile project teams to create and define the measurement for project value.
Clear outputs of the project
Agile methodologies, more than many other approaches, are reliant on working off a set of clearly defined outputs. What may confuse some business stakeholders is that, at face-value, switching from complex project designs to agile product stories may seem like the requirements are less concrete or well-defined. This is normally just a misconception driven by poor adherence to agile disciplines, as a well-run agile project requires that user stories are supported by clearly defined tasks and outputs as part of the sprint planning.
In fact, organizations, especially governance and compliance divisions, may warm quickly to Agile-based methodologies when they see that sprint outputs are clearly defined and releases have specific dates, giving a clear roadmap and view of what the project aims to achieve.
If anything, while the traditional documentation that waterfall frameworks are bypassed, Agile-based methodologies spend the time on documenting actual outputs and expectations. Because of the iterative approach, it is easy to identify value-based outputs far quicker with less long-term resource commitment versus traditional waterfall projects.
It might, therefore, be a few small tweaks of your existing governance and compliance requirements to adapt to the very clear and concise outputs of your agile project.
Where Agile-based methodologies really excel is the ability to offer governance and compliance stakeholders transparent and ‘real-time’ monitoring of a project output. The daily progress sessions (i.e. scrums or stand-ups) are sources for regular updates that can be shared easily and is one of the hallmarks of agile that these daily updates are available.
An agile project manager can provide, without much additional work or overhead:
- Access to notes or minutes from the daily progress meetings, which should be recorded but be succinct comments on the task progress of team members, and more importantly, any obstacles or deviations from the planning
- Access to the burn down chart, which gives a quick, graphical overview of the progress of the sprint at any time
- Many agile project management software solutions allow non-project stakeholders read-only access to the project dashboard, and the ability to drill down to any detail if desired
Thus, any Agile-based methodology is perfectly positioned to give project transparency to oversight entities, as long as there is adherence to the project disciplines.
Managing project risks
Project risk management isn’t something that should be unique or difficult with any project methodology, but there are some additional aspects that should be considered when dealing with your stakeholders.
As with any design that is not fully completed at the time the first build task is started, there always remains the risk that some outputs may not be fully understood until reached. Some organizational stakeholders may have difficulty in adapting to this risk, but the counter-argument (and strength of agile) is the adaptive nature mitigates the risk, and is less of a risk than that of a large pre-determined design that may be out-of-date by the time it initiates its build phase.
An important job as an agile project manager is to continually emphasize that Agile-based methodologies are not unstructured or chaotic, but more disciplined and structured than what the organization is used to.
Agile competency risks
A common theme amongst dealing with governance and compliance requirements is that the disciplines required by the agile project management team will satisfy and create the outputs necessary for compliance.
However, not having sufficient agile competencies or training within your project team is a risk in of itself, and, as noted in other articles, the leading cause of agile projects to fail.
Having the organization sign off on an agreed project management methodology is another aspect to agile projects failing. The only thing iterative should be the work output and not a haphazard, unstructured methodology.
Complying with regulation
One of the final concerns of any audit committee will be around any regulatory requirements that may be required. As long as these requirements are understood at the start of the project, an Agile-based methodology should be no less compliant. Agile projects can still output the required product documentation and incorporate software, security or data management standards as part of the project's outputs.
In fact, agile projects can often comply better with regulatory requirements by breaking them down into smaller, easier-to-quantify tasks that are produced. One thing to note is not to fall into the trap of only addressing regulatory requirements in later iterations or rollouts, as they can add substantial rework versus addressing it early-on as part of the ongoing development.
These simple pointers illustrate that agile projects can deliver the output the framework promises, but still be compliant with your corporate governance.