All posts filed under: Agile

The Prime Directive for Successful Retrospectives

Published by Marcus Raitner

Agility means adaptability. First and foremost with regard to the product being developed. Step by step, usable interim products are created, which help to explore the problem domain and the possible solutions. However, adaptability not only covers the product, but also the way the team works. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Among the Principles behind the Agile Manifesto this is one of the most important. Agility is therefore much more than just a method, but rather means taking responsibility for the product as well as the way people work together. However, especially the latter requires the right stance to be successful and not to end up in blaming. It is exactly this stance that Norman L. Kerth beautifully described as the Prime Directive in his book “Project Retrospectives: A Handbook for Team Reviews” (Amazon Affiliate Link).

No More Elephant Carpaccio!

Published by Marcus Raitner

How to eat an elephant? Exactly: In small slices. With this salami tactics you can master big tasks. Many recognize the iterative-incremental nature of agile methods like Scrum and therefore feel reminded of this elephant carpaccio — a fallacy which is based on the fundamental confusion of complicatedness and complexity.

No Agility Without Trust

Published by Marcus Raitner

Without a culture of trust, no agility. Cargo cult yes, but no agility. And without agility there is no chance of at least surviving digitalization, let alone benefiting from it. In an agile organization, responsible and empowered people can quickly make customer-oriented decisions in decentralized structures. This requires trust. They make these decisions in complex and uncertain environments, validate them through rapid implementation and learn particularly from failures. And that needs even more trust.

The Team, the Product and All the Rest

Published by Marcus Raitner

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.

The Customer-Vendor Anti-Pattern

Published by Marcus Raitner

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.