There it is again. The supposedly simple question of what agility actually is. I’ve faced it again and again in the past years and the answers were always different. This question is probably not as easy to answer as it may seem at first glance. Nevertheless, I would like to make another attempt at this point.
Where do agile working methods help us?
Let's start with the question of where we should use agile working methods and where they really provide us with added value, because no methodology should be used as an end in itself.
In very simplified terms, it can be said that wherever complex problems predominate or we cannot predict exactly what the solution to a problem should look like or what the customer wants exactly, agility helps us. Agility makes particular sense in the context of uncertainty, which is often expressed in the degree of complexity.
The complexity of a product or project can be assessed using the Stacey Matrix. The diagram by professor and economic theorist Ralph Douglas Stacey is a nice model for thinking about exactly this question in advance.
The diagram is divided into an axis for the requirements describing our planned product and the solution technology to be used.
If both are clear, i.e. if you are able to decide immediately on the right technology from the sea without any problems, if you know your customers’ requirements exactly and if you know with certainty what the market demands and what the solution should look like, then you are definitely travelling in a simple environment.
Then there is the area for complicated things and the area for complex tasks. The area for chaos, in which hopefully nobody moves and immediate action should entail, I would like to leave out today.
Complicated vs. Complex
But what is the difference between complicated and complex?
Here is a simple practical example: I buy a wardrobe from a Swedish furniture store – many parts, many screws. But I have a manual that I can consult and that helps me at some point to understand exactly how the wardrobe is put together.
If I have already assembled such a cabinet or elements of it several times, I may be able to assemble them at some point without looking at the instructions. So complicated things can be understood after careful analysis and solutions can be written down to make them controllable.
With these complicated things it is often still meaningful and possible to plan into the future with the classical procedures of project management, since the solution (after analysis of the problem) is known.
Now imagine turning a screw on the left side with a screwdriver and loosening a part somewhere in the lower right corner, without there being any obvious connection. Welcome to the world of complexity!
Here, forward-looking planning into the future is no longer possible with sufficient static relevance, but we need an empirical approach that allows conclusions to be drawn about the future from experience and observation of the recent past. These offer agile process models.
Complexity as a breeding ground for agility
Today we are experiencing an enormous speed of change, which we are confronted with on a daily basis. While we are still discussing decisions that have already been made, we may have to reconsider them.
By the way, this is not just a phenomenon we are confronted with in software development. Just observe the daily events in politics and business and the many dependencies and effects of decisions that are made there.
For example, did the British understand the possible impact of a brexit at the time of the referendum? Or the Monsanto takeover of the Bayer Group, an economically sensible but ethically questionable decision, is now facing angry shareholders and class action lawsuits. Or the Diesel affair, which weaves industrialists, environmentalists, politicians and lobbyists into a complicated web of actions and decisions.
Especially in today’s age of digitalization, we are experiencing change more and faster than before. Consumer demands are constantly changing and new technologies are springing up like mushrooms.
So, as we can see, the world is full of complexity. But it has always been that way. So what is new is the approach with which we confront this complexity.
Classical approaches often don’t help us any more, so today we take advantage of an agile way of working.
But what is agility then?
So far, so good. Now we know where agility can help us in concrete terms. But we still haven’t clarified exactly what agility is.
Is it a new way of thinking? A development methodology? A way of life?
Let me give you the following definition:
“Agility is a characteristic of the management of an organization (business enterprise, non-profit organization or public authority) to act flexibly and beyond that proactively, anticipatively and proactively in order to introduce necessary changes.”¹
For me, agility is first and foremost a change in our way of thinking and, above all, a strongly empirical process.
In the complex environment just mentioned, we make assumptions or assertions about the needs of our customers with each new iteration and try to prove them in reality by translating them into a concrete product increment.
Agility means change!
In fact, from my point of view, the core of agility lies is change.
Change in the way we have worked so far.
Changing our products to meet new challenges in the markets and new needs of our users.
And last but not least, changes in our way of thinking (the notorious agile mindset).
Because especially in the cooperation of an agile software development team a lot is changing. The developers now create the solution for certain customer requirements and problems in a self-organized and self-responsible way. The responsibility for how a certain solution is designed and implemented lies with the team, within which ideally all required competencies are staffed with employees.
Above all, the products must continually adapt and change in order to proactively address changes in the market. This only works through constant observation of the market, close cooperation with the users of the product or measurements and tests.
Agility focuses on the customer
atrify’s product development is therefore completely customer-centric and focuses on its users as the linchpin.
User Stories are a proven and often used tool in agile development to align new features to the needs of the customer: They contain a simple textual description of which concrete problem is solved for which user and which added value it provides.
In concrete terms, this means that the development always takes place in close coordination with the customer. For example, the latest adaptations are regularly presented and active feedback is obtained from the customer. On the basis of this feedback we can then determine whether we are on track with our product or whether adjustments are necessary.
Transparency, Inspect & Adapt
In this way, we try to substantiate the assumptions made in the planning for problem solving (here we are back to the empirical process).
One of the core principles of agile product development is continuous review and adaptation. The agile development of a product always takes place in small, clear cycles (so-called sprints, usually 2-3 weeks), at the end of which the result is examined and measures and follow-up activities are derived.
Not only does the product improve continuously in this way, but the development team also takes a critical look at its working methods in the previous iteration. In the so-called retrospective, the team looks back and identifies suitable measures to improve itself and to work together even more effectively in the future.
Failure is no shame
Are we on the right track or do we need adaptation? By obtaining feedback from the users concerned, or the customer, or viewing measurement and test results at the end of the short iteration, we can determine relatively quickly whether we are on the right track or even need to steer in a completely different direction.
It can also happen that a goal set at the beginning of an iteration simply does not work in practice at the end. In this case, the thesis set out in the planning was simply not substantiated in reality.
However, we draw valuable conclusions from this supposed failure in the end and let them flow into the next sprint to simply make it better there. In agility, we see failures as opportunities and as active opportunities to learn from misconceptions.
The Agile Manifesto
Especially in software development, agile development practices have gained enormously in popularity since the first steps in Extreme Programming at the end of the 90s.
The agile manifesto can be regarded as the lowest common denominator of all agile process models. In the spring of 2001, 17 clever and experienced software developers came together and adopted this agile manifesto.
It anchors principles and guidelines for agile software development. Four essential principles summarize the core points I already mentioned above:
- Individuals and interactions are above processes and tools.
- Functioning software stands above comprehensive documentation.
- Cooperation with the customer is above contract negotiations.
- Reacting to change is above following a plan.
Here it should always be said that the values on the right are appreciated, but that the things on the left are given much more importance.
Further guiding principles are the twelve agile principles, which represent an implementation aid for the life of the above values.²
Agile product development at atrify
At atrify, we have been working with agile process models for several years in order to align our products more closely with the needs of our customers and offer outstanding and helpful solutions for their business requirements.
How we work with our customers, how we generate ideas for our products and provide solutions for them will be discussed in detail in my next article.
Sources:
¹ Steven L. Goldman (Ed.): Agile in competition: the strategy of the virtual organization for the benefit of the customer. Springer, Berlin Heidelberg New York Barcelona Budapest Hong Kong London Milan Paris Santa Clara Singapore Tokyo 1996, ISBN 3-540-60644-0.
² Beck, Kent / Beedle, Mike / Bennekum, Arie van and others: Manifesto for Agile Software Development (2001), http://agilemanifesto.org/iso/de/manifesto.html (07.06.2019)
