One of the first steps in negotiating an agile contract is to define the scope and outcomes of the project, rather than the detailed specifications and requirements. The scope and outcomes should be aligned with the customer's vision, goals, and needs, and expressed in terms of features, functions, benefits, and value. The outcomes should also be measurable and verifiable, using indicators such as customer satisfaction, user feedback, business metrics, or quality standards. By defining the scope and outcomes, you and your customer can establish a common understanding of what you are trying to achieve, and how you will evaluate the success of the project.
it is very important to understand the most valuable features (from a must implement availability/perspective) to target customer sales - which most people fail to understand. Often we see folks even after 1-2 years, unable to move the needle on sales due to lack of crispness and laser focus on identifying the key requirements generating customer revenues
Agile Coach | Product Coach | Scrum | Kanban | Design Thinking | Product & Program Management
The AI's recommendation above is gibberish and wrong. An Agile contract is needed when things like scope, features, benefits, and value are uncertain or unknown. An Agile contract specifies how they will be learned and uncertainly reduced. Clarity is gained through iteration. Risk is managed through iteration. So, iterations are often the fundamental building block of Agile contracts.
Another key element of an agile contract is to use an iterative and incremental approach to deliver the product or service. This means that you and your customer will agree on a series of short cycles, or iterations, where you will plan, design, develop, test, and deliver a working version of the product or service, with feedback and adjustments along the way. Each iteration should deliver a subset of the scope and outcomes, prioritized by value and risk. By using an iterative and incremental approach, you and your customer can reduce the uncertainty and complexity of the project, and adapt to changing needs and expectations.
In my experience, this works really well, IF you make it clear to the Customers AND the Dev Team that, in general, NO changes can be made to a sprint that has already started. Of course, there are always exceptions, but they should highly scrutinized and discouraged.
Agile Coach | Product Coach | Scrum | Kanban | Design Thinking | Product & Program Management
Think iterative investment. Maybe your initial forecast is that the envisioned product be delivered in ten to fifteen iterations. You don't then pay for ten or fifteen iterations. You invest in two or three or one. Then after they are done, you update your forecast based on what is learned. For example, the long-range forecast may be between eight and ten iterations. So, you invest in two or three more. Then repeat. Money is likely wasted if you pay upfront to cover the original forecast. Your investment is minimized through incremental investment.
Even with a clear scope and outcomes, and an iterative and incremental approach, changes are inevitable in an agile project. Changes can arise from various sources, such as new customer requirements, market conditions, user feedback, technical issues, or quality standards. However, not all changes are equal, and some may have a significant impact on the scope, quality, schedule, or cost of the project. Therefore, you and your customer need to negotiate changes based on their value and impact, using criteria such as urgency, feasibility, alignment, and trade-offs. You also need to document and communicate the changes, and their implications, to all the stakeholders involved.
Always have a mitigation fallback plan in place should key things change in the project so that you can still deliver with top notch quality and time. Taking shortcuts when it comes to product usability, quality and performance matters when it comes to rolling out these changes.
Agile contracts specify how the work is done. Investment is iterative. Scope change is expected and is renegotiated at the close of every iteration (sprint). Since scope change is expected, detailed requirements (deliverables) are not specified in the contract, minimizing any need to update or renegotiate them.
Another way to deal with changes in an agile contract is to share the risks and rewards between you and your customer. This means that you and your customer will agree on a fair and transparent mechanism to adjust the price or payment of the contract, based on the actual performance and value of the product or service. For example, you and your customer can use a target-cost contract, where you will estimate the cost of the project, and share the savings or overruns proportionally. Or, you and your customer can use a performance-based contract, where you will link the payment to the achievement of specific outcomes or indicators. By sharing the risks and rewards, you and your customer can create a win-win situation, where you both have an incentive to deliver the best possible product or service.
When both parties involved in a project share risks and rewards, it creates a motivating environment where everyone strives to deliver the best possible product or service. This arrangement leads to a win-win situation for both the contractor and the client. A target-cost contract, which is commonly negotiated between the contractor and client, allows for the sharing of deviations between the actual cost and the target cost. This type of contract provides control over risk management, cost estimation, and ensures the quality of information. It fosters collaboration and encourages both parties to work together towards achieving mutual success.
Finally, one of the most important aspects of managing changes in an agile contract is to collaborate and communicate regularly with your customer. This means that you and your customer will establish a close and trustful relationship, where you will exchange information, feedback, ideas, and suggestions frequently and openly. You and your customer will also involve other stakeholders, such as users, end-customers, or experts, in the planning, development, testing, and delivery of the product or service. By collaborating and communicating regularly, you and your customer can ensure that you are on the same page, that you understand each other's needs and expectations, and that you can resolve any issues or conflicts quickly and effectively.
When have the need to hire an external agency to work for you, you should treat them the same as if they were an internal team. The nature of the work is the same. If the work would be handled by an internal scrum team, then do not negotiate a "waterfall" contract with the external agency. Fixed scope, schedule, and cost are waterfall expectations.