The Agile approach to software development
Does anyone remember how we took photos before digital came along? You needed a clear idea of the conditions, the set, the subjects, and then you would shoot in burst, using up all the film. Once you were done, you waited impatiently for the development and then found out whether you had taken great shots, bad ones or burnt good ones….
But let’s go back to the present day and revisit the same situation: set up the conditions to take a good picture, take the shot and… immediately check the result! If it’s not satisfactory, revise the conditions, adjust the light, move the subjects, change the filters and effects and you’re ready for a new shot. Not good? Start again until you have the perfect photo that gets you millions of likes on social media. Agile, isn’t it?
But what does this have to do with software development? A lot, but maybe it’s time to make things clear and tell a story…
In the beginning there was Waterfall
The ‘Waterfall method’ originated in the manufacturing industry and in the construction sector, where the work process must be linear. Think of building a house: first you have to find the ground, then you have to build the foundations, the walls and so on, following a very linear pattern until you get the finished product. When software development began to be conceived as an industrial activity, this methodology was also applied in this field.
In 1970, the computer specialist Winston W. Royce was the first to propose the application of this approach to software development processes. The name “waterfall” was coined a little later, its first official appearance being in a 1976 paper by T.E. Bell and T.A. Thayer.
The original ‘Waterfall model’, also called ‘waterfall lifecycle’ or ‘software lifecycle’, was based on linear sequential phases:
- Requirement analysis
At first, the introduction of the waterfall model was a great innovation, considering that it was a time when the approach to development was defined as ‘code and fix’, proceeding by trial and error.
Around the 1980s, this method began to be questioned, the main shortcomings emerging particularly when dealing with very big projects whose requirements were not clear from the start. The linearity of the method did not allow to retrace one’s steps with ease (…or with agility…) and each phase had to be completed before the next could be tackled.
Over time, the waterfall model was revised and improved, and the software industry still uses it today. The model’s linearity and simplicity of implementation still make it a valid approach, for example when dealing with small projects with precise and clear specifications from the outset, with restrictive time and budget constraints, or with stringent legal constraints.
Remember what we said about photography? There’s no doubt that even before digital photography came along, masterpieces were created! Of course, to achieve such results, the most experienced photographers left nothing to chance: everything had to be organised to the smallest detail before going behind the camera…
And then came Agile
But what about today? How do we behave in this ever-changing world, where market requirements are changing day by day and competition is running at lightning speed? The answer is one: you have to know how to adapt with agility!
In the mid-1990s, the software industry began to wonder how to cope with this situation and how to quickly churn out working, quality software that could stand up to the changing market. They started talking about ‘agile’ approaches, which were lean, iterative and focused on the real needs of the customers. The development process was no longer seen as a rigid and linear sequence, but divided into repeated phases called sprints. In each sprint, it was possible to analyse small parts of requests and evaluate the best way to develop them, before moving directly on to development, testing and release.
So it was that in February 2001, at a ski resort in Utah, seventeen industry ‘thinkers’ met to ‘talk, ski, relax and try to find common ground, and of course, to eat’. Out of this idyllic meeting came the ‘Agile Alliance’, a kind of Avengers of Software Development, who set the famous ‘Manifesto for Agile Software Development’ in stone.
The manifesto shifted the focus to new issues, considered more important than the fundamental aspects of the Waterfall method. Principles such as people and iterations, working software, continuous collaboration with the customer and adaptability are given priority over technical issues such as processes, tools, documentation, negotiation and linearity. The manifesto also contains the famous 12 principles underlying the Agile Manifesto, principles that reinforce the basic concepts of the Agile approach.
The focus on needs, iterations, relationships and collaboration has led to the obvious consequence of having to revise the process defined in the waterfall method, thus moving from a rigid and linear process to a more agile, lean and adaptable process based on single iterative development phases, the so-called Sprints.
But how do these phases work? Each Sprint allows the release of a part of the application containing specific functionalities agreed at the beginning of the Sprint itself. The customer has therefore the opportunity to use and test the software, giving valuable feedback to the development team, useful for continuing the implementation in the following sprints, moving closer each time to a final product of higher quality and closer to his needs.
Today, when we talk about the Agile approach to software development, we are actually referring to real Agile methodologies that share the same philosophy, the same features and often the same tools. This allows companies that want to follow the Agile method to choose the techniques that best suit them, project by project, situation by situation.
The main Agile methodologies used today are:
- Agile Scrum Methodology (or simply Scrum)
- Lean Software Development
- Extreme Programming (XP)
- Dynamic Systems Development Method (DSDM)
- Feature Driven Development (FDD)
Let’s go back to our first example: an ‘agile’ approach to photography certainly doesn’t turn us into the new Oliviero Toscani, but it certainly allows us to impress with our shots, save money on film (no more available on the market…) and plenty of time!