Agile Software Development

I’ve previously posted about planning out an application- how to get from an idea to an MVP. Pretty much everything I discussed fell under the ‘Agile Software Development’ umbrella, so I thought I’d discuss what exactly Agile Software Development is and why it’s so useful to adopt into your work flow.

History behind Agile

In the 90’s a few developers began to form a resistance against the way in which software was being developed. They argued it was too heavily regulated, they felt micro-managed and decided something had to change. There must be a better way to develop software, a way in which developers, clients and managers can work together, in harmony. Through the 90’s things like SCRUM and Extreme Programming (XP) as well as feature driven development started to evolve and take shape.

Agile Manifesto

So, fast forward to 2001 and the Agile Manifesto was published by a group of developers. This highlights the principals and values behind Agile Software Development. The four main values of the Manifesto are listed below.

Individuals and interactions over processes and tools

This essentially boils down to valuing people and communication more than the process and tools used in development. If tools were driving the development, the team becomes less responsive to change. Through valuing people and interactions, communication is natural and things are discussed as and when a need arises. It’s also important to value everyone on the team and understand that people are the ones to respond to the changes, not the tools being used, so it’s important to keep communication and interaction open to allow for a more efficient and agile team.

Working software over comprehensive documentation

This is one I can’t agree with more. As great as it feels to plan something out and write up this lovely, colourful document that someone will probably bind and laminate is such a waste of time. What you start with is almost never what you end up with, requirements change, opinions change, feedback guides you to a different path and your document becomes obsolete pretty quickly. I’m not saying don’t plan or write down your requirements, you still need to plan, but don’t over complicate things. Start with user stories, keep the document simple and to the point. Allow it to be flexible so when things do change, you’re not left feeling like you’ve wasted a week diagramming out the settings page. Agile still values documentation, it just values working software more.

Customer collaboration over contract negotiation

Originally the customer may only go through the requirements at the start of a project and then, once it’s finished, the end product is revealed. More often than not the customer would forget what the original idea was or their needs had changed, so when the final product is delivered it may look entirely different to what the customer had in mind. Equally the developers may stray or have misinterpreted the customers needs, also leading to an end product that doesn’t meet the customers requirements. This is why we collaborate and involve the customer in all stages of development. This avoids miscommunication and creates an environment where everyone is collaborating towards a more functional end product that is inline with the needs of the customer.

Responding to change over following a plan

Back in the old days following a plan was the only way people knew how to build software. Over detailed, over analysed, verbose plans were created and followed to the point. This is great for some industries, where you have a set procedure and the outcome is always the same product, say building a car or baking a cake. You have a plan or recipe you follow, which is detailed and lays out point by point what needs to be done. If you leave, someone else can pick up from the point you left off and the end product won’t be affected in anyway. It’ll still turn out the same way. If it hasn’t occurred to you already, this is not the way we develop software. Software changes as the needs and requirements of both the customer and end user changes. Through building features in iterations, you can shift your priority much quicker if the circumstances demand it, changes provide additional value. It gives you a much tighter development cycle, the customer is able to see progress over each iteration and if something changes, the development team is able to respond to that change quickly and implement the necessary action in the next iteration.


This is a brief overview of Agile Software Development. As well as the four values listed above, there are a list of twelve principals, which further build on the points above. Some of the things listed above may come across as common sense, but there are still companies out there implementing the old-style waterfall method. Everyone is different and everyone has a different work style, but for me I can’t see another way you’d want to build software. It’s all about continually improving your product, iterating over it and reacting to change as and when required. Plus, more importantly, it creates a team that communicates, this is vital in any business. Communication is key. Working within an Agile environment gives people the space to grow, it empowers them and it’s way more fun building stuff when everyones getting on and talking.

That’s my take on Agile Software Development. I welcome your thoughts and discussion and, as always, if you liked what you read subscribe, recommend and share it around!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store