Jaco Viljoen, Principal Consultant
Agile: Mindset before methodology
Don’t think you can just learn agile on a course. Agile is a mindset first and foremost, not a set of procedures.
As Wikipedia reminds us, the agile methodology evolved in the late 1980s and early 1990s, with the Manifesto for Agile Software Development was published in 2001. Some two decades later, we understand a little more about what agile entails, and what it means.
Agile was a response to the rather clumsy, high-stakes waterfall approach to software development, in which the project moves through a series of steps from requirements through design, implementation and verification to maintenance. It was borrowed from the manufacturing and construction industries in the 1950s, as no formal software methodology existed. The waterfall method is still used because it seems to make intuitive sense, despite its numerous shortcomings in software development.
One of these shortcomings is the rigid delineation of roles. As the project moves from one stage to the next, there is little or no contact between the various role-players or stakeholders. Any divergences between what the business desired and what the developers have produced only becomes evident when then process is nearing completion. Correcting mistakes can thus be extremely difficult and expensive because of the effect across all the code.
In addition, correcting major disconnects between business requirements and the actual product could potentially require major recoding, thus delaying launch and incurring extra expense.
Another shortcoming is that the waterfall approach does not easily accommodate changes in what the business requires. This has always been an issue, and has become more critical in today’s world, in which speed to market and responsiveness to an ever-shifting competitive environment is key.
By contrast, agile promotes teamwork and collaboration across the life cycle of the project. Business and development work together closely, and the whole team takes responsibility for results. The development process is broken up into tasks made up of small increments, with cross-functional teams working closely in an iterative style, creating a working product that can be shown to customers. This approach, as the name implies, also means that the process can adapt to changes quickly, and as testing forms part of each iteration, bugs are caught early on.
Other hallmarks of agile include the automation of as much of the process as possible (for example, testing), and continuous feedback from the business. This is represented in continuous delivery.
Over time, a number of agile methodologies have been developed and can be taught, but the essence of agile is this collaborative, iterative approach in which every team member takes responsibility for the quality of the output.
Many companies are cynical about agile because they have adopted a tick-box, role-based approach to implementing agile, without ensuring that the necessary mindset change is embedded in the team as a whole.
A recent development in agile is the emergence of the DevOps philosophy also referred to as Agile 2.0, which attempts to carry through the improvements in software development delivered by agile into the production environment.
On the horizon there’s the emergence of what some call Agile 3.0, which applies the principles of Lean product development, and particularly the Lean start-up, to agile. Lean, which came out of Toyota in Japan, emphasises zero waste, total quality and more customer value. Lean start-up is a method for developing businesses and products first proposed by Eric Ries. Based on his previous experience working in several US start-ups, Ries claims that start-ups can shorten their product development cycles by adopting a combination of business-hypothesis-driven experimentation, iterative product releases, and what he calls validated learning. Adapting Lean to software development is seen as a way to return agile to its roots or essence: collaboration via fewer steps to deliver more value with less wasted effort—without losing sight of continuous improvement via validated learning.
Author: Jaco Viljoen