Misunderstood agility
- ‘Our development is too slow? No problem! We’ll work agile from now on!’
- ‘The competition is faster? No problem! We’ll overtake them with agility!’
- ‘Employees are demotivated? We have the solution: agile working!’
Unfortunately, these ‘solutions’ overlook the primary goal of agility: the development of good software. This is exactly what the manifesto for agile software development is all about. Good software development. No more, but also no less.
Practice – the centrepiece of agility
Agility was originally created to free software development processes from the shackles of cumbersome and bureaucratic methods. Agility emerged as a response to these challenges – not as a theoretical concept, but as a practical necessity. It was not about creating a trend or defining rigid methods. The heart of agility is practice – the art of developing good software. Software that really works and proves itself in the real world.
In this sense, agility is not just a set of tools or methods such as Scrum or Kanban. It is a way of thinking that focuses on the result: software that creates value, is user-centred and can adapt quickly to changing requirements. This approach puts the needs and feedback of users at the centre and recognises that the true measure of success is not process compliance, but the quality and usefulness of the end product.
In other words, the winner of the game is not the one who adheres most closely to the Scrum Guide, but the one who develops the best software from a market perspective.
The agile mindset or the focus on results
What came first in agility? The methods or what we know today as the manifesto for agile software development? Sometimes this question is answered with the construct of an ominous ‘agile mindset’. The next step is then the overbearing demand that people in the organisations should please develop this agile mindset. This is highly problematic because, on the one hand, it labels people (agile or not agile) and, on the other, the term mindset remains extremely unspecific (and, incidentally, does not appear anywhere in the manifesto).
The origins of the manifesto are much more mundane: all of the signatories were genuine experts in the field of software development. They used and developed a range of methods for themselves that they considered suitable for their daily work. At the time, these methods were also much more diverse than today’s Scrum monoculture would suggest. [1]
The legendary conference in Snowbird, at which the manifesto was written, was apparently on the verge of ending on the second day without a resilient result: ‘Lots of great discussions happened over the 2-day event, however, late into day 2, nothing actionable had come out. The team was kind of in analysis paralysis until Dave Thomas and Martin Fowler tried to summarise the discussions so far based on the common ground between the different methods.’ [2] Thanks to the intervention of Thomas and Fowler, the participants were finally able to agree on a kind of lowest common denominator: The unifying elements and commonalities of the methods they were pursuing at that point.
Paradoxically, it was the methods that stood at the beginning. However, the signatories of the manifesto were all gifted experts in their field, for whom their methods were nothing more than practical tools for their work. In this sense, the manifesto is a kind of method filter[3] that helps to distinguish sensible from nonsensical approaches in software development. No more and no less.
Even if methods are at the beginning: They are nothing more than tools in the hands of talented software developers. With the help of the manifesto, they can better decide which tool they want to use. This is also the most serious difference to the cumbersome process models that place the process and its adherence at the centre of action.
Agility beyond methods
The fascination with approaches such as Scrum and Kanban in the agile world repeatedly leads to limited perspectives in practice. While these approaches provide a framework, there is a danger that they become rigid templates that obscure the real goal of agility: the flexible and effective development of software.
The true potential of agility lies in using methods as a starting point and creatively adapting them to the challenges at hand. In doing so, it is important to internalise the basic concepts of agility and to be able to differentiate between good and bad ideas in terms of the method filter. For example, it is a good idea to look at the flow of work and optimise it, and a bad idea to look at the workload of individual employees.
A deeper understanding of agility therefore requires a step back to look at the bigger picture: How can we design our processes and ways of working so that they promote the development of high-quality software instead of getting lost in methodological intricacies? It’s about creating an environment in which continuous improvement, flexibility and a focus on the end product are not just ideals, but a practical reality.
Summary
The manifesto for agile software development can serve as a lens for analysing and adapting the specific environment. Technical skills, for example, play a decisive role in agile software development. The ability to develop high-quality software efficiently is the foundation on which agility is built. It is not just about delivering quickly, but also ensuring that what is delivered is of high quality and sustainable. Agile teams must therefore constantly strive to improve their technical skills and familiarise themselves with the latest technological developments. Does my environment support me in achieving exactly that, or does it favour quick, short-term and messy solutions that slow down my software development in the long term?
Even though agility has its roots in methods, it goes far beyond this and focuses on the fundamental goal of developing effective and valuable software. The art of agility lies in the ability to adapt methods to specific project situations based on a deep understanding of agile principles. It may also make your development faster, it may help you outperform your competition, and it may help motivate employees, but these are only peripheral aspects. The real issue with agility is and remains the development of good software.
Notes:
Would you like to talk to Jonathan Frankenberger about agile working methods, machine learning or software development? You can easily get in touch with him via LinkedIn.
[1] https://agilemanifesto.org/history.html
[2] https://www.kaizenko.com/a-behind-the-scenes-look-at-the-writing-of-the-agile-manifesto/
[3] I learnt the term method filter from Mark Poppenborg and Lars Vollmer at Intrinsify.
If you like the post or want to discuss it, feel free to share it in your network.
Jonathan Frankenberger has published another post on the t2informatik Blog:
Effective practices for a successful software transition
Jonathan Frankenberger
Jonathan Frankenberger already realised during his computer science studies that software can often be developed better using agile methods. After a lengthy excursion into the waterfall world, he has been working agile again in various roles since 2016, primarily with Scrum.
As an agile coach, he currently supports product teams at BettercallPaul in “finding better ways to develop software”. He also works intensively on the question of what organisations need to look like in the 21st century in order to offer teams a good environment.