The core focus of Agile is on people, processes, collaboration, and iteration.
The basic premise is to allow for flexibility in how something is achieved, relying on a team's technical excellence and ability to assess and evaluate, adapt to changing demands, learn from failures, and drive ongoing improvements to deliver value.
Where the Waterfall methodology is linear, the Agile project development framework is more dynamic and iterative, breaking projects into several phases referred to as sprints. Post-sprint, Agile teams look for improvement opportunities and re-adjust their strategy according to new learnings before heading into the next sprint.
Enabled by autonomous, engaged teams and transparent data sharing, Agile ensures both quality and speed, shortening time-to-market by prioritising short feedback loops.
A cultural change: Why Agile sourcing is different
Procuring software developed using the Agile methodology looks different than traditional procurement.
Mirroring the methodology it supports, Agile sourcing flips the traditional target-driven procurement mindset on its head, focusing on nurturing highly collaborative relationships, widening specifications and scope to allow for innovation, and establishing contracts that ensure to balance risk and motivate suppliers. Rather than relying on strict processes, strong-armed negotiations, and governance, Agile sourcing is more fluid and pragmatic, focusing on ensuring quality engagement and honing in on value delivery and ongoing improvements.
Supplier discussions should happen early and often, leveraging supplier expertise to help define the scope and service level requirements. That said, to empower agility, the scope itself should be wider, more innovation-friendly, and remain open to change.
As an Agile procurement approach is underpinned by collaboration and partnership, procurement leaders should strive for less combative negotiations that embrace the spirit of Agile from the start.
Building a more Agile RFP process
“In preparing for battle, I have always found that plans are useless, but planning is indispensable.”—Dwight D. Eisenhower.
No matter how much information you lay out in an RFP, you do not know what you do not know. Nor do your suppliers. But that doesn’t render your RFP process futile. However, your RFP process must uphold the principles of Agile and may need a little fine-tuning to build in some flexibility and better mirror Agile’s non-linear processes that prioritize change.
By taking an outcome-based approach, building trust through mutual transparency, and fostering open, reciprocal dialogue, procurement leaders can enable bidders to meet due dates and provide quality, Agile-supportive bids, making for a more effective RFP process so you can start realizing the benefits of the new contract sooner.
Here are some best practices for creating a more Agile RFP process:
Find a good cultural fit. Agile is rooted in collaboration, and it’s not just the procurement/ sales dynamic that matters. It’s important that teams mesh well and work seamlessly.
Target requests toward business outcomes. As your focus is on business value, your priority should be to communicate end goals and wider project outcomes over listing specific feature requirements, i.e., What do you want your product to do or not do? Who are the end users? How do you anticipate the market changing, and how do you expect the product to respond to those changes?
Hold planning and discussion sessions separately with each vendor. A “one-on-one” will help them feel safe enough to ask questions. Explain or discuss options for an Agile contract model that works for both parties. Use this time to position yourself as a collaborative partner that’s open to discussion on how to find the best solutions.
Focus on evaluating the potential supplier’s capabilities to deliver business outcomes. A traditional waterfall-based RFP process would typically involve a thorough investigation of product features. However, in Agile sourcing, the goal is to establish a win-win contract that best supports Agile development.
Consider using a proof of concept (PoC) to help you determine the best solution provider. Although RFPs allow companies to sift through the weeds and eliminate suppliers that clearly aren’t a good fit, it’s not necessarily the best process for figuring out who is. When it comes to technology, there can be a severe disconnect between what sounds good in theory and what actually works in reality. Relying on RFPs alone can leave companies susceptible to bait-and-switch tactics and other quality risks.
Trust is the foundation on which Agile is built, allowing for free-flowing ideas, open communication, and healthy conflict without fear of repercussions or exploitation. By laying your cards on the table first and including your budget limitations and known risks within the RFP itself, you lead by example and start on the long road of developing mutual trust while providing potential vendors with critical information for more fair and accurate bids.
If you’re an Agile company yourself, you may want to consider using the Agile framework to adapt your RFP process. One company used Scrum for an RFP Project and restructured its RFP content to be more suitable for Agile.
Contracting for Agile
The effectiveness of a partnership is influenced by the agreements and boundaries established within a contract. Depending on the contract model that supports it, the partnership can be a win-lose or, worse, a lose-lose.
Conventional contracts that were designed for linear project structures with clearly defined milestones and delivery targets fail to support the flexibility Agile requires. Traditional contract models can slow innovation and lean too heavily on negotiation rather than collaboration. The terms also fail to fairly distribute risk or motivate suppliers to ensure quality and timeliness.
KPMG estimates that around 70% of Agile projects are contracted for Time & Materials (T&M). Although these terms protect suppliers, ensuring they’re paid for their time and materials, they leave buyers “to shoulder all the risk with no compelling incentive for suppliers to flag quality or productivity issues as they are being paid for their time and materials regardless of the outcome.”
Although there’s no rubric for what’s most suitable for every case—understanding each of the models, their pros and cons, and working with stakeholders to shape your approach is essential to creating a win-win contract that promotes Agile development.
Here, we lay out four alternative contract models for you to consider when contracting for Agile software development, as well as the advantages and disadvantages of each.
Time & Materials (T&M)
Flexible in nature, a T&M contract may be a suitable fit for proactive suppliers if final product requirements are unclear. As we’ve noted, the customer bears the blunt of quality and performance risks. Suppliers may be happy to sell their time at a profit and not concern themselves with deliverables.
However, if your software development partner is highly responsive and driven by customer satisfaction, a T&M contract offers the flexibility for the supplier to work under the direction of the supplier and adapt to changing demands, allowing you to add features and inputs after the contract has been signed.
Fixed price based on outcome
A fixed-price model is best suited to well-defined and documented MVP or Beta projects with a clear customer vision, a set budget, known feature requirements, and a hard deadline.
Risk to the buyer is minimal as the supplier is committed to the final price and outcome. However, risk can lie on the side of the supplier as pricing can be difficult to estimate and depends on the quality of the scope.
The pitfall is inflexibility if requirements change, which, ultimately, is anti-Agile, going against a critical tenet of the Agile Manifesto: Responding to change over following a plan.
Fixed price per story point
Story points are a unit of measure that estimates the amount of effort required to complete a user story in your product backlog (a product backlog is a list of bug fixes, features, and everything else to be worked on within a project).
The fixed price-per-story contracting model has emerged as a way to fill the disconnect between traditional contracts and Agile development.
In a fixed price per story point contract, the number of story points delivered dictates the price. As story points are estimated based on risk and uncertainty, as well as the amount of work and complexity, payment is proportional to the work performed.
Story points are relative, however—meaning that the numerical value assigned only has meaning within context, the values relative to each other. For instance, parties could agree on a ratio of 10, 20, 30, or 100, 200, 300. Either way, the ratio is what’s important, their relativity allowing developers to compare how much work went into a 10 vs. a 30 or 100 vs. 300. Although this works well for its intended purpose when it comes to contracting, it means customers and suppliers must come to an agreement on the value a story point represents.
Although the fixed price per story method enables you to pay based on output, there are some downfalls to consider.
Firstly, story points are estimated by the team completing the work and are subjective, another team (with different experience and skills) could look at the same story and determine a different level of effort and, therefore, assign more or fewer points. The team-specific, self-assigned nature of story points leaves you open to risk, as the numbers can be easily manipulated or falsely inflated. Teams with story point quotas are, after all, responsible for hitting them.
A solution to this is pre-estimating story points, however, as Accenture points out in Please, stop buying Story Points, which comes with its own set of problems.
Fixed price per sprint
According to the Scrum Guide, “Sprints are the heartbeat of Scrum, where ideas are turned into value. They are fixed-length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.”
With a fixed price per sprint contract, the supplier holds responsibility for the quality and volume of work performed within each sprint. With smaller commitments, however, comes less risk. The mechanism also allows for flexibility as the scope is defined within the sprint.
The approach was developed by KPMG and Coca Cola European Partners (CCEP) collaboratively with the goal of maintaining the benefits and flexibility of Agile and ensuring that its partners were delivering the right quality.
“Consequently, we have greatly improved the achievable and measurable quality of our shippable product, decreased the financial volatility of our Agile projects, and gained greater collaboration with a governance model that has clearer roles and responsibilities. We achieved all this while maintaining the creative freedom that our Agile teams need to thrive,” said Kai Uhlemann, Director, Collaborative Solutions , CCEP.
In an Agile environment built to respond to change, there will always be tradeoffs to manage. If the supplier is the one left "holding the bag," then they'll also be the ones setting priorities and deciding on quality vs speed. On the flip side, if they don’t have any “skin in the game,” they won’t be motivated to deliver both quality and speed.
With some ingenuity and collaboration, it’s possible to devise commercial principles that simplify cost management and ensure shared responsibility for quality and velocity for win-win contracts that support Agile development and foster long-term partnerships.
Regardless of the contract type, remember to stay true to Agile and include mechanisms for managing change. The Agile Contract Manifesto can act as a great guide, offering a set of principles for successful collaboration.
Of course, as contracts are legally binding and laws and regulations will vary by jurisdiction, it’s crucial to rely on legal professionals with expertise in Agile contracting.
Procurato; here to help
Not every solution is a fit. That’s why we’re here to help.
With vast experience in RFIs and RFPs for IT development (Application Think & Build), Procurato can help bridge your knowledge and resource gaps. From gathering requirements, and key deliverables to shortlisting potential solutions, tendering relevant suppliers, assessing capabilities, and benchmarking, we can ensure to find you the right strategic solution for your organisation that aligns with your goals.
Our team members have a diverse skill base and versatile experience to provide clients with the best solutions. Find out more about our expertise or contact us now to learn more.