Category Archives: General

Map of Change – Orientation Aid for Change Management

What do I need for a successful change? What do I need to think about? With this Map of Change we try to give an overview of the most important elements of a successful organizational change. We have put these elements into relation with each other. Even though the Map of Change is designed with a humorous intention, it represents a sincere topology of the core elements of an organizational change.

The map is included in our book “Der Weg zur professionellen IT – eine praktische Anleitung für das Management von Veränderungen mit CMMI, ITIL oder SPICE” (The way to professional IT – a practical instruction for process improvement).

Continue reading Map of Change – Orientation Aid for Change Management

Prioritize and Say No Properly – A First-Hand Report

In one of our last articles, we went into more detail about the success story of our service team. Today, we’d like to give you some insights into some of the team’s learnings: With growing task areas, the team had to learn what it means to prioritize and say no.

In addition to the daily work, the team had all kinds of other tasks to take care of. Plus, there were requests from employees and customers – tasks and requests that could not be scheduled in this way. The sheer volume of these unplannable things soon meant that the team could not keep up with the daily work.

Continue reading Prioritize and Say No Properly – A First-Hand Report

Descaling instead of scaling: Why scaled agility should simplify the organization.


Quo vadis agile scaling?

More cheese, more holes

More holes, less cheese
More cheese, less cheese

Is this paradox cheese? Possibly. And is it transferable to the organization of organizations? It is possible.
One thing is certain: to achieve more with less in terms of organisation is not such a far-fetched idea at the latest on second thought. Especially when it comes to scaled agile frameworks, this idea is just too contrary. Continue reading Descaling instead of scaling: Why scaled agility should simplify the organization.

Agile Myths: User Stories – a mandatory format for Scrum Teams?!?

The User Story format is often used by Scrum teams to document requirements. It’s a short syntax that sounds totally simple, but when we sit down and try to fill this syntax with life, we quickly realize that it’s not that easy. Some of you may have stumbled across user stories that somehow sound “artificial”. So what is it about this little sentence? Why do so many people use it? And do Scrum Teams have to document requirements in the user story format? Don’t they otherwise make a “real” Scrum? Continue reading Agile Myths: User Stories – a mandatory format for Scrum Teams?!?

Agile myth: Writing user stories is Product Owner work

Again and again I am confronted with the statement that only the product owner writes and prioritizes user stories. The Product Owner is the person who prioritizes the Product Backlog. But for reasons I don’t understand, many people seem to be convinced that it is a core task of the product owner to sit down at his desk and write a user story until it is ready for a sprint. Is that really what the Scrum Guide says? Continue reading Agile myth: Writing user stories is Product Owner work

What is agility, anyway?

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?

X no longer marks the spot – Y we believe in something else

Theory X and Y describe two contrasting models of workforce motivation and behavior. They were created by Douglas McGregor in the 1960s. According to these theories, there are two types of employee behaviors that can be encountered. Theory X behavior is driven by extrinsic motivation, while theory Y behavior is driven by intrinsic motivation. Continue reading X no longer marks the spot – Y we believe in something else