Please note that this blog is archived and outdated. For the most current information click here!
The Benefits of Agile Software Development
It seems like every software project nowadays is 'agile.' Or at least it's said to be. So why the fuss? To understand why the market gravitated towards agile, we must first understand where it came from. Before agile the main project management approach was waterfall. Essentially the waterfall methodology means roadmapping all your features and completing them in sequential order, with a final release at the end of the project. If you're interested in learning more about the differences between agile and waterfall development then follow this link.
What is agile development?
The concept of agile originally surfaced through the agile manifesto. The manifesto contains 12 Principles which outline what to prioritise during a project build. What has arisen from this methodology is a number of different frameworks including Scrum, Kanban, Kaizen and Lean. But at its core agile is a mindset. A mindset that helps projects thrive in complex environments. It ties in well with product/market fit by putting the emphasis on customer collaboration (one of the agile principles).
Benefits of agile
1. Mitigates the risk of budget blow outs
The main criticism of waterfall development was the likelihood of projects running overtime and over budget. When one phase of development is reliant on the prior phase it makes it extremely difficult to deliver an entire project on time. This is especially true in the software development industry where there are so many complexities and unknowns. With agile we can prioritise smaller increments of work that don't depend on previous work being completed.
2. Better product/market fit
One of the manifesto's values is customer collaboration over contract negotiation. The key is to put the customer at the centre of everything we do. It allows us to focus on a problem statement and solve it for the customer base. By building in increments we can test out different solutions without having to wait till the end of the project to see if they work.
3. Increased stakeholder collaboration
Many of the agile frameworks put a process in place for facilitating stakeholder collaboration. Scrum for example uses sprint planning and review sessions to ensure the product owner and the developers are aligned and working towards the same objectives. This also prevents getting to the end of a project only to realise your solution doesn't actually solve the problem.
4. Get to market faster
The sooner you can get to market the better. It opens up the possibility of licensing the software (and starting to make a return on investment), gathering customer feedback or even using the first version to raise more capital. There is a common saying that if you're proud of your first version then you've waited too long to launch.
5. More value, less time
One of the flow on effects from building in increments is that we can prioritise each increment. Let's say at day 1 we thought our users wanted a dashboard. But after building out the basic application functionality we tested the solution again and realised that a dashboard wasn't needed as much as an API integration with Xero. Being agile allows us to prioritise the integration above the dashboard and deliver that to users first.
Putting a framework to agile
Being agile is a great mindset but without the processes in place, it remains just that, a mindset. As mentioned above, there are many frameworks that have arisen from agile. We won't explain the differences between Scrum, Kaizen, Kanban, Lean and the increasing number of other frameworks in this blog. Rather, we'll briefly mention the way WorkingMouse has taken the methodology and created a process around it.
WorkingMouse's agile process
WorkingMouse follows our unique Way of Working. With extensive experience in the software development industry it was important to adapt based on learnings from past projects. The closest mainstream framework to the Way of Working is Scrum.
The most important thing to note is that the Way of Working is never complete. What works today may not work tomorrow. Twenty-five years ago the IT industry may have been satisfied with the waterfall methodology. As I write this there are growing critiques of agile with the formation of new methodologies. The best way to illustrate the evolution of the Way of Working is through examples of how it has evolved in the past based on pain points.
Pain point #1 Unclear requirements
One of the very first learnings made was the impact unclear requirements has during development. This is similar to trying to build a house without a blueprint. Next time you think about writing a list of requirements and handing it to a developer to start building the application, question the process. The Way of Working now requires projects to go through a scoping phase where all stakeholders align on the requirements before starting the build.
Pain point #2 Mismatch in expectations
While Scoping does mitigate this to a degree there are still minor differences in requirement interpretation that can arise. The first step is to work closely with the product owner to catch these early. Scrum development has a great system in place for this. Working in short sprints (2 weeks on average) with a planning and review session either side helps to catch any divergence. The other tactic that we added to help combat this pain point is to set user acceptance criteria with the product owner. This is a strategy used in Scrum and has helped to align expectations on a granular level.
Pain point #3 Unrealistic estimations
Software estimations are a notoriously difficult process. It's difficult to estimate how long something will take until you've done it. That is why there is always a layer of risk and unfamiliarity associated with estimates. Early on, we did not account for this. We also didn't account for the time spent in meetings (project and company related meetings). This led to a lot of late nights. To combat the pain point we introduced an allocation factor and risk factors to scientifically estimate on a software project.
To recap, agile is a mindset. Ensure you put the right systems and processes in place to be able to execute on that mindset day to day. It can have a significant benefit on the end product that is built.
