Making decisions is often considered an essential element of leadership. An elite circle of executives makes decisions; at least the big and strategic ones and sometimes, depending on the level of trust in the organization, also decisions on details, leading to the plague of micromanagement. Reed Hastings, CEO of Netflix, is leading differently. He prides himself on making as few decisions as possible. And his success shows that he is right, as 20 years after its foundation Netflix is now the tenth largest Internet company in the world (Wikipedia).
Sustainability could be defined as a principle according to which no more should be consumed than can be replenished, regenerated or made available again in the future. Usually we think in macroscopic dimensions of our environment when it comes to sustainability. For me, however, sustainability begins on a much smaller scale, with myself and the sustainable use of my own personal resources, such as time, energy and knowledge. It is time to talk about relics from the industrial age and especially about how effective and sustainable the strict temporal and spatial separation of work and life (as if work were not life!) in terms of eight-hour work days really is.
There is a fundamental misunderstanding around agile. This misunderstanding begins with the title of the Manifesto for Agile Software Development. For too long, many considered software development to be the translation of specifications into code by interchangeable programmers completely disconnected from their customers and their products (and often reinforced by contracts). And this is exactly what many still understand by software development nowadays. Only in shorter cycles. Simply agile. But the authors of the manifesto, all passionate software developers, were concerned with something else. They tried to put software development back at the core of value creation and to eliminate all the waste around this core, all the heavy-weight processes and their manifestation in organizational structures. Their aim was to build software as a long-lived team really owning the product. And there must be no middlemen between team and customers with corresponding artifacts and handovers. Instead, business people and developers must work together on a daily basis to explore the market, the product and the solution space together.
One of the four main propositions of the Manifesto for Agile Software Development is “Customer collaboration over contract negotiation”. And then one principle behind the manifesto say: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” This notion of the customer unfortunately often leads to what Jeff Patton calls the customer-vendor anti-pattern. Especially in large organizations with their own IT departments, this pattern occurs when the Product Owner understands his role as a representative of internal customers and submits requirements to the Development Team for implementation. Understanding customers and their needs is important, but it is only one aspect to make a product successful and exactly that is the task of the product owner. In order to cover all aspects, the Product Owner must not be an ingenious and lonesome decision-maker and not be unilaterally associated with the business, but rather the leader of a team of experts who together take responsibility for the sustainable development of a successful product.
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.