As organizations adopt an Agile process, they may find that their standard methods for negotiating corporate contracts...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
do not mesh with Agile. At Agile 2011, Angela Druckman co-presented with Jimi Fosdick about the practical considerations that stakeholders must take into account when developing agreements in an Agile environment. SearchSoftwareQuality.com conducted the following interview with Druckman to get the scoop on her presentation.
SSQ: What kind of "contracts" are we talking about? SLAs? Contracts when working with vendors? Are these legal documents?
Druckman: For this presentation we are referring to a written, legal agreement between an organization and outside entity, such as a consulting firm, contracting agency or partner. What we’ve found is that when two parties come together to accomplish work, such as a software development project, in an Agile way. The way they define and write these agreements must change to support the new process.
SSQ: When you speak of "Agile" contracts, are you talking about Agile development practices (such as allowing for changes), or are you talking about using Agile practices (such as collaboration) to negotiate your contract?
Druckman: Agile practices will touch and affect almost every facet of these agreements, both the negotiation process and the wording of the contract itself. But certainly they must explicitly define how the two parties will work together in regards to change management, roles and responsibilities, artifacts and the approval process for calling increments of work “done.”
SSQ: Who do you think should be involved in writing, reviewing and approving these contracts?
Druckman: Building these contracts should be a collaborative process between both parties. A variety of stakeholders should be involved. This list may include end users, management, downstream groups and third-party entities like partners. The actual team members that will build the product will also be heavily involved. If the plan is to use an Agile framework like Scrum to structure the project, the Product Owner and ScrumMaster will also be part of this process. Finally, the person who actually writes the contract-- whether it be the ScrumMaster, Product Owner or someone else entirely -- will also be involved.
SSQ: The presentation abstract says that often standard templates for corporate contracts do not support the Agile process. Can you give us some examples?
Druckman: Many standard contract templates describe a gated, waterfall style of product development. For example, a contract of this type may indicate the need to have a completed, signed Business Requirements Document (BRD) before actual development of the product can begin. But with Agile methods like Scrum the requirements that make up the BRD, which will ultimately make up the Product Backlog itself, are gathered not only at the beginning,but rather continuously throughout the entire project. So any contract language that describes this gated approach must now be revised to support a more iterative approach.
Likewise, most contracts provide a change management section, which describes the process to make revisions to the requirements list. Since it is a given that the requirements will develop in an iterative manner, with new additions and subtractions happening potentially every sprint, the contract language must reflect that flexibility.
SSQ: You talk about using contracts to define roles and responsibilities within an Agile framework. Are roles and responsibilities defined for everyone, or only for those who aren't internal employees?
Druckman: Minimally, the contract should describe the specifics of three roles. First, it is important to denote who will be prioritizing and approving work. In Scrum, this is the responsibility of the Product Owner. The contract should explicitly state which party will own this role. Second, the agreement should also describe the process by which the team will make commitments and state clearly that the team itself has final say on how many requirements they deliver in each iteration. Finally, the contract should state which party will provide the Scrum Master role. Taking these steps will help prevent confusion and misunderstandings as work progresses.
SSQ: Will the Agile contract negotiation you talk about apply to any contract negotiation? Will templates be available?
Druckman: We will offer specific language that can be added to an organization’s standard contract template to define responsibilities and expectations for an Agile way of approaching work. However, many enterprises find their contract templates need major surgery, with new parts being added while others are removed, to fully support an Agile project management practice such as Scrum. To accomplish wide scale change, we recommend organizations seek the help of an Agile coach. An experienced coach can help organizations revise not just their contracts but other project artifacts as well, such as the Statement of Work, Business Requirement Document and design documents. In addition, an Agile coach can work closely with a company’s Legal and Audit compliance groups to ensure their needs are met throughout this period of change.
SSQ: What do you think the biggest takeaway will be for those attending this session?
Druckman: Clients and consultants must realize that choosing to work together in an Agile way may produce a fundamental change in their relationship. Contracts become more about mutual agreements and benefits, and less about trying to gain advantage. When each party can approach the negotiating process with a spirit of collaboration and a commitment to eliminate ineffective processes, they will find this way of working together can transform the way they do business.