Updated: Mar 25
Did you know that almost half of companies now exclusively use Agile for application development? In fact, almost everyone is using Agile application development methods and practices in some way in their enterprises. While the benefits of Agile over traditional Waterfall development methods are clear, our clients often struggle with Agile projects that utilize third party vendors.
Traditional Waterfall development methods often require an extensive planning phase, multiple sequential steps and lengthy documentation before software can be implemented and utilized. Functionality is usually delivered at the end of the project and if a vendor is engaged, the project relationship, contract and pricing can more easily be structured at arms-length.
Everything is different in the Agile world, as it calls for a continuous, flexible and iterative process that requires team collaboration between the customer and the vendor, and features smaller, frequent deliverables through Sprints. Customer involvement and oversight is often much greater and the Statement of Work (SOW), which governs the project and the relationship, is much more complex. We explore several of the issues companies must address below.
Pricing Agile Projects
Many companies like to use fixed pricing contract structures for their software development projects with third party vendors, as it can provide budget assurance and vendor financial accountability. With an Agile project, fixed pricing is inherently very difficult to use, as the nature of an Agile project calls for fluidity of business requirements, tasks and deliverables. Therefore, Agile project work efforts and pricing are very difficult to estimate given their inherent lack of upfront specifications, and vendors will protect themselves by quoting a higher fixed price in an effort to mitigate the risk of potential additional work not covered in the estimate.
A Time & Material (T&M) pricing structure is better suited for Agile Development projects than Fixed, as it allows for the continuous mini-project cycles and flexible requirements, which are the hallmarks of Agile. The challenge with the T&M model is that, while this option supports the changing nature of Agile projects and is easy to terminate, it still can be difficult to budget and control project fees with the supplier. Critics of the T&M model complain that the vendor has no deterrent to accumulating hours and is less motivated to get the project done quickly.
However, this doesn’t need to be an “either-or” decision for companies, as a hybrid approach may be the best option. The following are some successful alternatives to consider that encompass some of the objectives of both the Fixed and T&M Pricing models:
Fixed Fee per Iteration or Sprint
Incremental Delivery or Milestone Payments
T&M (Time and Materials) with Bonus Tied to Target Cost
T&M with Cap
T&M with Holdback
Agile Staffing Rates
Companies are sourcing external resources with Agile expertise at an increasing rate. The challenge is that there is no industry standard on Agile resource titles or descriptions. For example, you hear things like “Scrum Master” and “Agile Developer”, but these titles have no common description, certification requirement or experience levels across vendors. In addition, there is often a significant hourly rate differential with Agile resources, as these roles typically cost 20-30% more than Waterfall resources. These vendor resources are often the same individual as a Waterfall project, but you still pay a higher resource rate. This increased rate is often recovered by the supplier as profit and doesn’t reflect an increased cost for the resource. ClearEdge recommends that companies use similar discipline and governance over how they contract for Agile resources as they do with all other roles to ensure that they’re paying a rate commensurate with the skill.
Supplier Accountability on Agile Development Projects
How do you hold the vendor accountable for sustained and consistent output of software development? Here are some tips:
Establish metrics and governance before starting; define what “done” means.
Leverage the measured aspects of an Agile development effort that relate to “output” and estimation variances.
Use velocity as a metric to predict how much work an agile software development team can successfully complete within a sprint.
Remember that velocity does not measure QUALITY… defect density per story that improves over time is a common metric best practice.
Agile requires significant change in organizational governance, contractual documents, and pricing.
It is essential to establish mutual trust with the vendor in an Agile project. Convey that you all win and or lose together; awarding bonuses for hitting milestones for sprints is a good practice. Look for other ways to share the pain and gain with your vendor and build them into the contract.
Agile is iterative and requires frequent, regular engagement; it cannot be overstated that consistent and regular governance by client is critical to success.
Traditional sourcing methods cannot be used for Agile projects. This requires a major change in engagement and trust with suppliers.
Deliverables are not as definitive as in Waterfall projects; having clear acceptance language on sprints is needed.
Disputes are hard to resolve in the Agile world due to the shared responsibilities and fluid nature of the projects.
Before jumping in, thoroughly understand and gain internal alignment on your responsibilities with Agile.
Scrutinize inflated rates for Agile resources and the vendor’s Agile capabilities.
Knowledge of Agile methodologies is necessary to writing a good Agile SOW. In short, be prepared to throw out your old ways of engaging vendors on application development projects and understand how Agile deliverables are released. To learn more about achieving leverage and mitigating risk in an Agile engagement, go to our webinar recording on the subject, or contact your ClearEdge representative.
Chris Powers is a Managing Partner at ClearEdge with a focus on Professional Services.