All posts filed under: Agile

Agility and Alignment: Strategy as an Empty Sphere of Action

When it comes to agility, most people think of Kanban or Scrum at the team level. And then of course the many scaling frameworks come to mind like LeSS, SAFe, DAD or Nexus. These frameworks primarily address the question of how the work of several or many teams on one or more products can be coordinated and synchronized. Especially in legacy IT landscapes with many dependencies this is a legitimate and frequently asked question, which unfortunately often obscures the far more important question of decoupling, but that is different story. The focus will now be on the question of how to give agile organizations alignment at different flight levels with corresponding planning horizons. And to this end, it is important that strategy remains an empty sphere of action that is filled with content from bottom to top.

The Dead End of the Agile Transformation

Copying Spotify or simply implementing any other blueprint of an agile organization is a fundamental mistake. Not because the models themselves were poor, but because implementing a model of an agile organization that has been chosen or developed by a few managers, experts or consultants from top to bottom contradicts the essential principle of self-organization. Agile organizations are always emergent in the sense that they result from the cooperation of self-organizing teams towards a common vision and are constantly evolving. Therefore, it is crucial for a sustainable agile transformation to withstand the pressure to deliver short-term successes and to empathetically and confidently give people the space and time to learn and grow together. As tempting as blueprints and their large-scale implementation may look, it is precisely this that leads the agile transformation into a dead end.

Stop Starting, Start Finishing!

We really don’t lack opportunities and choices. There are always more ideas than can actually be implemented. This is true at the level of the individual as well as for teams and organizations. The fact that technology makes our world turning ever faster and that our world is becoming ever more volatile, uncertain, complex and ambiguous, i.e. tending more and more towards VUCA, leads to an unprecedented wealth of opportunities and ideas. This makes it all the more important to focus which is the responsibility of leadership. And focus begins with the apparently forgotten art of saying no.

Change Never Comes for Free

How do people cope with change? Family therapist Virginia Satir has provided an interesting model that can also be applied to organizational changes. A stable status quo is challenged by a foreign element. After initial resistance to the foreign element, the confrontation with it initially leads to uncertainty and chaos and thus to a loss in productivity. Depending on the strength of this impulse, this phase lasts for a longer or shorter period of time until the chances of change are finally understood and utilized. Gradually, the group will return to its original productivity and hopefully grow even further. In essence, however, this model means that change can never come for free. As trivial as this sounds, organizations rarely admit this in both large and small changes. And then fail due to false expectations and their impatience.

The Benefits of Feature Teams

Agile methods and especially Scrum look very simple in a small product with a single team. As soon as several teams work on one product, the work has to be split up somehow. The obvious, because well-known, approach is to break down the product more or less logically and meaningfully into components and to assign component teams to them. From the customer’s point of view, however, these components are completely irrelevant. At best, the customer doesn’t realize them. In most cases, however, he does, because there usually several component boundaries have to be crossed to realize customer’s benefits and the product’s necessary functions. This results in handovers and coordination between teams that interrupt the flow. From the customer’s point of view, it would be much more desirable if the new feature was implemented by a single so-called feature team, no matter which components are affected.