A little under two decades ago, a group of 17 software engineers met at a ski resort in Utah, USA. Their agenda was straightforward – they were disillusioned with the software development industry they believed was cumbersome, reactive, inefficient and more concerned with process than meeting the needs of end users. The group, which called itself the Agile Alliance, wanted change.
The result of that meeting was the publication of the Agile Manifesto, a clarion call for a new approach to software and systems development built around four core principles:
- To prioritise individuals and interactions over processes and tools;
- To value working software over documentation;
- To focus on collaboration with customers over contract details;
- To approach development projects with an adaptable, flexible mindset rather than a determination to stick to a preconceived plan.
It is this last principle calling for adaptability once development projects start that has come to define Agile methodologies more than any other, and which signal the most obvious break with so-called Waterfall workflows. First proposed in 1970, the Waterfall model describes a linear approach to development in a series of logical steps, whereby you can only progress to the next stage upon completion of the one previous.
For the Agile Alliance, this model was far too prescriptive and restrictive, and ignored the realities of developing solutions for living, breathing operations in the real world – requirements change, unforeseen problems occur, different and better solutions present themselves as you go. In addition, with its strict sequence of phases to be completed in order, Waterfall inevitably leads to drawn-out projects which can take many months to reach
Sprint cycles
Instead, Agile methodologies propose a cyclical model of development. The idea is that a single project might have many distinct cycles of development and iteration – known as ‘sprints’ – where the aim is to get a version of the application, or at least some of its functions, deployed and updated each time. Once up and running in a production environment, the product can be reviewed and assessed and changes made accordingly in the next iteration. It means clients get working versions of software up and running within weeks rather than months, and there is a process of continuous improvement to shape it according to their operational needs.
First proposed in 2001, Agile thus laid the foundations for major trends in software development such as DevOps, continuous delivery and design thinking. Coupled with parallel developments such as virtualisation and cloud computing, the influence of Agile can also be seen in approaches like headless and microservices.
Agile itself has continued to evolve as a concept, with the effect that it is now best understood as a family of methodologies rather than as a single approach. While the central goals of the various Agile models remain the same – rapid iteration, adaptability to change and partnership working with the end user – they differ in how they define and describe processes and sequences. Or, to put it another way, they differ in how they define and describe the workflow involved in a development project.
Adapting your workflow
This is actually extremely useful for developers and their clients alike. By emphasising different elements of the iterative workflow, different models within the Agile family offer different benefits and achieve different effects. This provides development teams with an extensive toolkit of options that can be used to achieve a wide range of deliverables, depending on what outcomes best suit the client.
As this blog from Cisco argues, the point is not to be agile for its own sake. The key is knowing how to be agile in the right way to achieve specific goals, to the benefit of both the service provider and the client. Speed of deployment, cost efficiencies, dynamic scalability, quality service and more may present themselves as operational priorities on different projects, or even at different times within the same project. Knowing how to adapt workflows to achieve those ends gives developers a competitive edge, and that can be achieved through understanding when and how to employ different Agile approaches.
For example, Scrum is a methodology which brings the concept of multiple, ongoing, incremental iterations to the fore – and where the concept of a ‘sprint’ originates from. The idea is to break down systems under development into separate functions, deploy each in a logical sequence and adapt priorities in close consultation with end users at the end of each cycle.
If Scrum focuses on workflows that deliver rapid, adaptable iterations, Lean Software Development and the related Kanban models highlight cutting waste from workflows and therefore driving efficiency gains. Lean uses value stream mapping to identify and prioritise the most valuable features of a system, empowering individuals and small teams to work both collaboratively and independently to maximise human resources. Kanban adds the element of workflow visualisation into the mix to help teams keep sight of the bigger picture and maintain an optimum work-in-progress balance – neither overstretched or underutilised.
All Agile approaches emphasise the importance of collaborative working between developer and client to ensure products are developed in response to real need. But this is especially important to the Extreme Programming model, which aims for exceptionally high levels of quality and responsiveness by placing customer feedback at the heart of continuous development cycles.
To give one final example, Crystal is actually a sub-family of Agile methodologies in its own right, and the focus of these is adapting workflow to suit the make-up of your development team. The idea is that teams of different sizes and skill sets require different approaches to optimise how they work together, so understanding the process dynamics of teamwork adds another element to how you can understand.
In summary, the ethos of the original Agile manifesto was to advocate developmental approaches which prioritised speed, client needs, collaboration, quality outcomes and, of course, adaptability. It is fitting that many different approaches to achieving these ends have evolved, each with a slightly different focus, to arm developers with a range of different models for how to adapt workflow to achieve different ends.
To find out more about how Aspire uses Agile methodologies to develop robust, flexible and scalable solutions for our clients, contact us today.