The iterative and incremental nature of agile makes an agile approach seemingly less compatible with project governance or oversight. Traditional, sequential approaches to project management are a more natural fit with management’s desire for oversight on projects.
The purpose of project oversight, commonly called governance, is to make sure a project does not go astray.
Effective project governance can, for example, identify a project that will exceed its budget, leading to conversations about whether the project should be canceled. Governance can also identify a product that is drifting too far from its original goals, a project that is deviating from an architectural standard, or any number of similar high-level considerations important to the organization.
Project governance is not a new concept, but it finds its most natural home in any stage-gate process as shown in the figure below.
The central idea is that after each stage of a development process, the project is forced through a gate. Each gate acts as a formal review checkpoint on the project; the project might be approved to move forward, sent back for rework in the previous stage, or canceled.
Can Governance Work on Agile Projects?
A software team might encounter gates or governance checkpoints at a variety of times:
- an early review of their plans for scope, budget, and schedule
- a review of architectural and design decisions
- a review that the application is ready for system or customer acceptance testing
- a review that the product can be handed off to a support organization; and so on.
These checkpoints often wreak havoc on an agile team as this type of governance model is not compatible with work done in an iterative manner. For example, a Scrum team that allows the design of the system to emerge will have a difficult time clearing an early checkpoint that considers the appropriateness and correctness of the system’s architecture.
Reconciling Agile and Governance
The first step in reconciling the need for project governance and teams using Scrum is to realize that project governance and project management are not the same thing.
It is OK to separate project governance from project management.
But in separating them we would like to achieve the ability to have high-level checkpoints to provide the necessary oversight, while still allowing the team the freedom of managing itself and the project in an agile manner.
Governance Is Not Inherently Evil
Second, it is important to understand that governance is not inherently evil. Suppose that you are suddenly promoted to president or CEO of your company.
As the new boss, you are going to want some visibility into the company’s major projects. Maybe you establish a rule that you personally need to approve the start of any project expected to cost over a certain amount.
And, while you plan to attend as many sprint reviews as you can, you want any project that lasts over three months to give you a two-page summary of key information every three months.
This would be a lightweight governance model and a reasonable one to put in place. So it is not the existence of governance that is objectionable; it is when governance starts to affect how we run the projects that we object.
Running Agile Projects with Non-Agile Governance
Because few organizations will go so far initially as to completely revamp their current approaches to governance, agile teams will need ways to work with their organization’s non-agile governance. Taking the following actions should help.
Negotiate and Set Expectations Up Front
Without question, the first agile project to go through the governance process in your company will have challenges.
There will almost certainly be some information or work products that the first agile team will not be able to provide. For example, team members will not be able to provide a thorough design before getting permission to start coding, because design and coding will be done concurrently.
The only solution to this is for the team to negotiate with the necessary governance groups in advance. The more support a team has for this and the higher up in the organization that this support reaches, the better.
The team does not need to solicit a permanent change in governance policies. The change can be pitched as a one-time experiment.
Fit Your Reporting to Current Expectations
The project review boards or oversight committees that provide project governance have existing expectations for what information each project is to provide at each checkpoint.
Don’t fight these expectations.
If they expect a Gantt chart, provide a Gantt chart. When you can, however, try to slowly shift expectations by providing additional, more agile-friendly information.
If burndown charts are suitable to show, do so. Or perhaps you want to include a report showing how frequently the team deployed day by day during an iteration.
Invite Governance Auditors Into Your Process
Scrum teams can supplement less-detailed formal governance checkpoints by inviting governance committee members to participate in the regular Scrum meetings. One client told me how her team interacted with an architectural review committee:
Agile teams invited people from the architectural review committee to their sprint reviews early on. They then still had one formal checkpoint, but by then most major questions had been resolved. This was a lot less painful, and trust and collaboration were built earlier.
I like to extend the well-known technique of management by walking around into management by standing around. Encourage managers and executives involved in the governance of a project to attend the daily scrums, where they can stand and listen to what is occurring on the project.
The same shift from documents to discussions that is created by working with user stories needs to occur with project reporting. Encourage people to visit the team or join its meetings to see for themselves what is being built.
Reference a Success
Nothing convinces like success. Do whatever you can to get a first project or two through lightened or reduced governance checkpoints. Then point to the success of those projects as evidence that future projects should also be allowed through.
Once you get a few agile teams showing favorable results, you build trust. And you can then work on the larger overall governance process.
Agility and Governance Are Not Fundamentally Opposed
The concepts of agility and project governance are not fundamentally opposed. Each is an attempt to improve the finished product. Agile strives to do this through close collaboration and the short inspect-and-adapt cycles of the time-boxed sprints.
Project governance strives to do it by what we might call inspect-and-approve (or reject) checkpoints in which the product or project is compared to a set of desirable attributes.
However, while pursuing similar goals, agile and project governance take entirely different routes to achieving those goals. It is in these different routes where problems will arise in mixing the two.
Fortunately, a few compromises on each side, combined with the advice here, can lead to a successful combination of agility and oversight.
What’s Your Experience Been?
What has your experience been in working as an agile team with governance oversight requirements? Please share your thoughts in the comments below.
