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.
Step Three: Define Roles and Responsibilities
Regardless of the type of project management method used, it’s important to establish clear definitions of roles and responsibilities in a contractual agreement between an organization and an outside party, such as a consulting company. This is typically the part of the contract that describes which party will be doing what. When an organization is using an agile approach like Scrum, it is especially important to define which party will provide the product owner. This individual has a great deal of power in Scrum because he is responsible for defining the overall direction of the product as well as accepting (or rejecting) individual requirements as done.
Being a product owner is time-consuming, and consulting organizations should think about this carefully before they suggest their clients take the product owner role. The reality is that it is almost always more work for a consulting company to have a client-side product owner, rather than having responsibility for that role. Clients are often still learning Scrum, and they may be unsure how to write good product backlog items and acceptance criteria. Sparse and poorly written product backlogs can result from a client unversed in using Scrum, and who has other demands to attend to. Despite the fact that this is the product owner’s responsibility, consultants are often blamed and used as scapegoats.
That being said, individuals from the client side can make good product owners. They can be excellent at controlling costs, as product owners are also responsible for the return on investment of the project. Unlike a representative from the consulting organization, these individuals should have no trouble telling their stakeholders that a particular requirement is not cost effective when added to the project.
If you choose to have a client-side product owner, be sure to schedule regular product backlog grooming sessions to ensure the backlog is properly maintained. Unlike a sprint planning meeting, grooming sessions do not involve making commitments for a sprint. Rather, the purpose of these meetings is to improve the product backlog. Schedule one of these meetings every sprint so that it happens at least a few days before the sprint planning meeting. Doing so will help a client product owner get his backlog in working order and will help to build the collaborative relationship between the Scrum team, product owner, and ScrumMaster. It will also ensure the product backlog reflects the work being done in the project, thereby improving the audit trail.
Step Four: Use a Sprint to Build a Statement of Work
For consulting agencies, the statement of work (SOW) is a high-level description of the work a project entails. It usually contains some reference to the procedures that will be followed, including handoff points, roles and responsibilities, and estimates. Many audit processes require a signed SOW before work can begin or be billed for a project. When using an agile approach like Scrum, it helps to use the first sprint of the project to create this SOW. Do not mistake this for a “requirements” sprint—it is much more than that. During a SOW sprint, the two parties can define the high-level business problem or opportunity, assemble a team, write the beginnings of a product backlog, define roles and responsibilities, and create high-level estimates. The SOW itself is the output (or sprint goal).
When using an agile approach, using an SOW sprint is one of the biggest cost savers for clients. Methods like Scrum were created because it is hard to dream up all the requirements before ever starting a project. For this reason, the requirements phase of a project tends to drag on for weeks and sometimes months as clients try to think up every little thing they might possibly want included. In reality, many of these features are not essential to the project, and they raise the cost without giving commensurate value. By timeboxing this effort to a single sprint and letting the client know that additional requirements can be added later, everyone can focus on understanding the project goal. Client organizations have seen their project costs drop by as much as 30 percent by using this method.
Having a successful SOW sprint requires the full involvement of everyone during that time period. Because time is limited to a single sprint of perhaps two weeks, this should be considered a full-time effort for the identified Scrum team, the ScrumMaster, and the product owner. Stakeholders should be informed ahead of time of the schedule boundaries and when they will be needed. Finally, be sure to allot time for whoever will write the SOW, which oftentimes can be the ScrumMaster. Just be sure to allow ample time at the end of the sprint for this task. Ideally, the sprint review at the end of this effort will result in the product owner’s or other required parties’ signing the SOW so that actual development can begin the next day.
Step Five: Let the Right Path Emerge
Processes, like everything else, have a lifecycle. As business changes and new needs arise, commonly followed procedures can fall by the wayside while new ones are adopted. Ten years ago, Sarbanes-Oxley did not exist, and now it does. One thing is for certain: Change is constant. So, rather than getting stuck within the boundaries of current ineffective processes, it is helpful to focus instead on helping those processes evolve in a way that better serves the business.
This is truly a process of evolution. Don’t try to reinvent every project management process in your company before you start your agile transformation. Begin your first agile project using as many of the same artifacts and procedures you did in the old waterfall approach. Let conflicts arise—as they surely will—and gradually make changes. Most organizations that have audit requirements have something often called an “exception form.” The purpose of this form is to describe a variance from the defined project management procedure. Early in an agile transformation, make liberal use of this form to describe changes you are making to the process supporting an agile approach. When you find, for example, you have written five exception forms for five projects to explain that the BRD is now a living document and will be signed at the end of the project, it is probably time to change the root process itself. Working with an agile coach or someone who has experience writing agile contracts will help guide you when you’re new to the process.
Beyond simply meeting audit requirements, moving to an agile approach also requires taking a hard look at what you are trying to accomplish with your contracts. The Agile Manifesto is a document created by those many consider to be the founders of the agile movement. In it they describe “agile values,” in which one of the core tenets is valuing customer collaboration over contract negotiation. Truly, agreements can be mutually beneficial, and the best ones usually are. Too often, the contract creation process is viewed as a chess game with each side trying to exploit the other’s weaknesses to gain advantage. But the truth is both parties have a vested interest in the other’s success. It is to a consulting organization’s benefit to leave a client delighted with its new product and eager to do business again. It is also to the client’s advantage to pay the consultant a fair price while building a positive working relationship so that the consultant can maintain his livelihood and be available to work in the future. Both of these goals can be met while still creating contracts that support the audit processes. The first step to creating effective agile contracts is seeing the working relationship between all parties involved in the contract process for what it is—a partnership.
About the Author
Having served as a product owner, ScrumMaster and team member, Angela Druckman has seen first hand how agile practices and Scrum in particular can lead organizations to project success. As one of CollabNet’s Certified Scrum Trainers and a member of its ScrumCORE team, she helps organizations harness the Scrum framework’s potential, conducting dozens of public training courses each year as well as providing on-site, private coaching.
