How do you structure a contract for the development of software in a world that has learned valuable lessons from waterfall? It’s a challenge. From the perspective of a customer, the following guarantees are desired:
• A fixed set of functionality
• A fixed cost
• A fixed date
• A fixed (high) quality bar
Unfortunately, fixing all of those levers is not realistic, and a primary reason waterfall software development has failed. What makes us think it can succeed with contract development? In short, risk is high (e.g. no working software until late in the process) and probability of success is low.
What are the alternatives? First, some key principles of execution:
• Transparency, including near-real-time visibility into project progress (vs. post-project legal action)
• Commitment to deliver in small batches, which are easier to understand and deliver (vs. lengthy duration until working software is produced)
• Frequent collaboration to ensure the direction is correct (vs. going dark and delivering months later)
• High quality is non-negotiable (vs. taking shortcuts and building up technical debt)
Let’s cover some models for contract-based software development (e.g. outsourcing, or augmented development team) along with their suitability to Agile teams, where traditionally time and cost are typically fixed, but functionality flexes.
Variable price, fixed scope. In this model, the customer knows what they want, and are willing to pay a variable fee to get it, understanding that software development is an imperfect craft that cannot be completely predicted. This model is basic time and materials. The risk is the project may balloon out of control and cost much more than originally budgeted. Agile fit = medium, since a ranked backlog can still drive development.
Fixed price, variable scope. A product backlog (functionality) is agreed-upon that has work in sequential order. The team works through the backlog until the budget is met, at which point additional cost can be agreed-upon for increased functionality. The risk is the initial budget may not produce a workable product (I.e. incomplete). Agile fit = high, since Agile typically flexes with functionality.
Fixed price, fixed scope. Here, the date is left is to flex if necessary, but two key levers are fixed. Development can be iterative, with smaller batches of committed scope. The risk is the software may be delivered much later than needed and it may take more iterations than expected for a usable product. Plus, it is risky for the development team and may severely hit margins. Agile fit = low, since date is the primary flex point.
Start time and materials, fixed price later. A suitable model when there are many unknowns at the start of the project. Frequent collaboration is used to clarify scope with enough research to provide higher confidence estimates. Then, a more predictable cost can be inserted into the contract. The risk is that the scoping phase may use much of the budget. The fixed price portion may have the same risks as discussed previously, but risk is lower. Agile fit = medium, since the planning portion is Agile but the delivery is more waterfall (but with more certainty).
Capped costs with incentives. A lower bound cost and upper bound cost for the work is determined with incentives for delivery, such as date targets or functionality targets. If the team meets all of the incentives, the upper bound cost is paid. The risk is that the bounded costs may be difficult to determine, and the lower bound cost may not be agreeable to the development team. Agile fit = medium/high, since there is flexibility in how the team works.
Combination of models. This is a combined model of time and materials to start (a “sprint 0” to plan and determine longer term roadmap and backlog) with iterative development (e.g. 10 week increments), commitments for the first 6 weeks of development, and stretch incentives at the end of the increment. The risk is that the contract becomes more complex and a new one is typically needed every increment. Agile fit = high, since planning is Agile and the incremental model also fits with Agile methodologies.
The right model is dependent on a number of factors, such as how well-known the scope is, complexity of the software, the overall budget, and delivery timeframes. The principles to ensure success with outsourcing are referenced here. An important condition, however, is an Agile mindset by both development team and customer. Agile development teams typically have more success with delivering high quality commitments on-time, so an agile software development contract that does not force waterfall thinking, is generally preferred.
Crosslake Labs typically leverages Agile principles and methodologies to best meet customers’ needs. If you are in need of a high-powered development team that produces high quality, delivers in small batches for frequent and early feedback, collaborates effectively, and is fully transparent with progress, please do not hesitate to contact us.