Breaking through the Iron Triangle of Agile Contracting

By Jen Girdish, PM Boulevard - www.pmboulevard.com

Rachel Weston and Chris Spagnuolo teach a seminar on the pitfalls of Agile contracting at the Agile Development Practices. PM Boulevard caught up with the two to catch a sneak peak of their seminar and steal a few project-tested tools that can circumvent the restriction of fixed timelines, budgets, and scope challenge.

Q: The main focus of your seminar is about the limitations of contractual agreements on Agile. Why are practitioners finding Agile contracting to be such a difficult problem?
 
A: Many Agile practices are based on the experience that most software development projects share two constraints: schedule and budget. Considering these as "fixed," Agile asks the Product Owner and Delivery Team to focus their work each iteration on delivering the current highest value items regularly to the customer so that within the budget established and deadline for delivery, the customer can be sure to get the software that best serves their needs.
 
In a contracting scenario, the customer typically enters the relationship with an assumption that they will be able to fix budget, schedule and scope. This is an assumption that has been perpetuated through traditional contracting processes that promise big and frequently fail to deliver. This practice almost always results in a failure to meet one or more of those expectations, with projects running over deadline, requiring additional funding, or missing the mark on delivering the scope the customer needs. This makes contractual software projects as appropriately suited for Agile practices as other software projects, but client expectations as to what is promised at the contract establishment and signing stage must be modified to reflect what will ultimately be the reality of the delivery--that something will have to give.
 
Another difficult problem contractors are encountering is that client or customer organizations do not understand the benefits that Agile brings. They are skeptical that Agile will solve their problems. When you consider the high rate of software development failures, it is not unreasonable for clients to be skeptical. Even when clients understand Agile, they believe that the documentation and reporting that Agile provides is too lightweight, and then mistakenly believe that Agile project management presents a serious risk to their organization.

Q: What are some practitioners doing to stave off this problem?
 
A: Educating the client at the outset of the project as to why Agile will benefit them is a key practice that helps Agile contractors succeed. There are plenty of statistics out there to support the use of Agile practices and more and more customers are catching on to the idea that although the promise of budget, schedule and scope may sound good, the actual delivery of valuable software will be more beneficial in the long run.
 
Establishing a clear process for feedback and change management in the contract and with the client at the beginning of the relationship will also help immensely in making the relationship and thus the software delivery more successful. The process includes not only the Agile practices of prioritization and ranking of features, the iterative and incremental delivery of software, and the feedback loops that ensure continuous improvement, but also clear definition of the roles and responsibilities of both the members of the contractor's team and the client's team.
 
Additionally, setting up a clear and consistent definition of "done" for all features delivered to the client can help ensure that there are not misunderstandings that lead to missed deliverables and scope creep not based on value.
 
In addition to educating clients about the benefits that Agile practices can bring, Agile practitioners need to create an understanding with their clients that risk is shared equally by both the client organization and the contracted organization. This can be accomplished during the contract negotiation phase. By using language like the following in the contract, both the client and the contracted organization can equitably divide the risks inherent in software development and begin working toward a relationship of trust:
 
In our Agile approach, budget and time select the requirements that can be delivered. Our clients have the ultimate project control and may declare their satisfaction with the application as a whole at any time in the development process. Our clients can decide that although there is budget remaining, the delivery team has met their objectives and can call the project complete. On the flip side, although the total budget may be expended on a project, and all backlog items may not have been developed, our clients are guaranteed to have live, working functionality that is of the highest value to them due to the constant inspection and adaptation of the project backlog.
 
Q: What are a few tools that practitioners can use to deal with contracting in an Agile fashion?
 
A: There are a few tools we recommend to attendees to our Agile Contracting workshop:
  • Hit the waterfall problem upfront in proposals
  • Train sales and marketing in Agile
  • Cite Agile statistics
  • Define scope boundaries with product vision, product roadmaps, and release plans
  • Build Agile education for clients into your contracts
  • Clearly define client roles and responsibilities in your contract
  • Provide a clear definition of done in your contract

Q: Is there a type of project that's better suited to Agile than another?
 
A: We believe that any software development project that involves the possibility for learning through delivery that might change the direction the customer wants to go is suited to Agile. The feedback loops that the iterative and incremental delivery cycle provide offer a more flexible and less painful method for managing the inevitable learning and thus changing that occurs in the complex process of software development. For contracted relationships and projects, this becomes exponentially important because stiff contracting behaviors that inhibit change will only create pain for both the contractor and the client.

Copyright © 2009, Robbins-Gioia, LLC. All rights reserved. Used by permission.

Print Email