A Beginner's Guide to Agile
Anyone whose spent time looking into software development has probably heard of agile. However, being able to pinpoint what it is exactly can be difficult. With this in mind, we thought we’d lay out what this development approach actually is.
What is Agile?
Rather than being a single approach, agile is a collection of development approaches that were originally created for software development. Rather than designing and creating a product or solution in a single, multi-stage process, agile involves having multiple iterations of this process (called ‘sprints’). This aims at firstly creating a ‘minimum viable product’ (the simplest way of achieving the project’s aim), then repeatedly rebuilds this, creating a better solution each time. In these sprints, teams don’t necessarily attempt to build something that will be used in the final product, but rather create a solution that can then be rebuilt and improved upon. For example, if we were building a car according to agile methodology, we would create a skateboard in the first sprint as this is the simplest wheeled object that can get a user from A to B. We would then improve this solution with each sprint (for example, through adding an engine or a roof) until we eventually create something with all the features of a car. Small, multidisciplinary teams perform these sprints, working closely together to repeatedly plan and build a solution, learning more about the problem each time. In order to do this, teams are given overall control of their work.
Why Do Teams Use Agile?
The key thing about agile development is that it is, well, agile. As each sprint attempts to rebuild the solution from scratch, the solution has the freedom to change between sprints if necessary. This is crucial for software development for two reasons. Firstly, technology develops at an incredibly fast rate: between the beginning and the end of a project, it is likely that a better solution (using new or updated techniques) will become possible. Secondly, business requirements can change over the course of the project or can be too rigid to take advantage of technological advances. Businesses often make two mistakes about software development. Firstly, as a piece of software isn’t a physical object, they often underestimate how much effort it takes to create it. This means that they can expect their teams to make changes that are unfeasible as they overestimate how flexible software can be. Secondly, businesses can also underestimate how flexible software development can be as they expect it to be akin to developing a physical object, believing that teams will suffer from similar constraints. This means that they don’t allow teams to pursue opportunities for improvement. Through using agile development, teams can be as or more flexible than the business requires, meeting or surpassing business expectations and creating the best possible product.
Two key things to remember about Agile
1. Agile is as disciplined as other development approaches:
With its emphasis on flexibility and giving teams the freedom to control their own work, you may think that agile takes less planning, organisation, and paperwork. However, if anything, the opposite is true. Although what may happen within each sprint isn’t pre-planned, the structure of the sprints (for example, the number of sprints, the timescale they occur on, how often the team will meet) is strictly defined. As well as this, an ‘agile roadmap’, laying out what each sprint will aim to achieve, is created before the project begins. This means that the team knows what the aim of each sprint will be. Going back to the above example, if we were building a car according to agile, we might know that we were going to aim at building a four-wheeled transportation device in the first sprint, then aim at building a four-wheeled transportation device with an engine in the second sprint, then aim at building a four-wheeled transportation device with an engine and a roof in the third sprint. This frees teams from having to worry about project management and planning, allowing them to focus on delivering the solution at hand. Paperwork is also key in agile, as it ensures that what the teams learn in each sprint is recorded and therefore remembered. Again, through having rigorous paperwork, the team doesn’t have to worry about remembering previous sprints, allowing them to focus on the work.
2. Agile cannot guarantee specific outcomes:
As discussed above, although agile plans how teams will work and what they will aim to achieve, it doesn’t plan how the team will achieve this, as they discover the solution as they execute it. This means that you cannot expect specific project outcomes, as the team doesn’t know what their project will involve precisely. Rather than expecting work x to be completed by date y, you need to trust that the team will find the best solution and give them the flexibility to do this. This also applies to planning the sprints themselves – due to the nature of agile (where solutions are discovered as they are implemented), it cannot be guaranteed that each sprint will achieve its aim without any issues. This means that there will need to be time allocated in each sprint to address any of the issues that are left over.
How we can help
{n}.bora has extensive experience in working with agile development methodologies. If you need support with managing your own agile project or want us to find a technical solution for you using agile, please get in touch and we will be more than happy to help you.
