Agile software development is an approach to developing new software. It’s meant to be a collaborative effort amongst a team where software can evolve over time and be flexible during development, producing results that are better, deeper and last the test of time.
While agile has a lot of positives, it also has some challenges.
By nature, agile software development is tough to manage when there’s a strict timeline and budget in place, or an idea of what the end product is going to be. Typically, you will find stakeholders and upper management (those controlling the dollars) allowing only a certain amount of money being spent with a very good idea of what that amount will buy them.
This is not a surprise; it’s reasonable and understandable. They don’t want to purchase a fluid process. They want to purchase a clear end result – their product. When viewed in this way, agile can be seen as expensive and unreliable.
But these projects can be designed in such a way as to keep all parties happy.
How do you successfully balance developing a functional product, on time and on budget, using an agile approach that has yet to fully define requirements? Without requirements, you cannot estimate costs. Without estimates, you cannot make decisions. But creating requirements cannot be done without spending a lot of money to define what you need.
So, what comes first and how do we accomplish this? Let’s address a few of the most common questions from stakeholders.
Agile Software: How Much Will It Cost?
Building software is akin to building a house: It’s all about the budget. If you said you wanted a 3,000-square foot house, you will likely get quotes ranging from $400,000 to $4,000,000+ depending on how you want to build it and the decisions you make during the process. Software is not much different.
It can cost (almost) as little or as much as you want to spend.
There’s definitely comfort in knowing that a project will cost a certain amount of money (and time). However, the current state of software and technology doesn’t lend itself to the traditional model of purchasing X for Y, at least if you want the best possible product and make your purchase an investment rather than an expense.
Technology, security, requirements – and a vast number of other things are all changing daily. Costs are following suit. Yet, this is why being agile is so important.
With an agile approach, asking “how much will it cost” is like asking for an estimate from a builder without fully defined blueprints. That doesn’t mean it’s not a fair question – organizations and stakeholders need to make decisions based on numbers – but it isn’t an easy one to answer directly either.
Enter budgets and the idea of “MVP” (Minimal Viable Product). Your agile project needs a budget, not a cost estimate. It also needs an understanding of what your MVP is so you know what is minimally required. What is the minimum product needed and how much do we have to work with? With a budget and a loosely defined MVP, we can create capacity, timelines and get to work on making sure the minimum is hit, with the idea that we can do more along the way if there’s room.
Will It Stay on Budget?
Just like any other project, most IT projects will overrun the estimates if you don’t handle it with the correct process and discipline. As soon as a project starts, there’s often scope creep for various reasons:
- Product owners realize new features that weren’t envisioned at the state and need to have them. This follows the same principle of, “if you give a mouse a cookie, he’ll want a glass of milk.”
- Security threats evolve; we need to incorporate new protections.
- Competition changes; we need to stay ahead.
- Technology changes; products need to adapt.
- End users drive requirements; their requirements are forever fluid and we’re forever adapting.
- New challenges are uncovered that need to be addressed/solved.
There’s really a seemingly endless amount of reasons why scope creep happens. Controlling these overruns is the trick.
The agile process in fact does just that. You can collaborate and adapt during the process to adjust for new requirements and scope changes while keeping your MVP in line and your budget on track.
Stakeholders want fixed budgets. You have X-dollars; give me Y-product. If you take on a software development project with that mentality, you run the risk of corners being cut and future scalability being sacrificed – and in some cases you could still be over budget.
But it’s very rare to not have a budget, so it’s important that software development take budget and costs into account, but so not as to hinder quality and innovation. That’s exactly what being agile is all about.
Why not just develop your MVP to begin with? In agile, MVP is best used as a starting point of where you want to be by the end – a track to not steer too far away from unless requirements change or budgets/timelines increase. Staying on track with what is minimally viable and accepting that future phases of innovations will be done in order to continue to develop and enhance your product. An important message here is that if a software development project had a fixed budget from start to finish without future development, you are asking for failure.
Software products and projects are truly never done and in order to be successful as well as stay ahead of the curve, they need to constantly adapt and evolve. Technology is changing by the second, whether it’s the way we interact with it (devices other apps, etc) or the security we need, agile software development allows for these eventual updates to be baked in and changed along the way.
How Long Will It Take?
Collaboration really is the key to creating the best product!
An agile approach lends itself to endless collaboration, which creates the best possible product over time. When all parties can get together from stakeholders to tech to create a product it provides an enhanced understanding of what it is that is supposed to be developed.
This helps with many things. Not only will it create a better product because everyone is on the same page, but it will also help drive timelines and budgets to make sure there are no surprises. It also brings everyone together and builds excitement for the overall project.
But, this approach does mean that you have to be careful with agile software development, as more people are more often collaborating, if it’s not structured, bloating can easily occur and cause the project to become more expensive than differently structured approaches.
How can you explain this to C-suite stakeholders? Consider comparing the results of agile software development to other methods – by spending more time now, the team ends up with the right product and the right result. Or lay it out in dollars and cents. Spending more now, and taking the extra time to get it right, means less chance of mistakes being made in the end project, preventing the process from having to be repeated in a year or two. In other development methods, you risk not getting a completed project, not hitting timelines, not adjusting for scope change, etc.
Bottom line, there’s less risk and more reward with Agile.
‘Selling’ Agile Across the Organization
“Agile software development and traditional cost accounting don’t match”
– Rami Sirkia and Maarit Laanti
Your software development team should act as an extension to your product team, your stakeholders and your entire business.
Liventus specializes in creating custom software for organizations across many different industries. We keep our clients on the leading edge of their industries with the best software, integrations and automations.
If you have a project and want to talk, feel free to contact us and learn about how we partner and help you succeed through custom technology solutions.