When organizations use agile practices they may find themselves conflicting with the existing project management processes. When an agile approach is used for projects that touch outside entities, like consultants or partners, the issue grows even more complex. Organizations with heavy regulatory requirements face a similar challenge. Those just learning the agile frameworks may often ask, “How can we use Scrum and pass an audit?”
The fact is, it is no more difficult for an agile project to pass an audit than a traditionally managed one. Although the word “audit” may strike fear in people’s hearts, it is important to remember what the goal of this activity is, in the corporate sense. Every organization has both implicitly and explicitly defined processes that describe how it operates. These processes are defined by either the organization itself or outside entities, like a regulatory commission or even the federal government. Regardless of these practices’ origins, an audit ensures that you are following the processes you say you are following.
Processes can be defined for an agile project using, for example, Scrum as its project management framework just as they can any other kind of approach. The challenge is not the nature of being an agile project but, rather, the organization’s transition period. They are, in essence, moving from one set of rules to another. Because of this, there will be a period of time when there are likely several different “project rule sets” being followed. In order to create an effective agile contract, you must involve the right people at the right time and remember the following key steps as explained in this article.
Step One: Involve Your Audit Group Early
Reaching out early to your organization’s audit process managers is one thing you can do to transition to an agile approach. There is usually a group or, at the very least, an individual that is responsible for communicating with and assisting the audit team when they audit onsite. You should explain your objectives to the group or individual, and tell them that you are going to be using a new project management framework. For example, you can describe the process of using the product backlog to maintain requirements. Together, you can decide how to document things like the product owner approval of backlog items. A signed or initialed copy of the sprint backlog denoting the accepted requirements deemed “done” by the product owner will usually suffice. Instead of defining all the new processes up front, you should be defining the new processes that will support the agile approach, since you will be working together over time on more agile projects. Many teams working on agile contracts find it valuable to use an agile tool, because it helps collect and store electronic data that can be used to support the audit trail requirement.
Step Two: Use “Living Documents”
An early transition to agile in a project can be thrown off by the need for completed and approved documents prior to beginning work, as exemplified by a business requirements document (BRD). For traditional, waterfall organizations, this document is developed in partnership between the client and consultant organization. Generally, it must be approved by the management of both parties before beginning any software development work. This leaves the project team in a quandary if it is trying to use an agile approach, since the team members know the product backlog and BRD will change, but they are unable to work until all changes are identified. These two coexisting but seemingly conflicting requirements leave the project team unsure how, if at all, to proceed.
The easiest way to deal with this dilemma early in an agile transition is to create artifacts like BRDs and make them “living documents,” meaning they will be updated each sprint. The product owner can initial each new section added in a sprint, and the entire document can be signed at the end. Both the client and consulting organizations will benefit from this arrangement. The clients can now make modifications to the backlog each sprint, giving them more flexibility. Additionally, the consulting company avoids the negative associations with “client change requests,” which are additions to an original contract that usually mean one thing to their customer: The project is going to cost more than originally planned. Eventually, both parties may decide the BRD should be revised or eliminated altogether, but until then and while early in an agile transition, the approach described here can be effective.