Time and again, customers ask us what is actually “agility”. Malte Foegen describes the term “agility” very aptly in one sentence:
“Agility is fast responsiveness in a complex world.”
Often, this still leaves questions unanswered. Examples are: Isn’t that the same as flexible? Adhoc? Does it have anything to do with the fact that we, as a modern employer, offer home office? And let’s be honest: How does all this fit in with responsiveness and fast regular deliveries?
Reason enough to get to the bottom of the meaning of the term!
The term “agility” as we know it today first appeared in 2001: 17 people spent three days in a ski lodge in Utah and defined in the “Agile Manifesto” how they envisioned the development of software. The result is the Agile Manifesto and twelve principles. The Agile Manifesto still exists today in its original form; at wibas, we now summarize the twelve principles into five. In addition, different agile frameworks bring their own values or principles. Kanban, for example, which can be combined very well with agile working, is also directly oriented to the lean principles; with Scrum, we also talk about the Scrum values:
Agile is therefore someone who aligns his actions as best as possible with the values and principles of agile methods.
What does the agile manifesto got to do with Scrum?
If you look at the context chronologically, the obvious answer is “nothing”. After all, the “Scrum” framework is six years older than the Agile Manifesto. But: The inventors of Scrum, Ken Schwaber and Jeff Sutherland, belong to the circle of 17 representatives of different development frameworks, who were present in said lodge in Utah; they have co-created the term “agile” on the basis of their invention Scrum; Scrum is therefore one of the frameworks, which is based on the Agile Manifesto, the values and principles – but probably not the only one.
In addition to Scrum, there are also other frameworks such as Design Thinking, which are based on agile values and principles. Even if there are differences within the frameworks, they use a common toolbox of (interchangeable) agile techniques, such as Pair Programming (Pair Working) or Continuous Deployment. To understand what agile means we need to keep in mind a golden rule: Agile starts with values, not with the implementation of a technique. It may seem scary, but the fact that I use Pair Working does not make me agile! The goal I pursue with it and the attitude makes me agile!
So much for the theory – but what’s behind it?
The big breakthrough of agile methods took place in software development. In other words, in an industry that traditionally works on a project basis. If we think of complex software products, it quickly becomes clear that the development time can easily take longer than a year. A lot of time, considering how quickly the industry and its business environment have changed in recent years. Of course, we want the software we develop today not to be obsolete by the time it is released. Today, we set ourselves the goal of developing a product that, when it is ready, will be state of the art. A laudable goal. However, today we have no idea in which direction the technology for implementation or the interest of our target group will evolve. Under these circumstances, it has been possible to build successful products in recent years by using agile frameworks.
Following the success of software developing companies, more and more companies in the areas of hardware and organizational development are also relying on agile frameworks and techniques.
What do agile companies do differently in their daily work?
While classically operating companies try to describe the target state of the product at the beginning of the project term, agile companies have invested their energy in the past years to remain responsive to ongoing changes. In doing so, they invest in degrees of freedom for the future. This primarily requires short development cycles and equally short coordination intervals with customers. These, in turn, require a close and open customer relationship that allows appropriate exchange and, if necessary, supporting conditions (e.g., suitable infrastructure for meetings and exchange), as well as the use of modern development techniques such as “continuous deployment” (software development) or “rapid prototyping” (hardware development). As a result, agile companies can constantly take customer feedback into account in planning, i.e. react flexibly.
That sounds a somewhat situationally elastic.
Of course, agile companies also have a clear direction and communicate it. However, we are talking here about a vision or a target corridor, not a target described down to the last detail.
However, there is still a significant difference between agile and situationally elastic: Agile frameworks (only) allow flexible changes within a clearly defined set of rules. At the same time, they also help to reflect on goals along the way and to adjust them if necessary.
…that may be the case in the software industry, BUT…
The speed of adaptation of customers and technical development on the market are faster in the software industry than in any other traditional industry or service sector. Nevertheless, even away from software development, companies today are forced to adapt quickly to the market in order to succeed in competitive situations. Industry and service organizations have therefore demonstrated how agile principles, frameworks and techniques have helped improve products and services in other areas. For example, our customers also rely on our experience in agile methods when building vehicle modules or improving customer services.
In their book “Organization in a Digital Age,” Malte Foegen and Christian Kaczmarek provide insights into practices that have proven successful in this regard.
Then everything is settled, isn’t it?
Theoretically, yes. Which is a good first step. In practice, however, there is a big difference between applying a technique, i.e. “we can deploy continuously” and “we have managed as a company to adapt to customer and market needs in an agile way.”
But that is a goal, we could call it a vision, that should be achieved in an agile way rather than a situation-elastic way. If you consider this vision worth striving for and would like to take the first step in this direction as a company, why not attend our agility workshop?
