Agile development is an umbrella term for a set of methodologies used to create software. Focused around four key principals the goal, like most methodologies, is to ensure delivery of the right solution. However, where Agile development differs from other approaches is that it embraces change. It understands businesses are constantly evolving and it understands that priorities change, any solution needs to be able to respond quickly to an evolving landscape.
With a typical waterfall project, the requirements are discussed, agreed and fixed at the beginning, with the solution only released at the end when every requirement has been completed; whereas an Agile project releases little and often, making course correcting adjustments at each opportunity. Agile starts by taking the most important requirement, creates, tests and releases just that, then takes feedback. Feedback could be the reprioritisation of other features, it could be a change of direction because of a change in the business, or it could even be the addition/removal of a feature because of a change in needs. Agile optimises for a shorter release cycle, so feedback can come as soon as possible, and customers can have value from the solution quicker.
Because of the long feedback cycle, heavy upfront investment in capturing all requirements and the need to complete all the features first, waterfall projects are more expensive when changes are needed, and they are more expensive to get the first version released. Whilst often their documentation heavy approach can feel very familiar and safe, it is just a distraction to getting the creative process going and adds delays in realising a working solution.
Making the leap into Agile can, at first, feel scary, the unknown delivery date and the focus only on what’s important now, not the entire solution can feel very alien, but it doesn’t take many quick releases to see the value and control it provides instead, which in turn provide confidence.
How we apply Agile
We believe that rather than putting process and documents in the way, passing requirements down like a baton, it is far better for a team to collaborate. At the start of each sprint our Developers work directly with the Analysts and Testers in breaking out the requirements together, this way we ensure everyone has a deep understanding of what is needed, and how the whole solution fits together.
Furthermore, we don’t like silos, we are all one big team, our Testers, Analysts and Developers all sit together, so they are always available to help each other out. No passing a feature on to another team to complete, the requirements are broken out together and delivered together. Each morning we have a daily progress meeting with everyone involved, lasting no more than 15 minutes. We ensure we are on track, we escalate anything blocking our way, and we listen to what others are working on, offering to help if we can.
For us a feature isn’t complete until it is deployed into production and we would rather have a few fully finished items than a load of half-finished ones; to that end we ‘pick from the right’ on our progress board. Before starting a new piece of work, people on the team have a look at the Kanban board, and offer to help others with what is currently in progress (a code review, a feature, even manual testing or deployments) before picking up something new. We want to ensure we deliver value as soon as possible, and often that is best done by helping someone who has already started.
Finally, at the end of each sprint we have a retrospective, we look back at what was completed, what we did well and where we could have improved. We ensure that we are always moving forwards, improving ourselves and improving the process so that with each sprint we get even better at what we do.