Here at ATeam Software, our goal is to create the best value, functional software for our clients at the lowest cost to them. Those in the industry know that this fits right into the definition of what agile software development aims to accomplish. Its benefits are undeniable and its adoption is unstoppable, with a report from Capterra stating that 71% of software companies are now adopting agile as a primary development process.
While agile processes are just what the doctor prescribes for software-as-a-service (SaaS) business models, it’s unfortunately hard to deny that most of the time, agile principles can seem incompatible with the contract or outsourced software development business model. Here are a few things that might go wrong, as we have experienced ourselves at one point or the other:
- As much as we might embrace uncertainty as software developers, people in the business domain may (understandably) be less inclined to accept it as a reality.
- Conversely, your client might be very open to the idea of changing requirements, but are unable to deal with any additional costs.
- Your client is too busy to participate in the process, then delivers a major change request near the end of the project.
If any of these sounds familiar, you’re definitely not alone. Fortunately, this is a problem we have committed to try and solve and so far with moderate success. So we’re happy to share a few guidelines we’ve found to be useful when trying to implement agile software development into contract projects.
1. Start with the budget.
There is often a misconception that agile works only with slippery and flexible budgets, but according to the Project Management Institute (PMI), “because agile processes emphasize the use of timeboxes, they present a distinct advantage to achieving [fixed price projects].”
As a matter of fact, a key principle in many agile processes is “fixed budget, flexible scope“. You can take “budget” here to mean either the actual expense or the timeline, both of which are often proportionate. The reason this principle is especially relevant is because there’s certainly more than one way to solve a problem, and the cost of your options can vary widely.
Thus, we’ve found it’s very important to get an idea how much the client is actually willing to spend on a solution. From here on, as the software expert, the provider can come up with a solution that fits within the budget and propose that to the client. An article on the Harvard Business Review agrees with this point, stating that your agile project needs a budget and not an estimate.
“Your agile project needs a budget and not an estimate.”
AN ARTICLE ON THE HARVARD BUSINESS REVIEW
2. Commit to the problem, not the solution.
Related to the first point, as a software developer, it’s important to commit to solving the problem or business need and not to any specific implementation. Clients may have solid ideas about what they want, but as the expert, it’s the provider’s responsibility to find out whether that really is the best (and cheapest) way to solve the problem.
In the past, we’ve received requests that included detailed user interface mockups, and while that is definitely helpful as a reference, if you want to implement agile in the project, it’s wise to not commit to replicating the mockup in its entirety. Instead, drill down on what needs and problems the mockups actually address and commit to addressing those needs instead.
A caveat here is that this may be a slippery slope when it comes to legal contracts. Consult a law professional to make sure you are not setting yourself up for ambiguity in your legal obligations. The PMI suggests having a clear “definition of done” as a means of limiting your obligation to the client, without compromising on the flexibility of the solution.
3. Narrow down your projects.
This can be a little bit counter intuitive from a business perspective. After all, the bigger the contract, the bigger the revenue. However, it’s important to understand that big contracts also come with big risks not only to the client but to the provider as well. It’s hard to predict what happens beyond the next month, so committing to working on something that spans half a year can set you up for a lot of issues later on – failure to deliver, budget overruns, and more. In fact,
Keeping your contracts to smaller time frames and more focused scopes can help you mitigate these risks. In the end, if your client is satisfied with the outcome of a smaller project with you, there’s no reason they would not take you on for more development projects in the future.
4. Involve the client consistently and as early as possible.
A key value that agile brings is being able to uncover misunderstandings and wrong assumptions as early as possible in the project. As such, it’s important to keep your clients involved in evaluating the software as early as possible. The sooner they see the work in progress, the sooner they realize they need something else and the less rework you will need to do down the line. A positive side effect of this is that getting the feedback loop going early on builds trust with the client from the get-go, something we have personally experienced ourselves.
This is definitely not as easy as it might sound – many clients feel they don’t have the time to be as involved as you would want them. However, as this is crucial in successful agile adoption, it is worth the extra effort to give your client an understanding of why this is important and get their buy-in to participate in reviews frequently. A few sprints into your project should be more than enough for anyone to fully realize the benefit of this approach.
5. Keep it open ended.
This part can also get tricky from a legal contract perspective, so do consult with a law professional to make sure you are not putting yourself at risk. However, if at all possible, scopes in contracts should be open ended and include clauses that allow for changes in the middle of the project, both to the scope and the fees. The first three points above can mitigate a lot of the uncertainty involved in a software project, but it definitely cannot account for all of the uncertainty.
According to the PMI, “although the Fixed Price structure is intended to protect the project sponsor for cost and schedule overruns, it also limits innovation and business value”. PMI recommends a “dynamic scope option” in which the client can choose to add more items to the scope only if they decide to drop others.
This approach may take a bit of convincing for the client to accept as they would understandably want to have some level of certainty when it comes to the cost. Providing a cost table as reference may help ease their hesitations. Ultimately, it is important to communicate the acceptance of uncertainty to your clients to make sure there are no unrealistic expectations.
We’d like to leave you with this positive feedback we received from our own client who realized the rewards of agile adoption in a project we worked with them on for over a year: “You had the flexibility to change even our redundant ideas, because really, we also don’t know exactly what we want until we got to try it first hand.”
This sums up succinctly how agile can be used to improve how you work with a client on outsourced software development.
Transform your business in 2022 with us! Our software development consultancy packages are affordable and made to empower small-to-medium enterprises with digital solutions. Contact us below to get a quote!
