Agile Approach: Fixed-cost agile projects are a fool's errand
What is a fool's errand?
A fool's errand is an activity that has no hope of success.
Why is a fixed-cost Agile project a fool's errand?
Agile Software Development is a methodology that emphasises flexibility. Hence the name, Agile.
An antonym of flexibility is constraint. Flexibility (agile) and constraint (fixed-cost) work against each other as opposites.
Point made? No? Let's take a step back at look at this from a different angle.
What would it take to fix-cost a project?
It might be helpful to think about a project other than software. Let's look at something more everyday relatable, building a designer home (not a kit home).
If we are to determine the total cost to build a home before we've spent a single dollar on construction, we will need to spend time and money designing and planning.
An Architect will help us design our new home. They'll ask questions to determine our needs and consider other factors, like size, slope and elevation of the block of land.
After multiple revisions, you accept their work based on the renders, which help you envisage the final designs.
To rephrase that, we have completed the design phase. The design is agreed to and signed off by the stakeholders.
We can move on to the next phase, planning.
During planning, we'll need to conduct site surveys, choose contractors, get fixed-cost quotes from each contractor, and choose all fixtures and finishings. There is a mind-boggling amount of other things to do too.
After significant effort, we have a plan and the agreements to start construction. It will cost X dollars and take Y months to build.
To rephrase that, we have completed the planning phase. The plan is agreed to and signed off by the stakeholders at a fixed cost. Any deviation from the plan will come at an additional cost.
So far, it sounds analogous to a software development methodology, and it's called Waterfall. Whereby the next phase starts after the previous completes.
Hmm. We may need to look at Waterfall to see if it can successfully deliver a fixed-cost project.
Why is a fixed-cost Waterfall project a fool's errand?
Suppose you follow a phased Waterfall approach for your software development project and negotiate a fixed-cost contract with the App Developer. Then it's important to note that the Waterfall methodology has several pitfalls that can severely risk project success.
Some of the top pitfalls associated with the Waterfall approach:
Lack of flexibility: Waterfall is known for its sequential nature, where each phase must complete before moving on to the next. This lack of flexibility can be problematic when requirements change or issues arise during development, as it's challenging to accommodate these changes without disrupting the entire process.
Limited stakeholder involvement: Waterfall typically involves minimal stakeholder engagement until the later stages of development, such as during user acceptance testing. This limited involvement can lead to misunderstandings and misalignments between the development team and stakeholders, resulting in a final product that may not meet the actual needs and expectations of the stakeholders.
Late defect detection: In the waterfall approach, testing usually occurs towards the end of the development cycle. The discovery of defects and issues late in the process makes them more challenging and expensive to fix, leading to delays in project timelines and increased costs.
Long feedback loops: Due to the linear nature of the waterfall methodology, feedback loops are typically long. Stakeholders often have to wait until the end of the development cycle to see the product and provide feedback. Delayed feedback can result in wasted efforts if the deliverable fails to meet expectations and may result in rework to address feedback received too late.
Lack of adaptability to change: Waterfall is not well-suited for projects where requirements are uncertain or likely to change. If new insights or market conditions emerge during the development process, adapting to these changes can be difficult due to the rigid structure of the methodology, which can result in projects delivering outdated or inadequate solutions.
Limited risk management: The waterfall methodology does not prioritise early identification and mitigation of risks. Discovering risks late in the process can lead to project delays, increased costs, or even project failures.
Lengthy-time to deliver value: Waterfall projects typically have long development cycles before delivering any value to the end-users. Long development cycles can be a disadvantage in dynamic environments where quick response and early value delivery are crucial (e.g. Apple App Store or Google Play Store).
Difficulty in managing large projects: Waterfall can be challenging for large-scale projects. Coordinating multiple teams and ensuring synchronisation between different phases becomes more complex, increasing the risk of miscommunication, delays, and overall project inefficiency.
Reduced collaboration and communication: The linear nature of the waterfall methodology can hinder collaboration and communication among team members. Since different teams often work in isolation during each phase, there may be limited opportunities for cross-functional collaboration, knowledge sharing, and synergy.
Limited visibility and transparency: Waterfall projects often lack transparency and visibility into the progress of different phases. Stakeholders may have insight into the actual development process in the later stages, which can lead to uncertainties and make it challenging to track project milestones and identify potential issues in a timely manner.
While the waterfall methodology has drawbacks, it may still suit specific projects with well-defined and stable requirements, predictable environments, and minimal expected changes.
Additionally, the rigid structure of the methodology increases the likelihood of delivering within the fixed cost as the approach resists changes within the development phase. Resistance to change does not allow for adaption when new insights or market conditions emerge during the development process, which can result in projects delivering outdated or inadequate solutions.
That is a fixed-cost Waterfall app development project in a dynamic environment, such as developing custom apps for the Apple App Store or Google Play Store, has little to no hope of success. It's a fool's errand.
Why do fixed-cost Waterfall projects end up costing more?
It's worth pointing out that the Waterfall methodology does not inherently guarantee fixed costs. Since waterfall projects have limited flexibility for changes, any modifications or additions requested during the development process will incur additional charges. These change requests are often handled through change orders or by renegotiating the contract, leading to additional expenses and extended timelines.
Let's revisit our designer home analogy. Remember, the stakeholders (Client & Builder) agreed to all finishing and fittings before commencing construction. Additionally, both parties agreed to a fixed-cost contract.
During construction, the Client visits the building site and notices that the kitchen countertop does not suit the splashback tiles. Or at least not to their liking. It's a designer home, and the kitchen is vital to the value the Client will derive from the building they will call home.
The Client requests the Builder change the tiles. Unfortunately, the countertop and splashback installation is complete. For the Builder to meet the Client's new requirements, they'll need to remove the installed tiles, purchase new tiles (materials), and install the new tiles.
The Builder is happy to oblige but at an additional cost.
The Client has a choice to make. Do they accept the tiles as is, deriving reduced value from their designer home? Or accept the additional cost and maximise value?
The Builder also has a choice to make. Is the change request work done while the fixed-cost work is still underway? Or should any change request work be done after the completion of the fixed-cost work?
The risk for the Builder with the former is that the Client confuses change request work with fixed-cost work, which makes it more challenging to get the Client to sign off when the fixed-cost work is complete.
The risk for the Builder with the latter is that the change request work damages the fixed-cost work that the Client has accepted, creating additional unexpected work.
As with our analogy, the reality is that fixed-cost Waterfall contracts often incur additional costs through the change requests needed to work around the rigid structure of the methodology.
What are the risks of fixed-budget Agile projects?
If a Waterfall approach can't deliver on fixed costs, can Agile? Let's explore the risks posed by fixed-budget projects following an Agile approach:
Scope Creep: With a fixed budget, there's a risk that as the project evolves, new requirements emerge, which can put a strain on project resourcing and impact the project's success.
Compromised Quality: To stay within the budget, teams might need to cut corners, resulting in lower quality outputs or an accumulation of technical debt.
Insufficient Flexibility: One of Agile's strengths is adaptability. A fixed budget might limit the ability to adapt to changes effectively.
Unrealistic Expectations: Stakeholders may expect more than what can be achieved within the fixed budget, leading to dissatisfaction when the project fails to meet all the desired goals.
Incomplete Features: Constrained by a fixed budget, teams are motivated to deliver incomplete or inadequately implemented features.
Inadequate Testing and Documentation: Rushing or skipping testing and documentation helps to save costs, which can lead to the release of a buggy product or difficulties in future maintenance.
Misalignment of Priorities: The team may focus too much on adhering to the budget, causing a misalignment between the developed software and the customer's needs.
Poor Risk Management: With a fixed budget, there may not be enough financial buffer to manage unexpected risks or challenges that arise during development.
Communication Breakdown: Pressure to stay within the budget may cause team members to hesitate in communicating bad news or challenges, leading to a breakdown in transparency and communication.
Short-term Focus: The fixed budget leads to a short-term focus, where decisions are made for immediate savings but incur higher costs or consequences in the long term.
To mitigate these risks, encourage open communication with stakeholders, set realistic expectations, prioritise value-based features, and allocate budget contingency.
It is possible to deliver within a fixed budget following an Agile approach. However, given the above, we are introducing several risks which may be avoided by seeking to control costs rather than fix costs.
How can App Developers control project costs?
Controlling costs in an Agile software development project requires planning, monitoring, and adapting. Here are some steps to effectively manage costs:
Clear Objectives: Establish clear project objectives and scope. A well-defined understanding of what is necessary versus what is optional helps prioritise features and manage costs.
Frequent Estimations: Encourage the team to estimate effort for upcoming tasks regularly.
Regular Monitoring: Continuously monitor the actual costs compared to the budget. Use tools like burn-down charts to track expenditures.
Limit Work In Progress (WIP): Limit the number of tasks being worked on simultaneously. Focusing on fewer tasks can lead to faster delivery and lower costs.
Resource Management: Efficiently allocate human resources to ensure the right people are working on the right tasks.
Automate and Optimise: Implement automation for repetitive tasks like testing and deployment to reduce manual effort and associated costs.
Feedback and Adaptation: Obtain feedback early and often from stakeholders to identify issues sooner, preventing costly late-stage changes.
Effective Communication: Encouraging open communication within the team to identify issues early and lead to quicker, more cost-effective solutions.
Time-boxed Sprints: Utilise time-boxed development cycles to ensure that teams focus on delivering the most valuable features within a fixed timeframe.
Scope Management: Be vigilant about scope creep. Evaluate the impact of proposed new features or changes on the budget and timeline, and be prepared to make trade-offs.
Training and Skill Development: Invest in training for team members to ensure that they are up-to-date with the best practices and tools, which can lead to more efficient work processes.
Outsourcing and Delegation: Consider outsourcing or delegating non-core functions to more cost-effective service providers.
Technical Debt Management: Pay attention to technical debt. Accumulation of sub-optimal solutions can lead to higher costs in the long run. Allocate time to address issues periodically.
By implementing these strategies, teams can control costs while benefiting from Agile software development's flexibility and responsiveness.
Is a cost-controlled Agile project our pot of gold?
Successfully building and deploying an app on the App Stores (or delivering it to your workforce) is a complicated endeavour and requires a coordinated effort from your App Development team. Throughout this journey, all stakeholders will learn much about producing value for the app's end-user.
Flexibility throughout the app's development allows the team to adapt the app as we learn more about how they use the software. Seeking to fix costs might be good advice from your accountant or business adviser. Still, as we have learned, fixed-budget software development projects introduce many risks.
Avoiding these risks by seeking to control costs increases your chances of delivering apps people love to use. And as is our ethos at Code Heroes; if people love it, the business will love it too.
Get in contact to find out more.
If you'd like to learn more about how we help clients build apps that people love while controlling costs, please get in touch to learn more.