Direkt zum Hauptbereich

Why „Hybrid Agile“ is not Agile at all.

A couple of years ago, I got a call from a project manager. He wanted to introduce Scrum to his team. The company wanted to introduce a new internal software, therefore they wanted to use Scrum.

My first question was: Why do you want to use Scrum? He answered, that they needed faster feedback. And that they don’t have time to wait, they needed to start immediately. Ok, I said. Let’s go.

Welcome to another "crash & burn" story.

There are probably many ways to start with Scrum. I’d like to highlight briefly two:

A) You prepare thoroughly. An Agile Coach starts training and coaching the Product Owner, clarifying the product vision, goals, success metrics, road map, personas. It always depends on how much time & the experience the new Product Owner has. At the same time the new Scrum Master receives coaching: What does it mean to be a Scrum Master? How does Scrum work? What does self-organization or self-managing teams mean? What’s different from being a project manager?

This coaching might take some weeks, depending on the availability of the people. The Product Owner also creates some artifacts along the way, to sharpen his or her own (hopefully passionate) vision of the product. Maybe there also needs to be more clarification with stakeholders within in the organization.

When the right people for the Scrum teams are found, there’s typically a vision & product backlog refinement & working agreement workshop. The people decide on the Sprint cadence, and off they go.

This approach is very useful, when organizations have a little bit trouble with openness and their ability to learn. The initial disruption is low, when they start sprinting, because everything is well prepared.

B) Another approach would be: The product vision & goals are clarified first, then it needs to be decided, who needs to be on the Scrum team. A vision & product backlog refinement & working agreement workshop is scheduled and they just start. They use their Daily Scrums and Sprint Retrospectives to adjust. The disruption might be higher, because there is so much to learn in the beginning: How to be a Product Owner, Scrum Master. How to avoid old micromanaging habits. How to use the events effectively. Typically, this requires the support of an experienced Agile coach. It also requires the openness of everybody to reflect and learn.

I tend to like this approach a bit more. The roots of Scrum are described in the paper „The New New Product Development Game“ (/1/). The authors describe a „Built-In Instability“ characteristic: A broad, extremely challenging goal or a general direction is signaled without handing out clear-cut concepts. Wide measures of freedom are offered to the teams.

This freedom is a precondition for self-organizing teams. If there was no freedom, the teams don’t self-organize. Why should they? If everything is arranged for them, like it is typically done in many organizations to avoid a disruption, there is no need to change behavior. Hence, there will be no more active participation by the team members.

The „built-in instability“ forces everybody to engage. It is a bit more exhausting in the beginning, but Daily Scrums and Sprint Retrospectives are properly used to establish a learning habit. The tension creates more creativity. The product is also more innovative. Isn’t that the reason why so many organizations try Scrum?

Both approaches work way better, when the participants volunteer for using Scrum.

Back to the project: Since they wanted to start immediately, they decided to use the second approach. We did a Scrum training for the Scrum Master & Product Owner, some workshops about the product vision, the risks, the team setup. Some working agreements about the scheduling and flow of the events.

Just enough Product Backlog was prepared. The Sprint Planning was running and then - they stopped. They prohibited the active involvement of an Agile coach. They kept sprinting, but they demanded, that the coach should watch the events and could give feedback after the events. Or some notes about the preparation of the next events, which were moderated by the new and unexperienced Scrum Master.

Here’s why: The Product Owner, the project manager who contacted me, had the scope already in his mind. Reducing scope or finding out which features were necessary and which were obsolete, was no option for him. It wasn’t the feedback of the end users, which was important for him. He needed the feedback of some future users from different departments of the organization, who were now part of the team. He just wanted them to answer many design questions. These were the increments in the Sprint: answered questions by the team about the design. No working product or software at the end of the Sprint.

Their project plan, which was set up in advance, included some weeks of getting the design done, then a few weeks of implementation, then some weeks of testing. The one and only goal for them was to meet the deadline.

They were quite effective in getting the design done. They even improved, because they had a dedicated team in the first time of the history of the project and they got feedback about the progress every day.

The feedback sessions with the Agile coaches got shortened or canceled pretty soon. It become harder to give feedback. The Product Owner and Scrum Master were open for minor changes and tactical improvements. But they refused to change fundamentally. In one conversation, the last one, one said, they rather would do „hybrid agile“ instead of doing full Scrum.

Hybrid Agile?

What does „Hybrid Agile“ mean? Typically, you take some parts of traditional project management and combine it with Agile tools. For example, you gather all requirements, then you use Scrum for the implementation, then you do a separate testing phase.

Is this a bad thing?

Well, first, there is no „Hybrid Agile“. In an Agile approach, we value a „working product“ or „working software“ over „comprehensive documentation“. If you continuously have no working product, you’re not Agile. The word „Agile“ should not be in the term „hybrid Agile“. Better call it „NOT agile“.

Besides, why? What are the reasons, to introduce this „hybrid model“? Maybe because there are some internal impediments in the organization, that prohibit being Agile. But what is the value of this? You live with these impediments and therefore they never go away. What will be the longterm consequences, if an organization doesn’t face their impediments?

In the above example there was no necessary reason to use a „hybrid“ approach. It was just, that the Product Owner and functional manager, who micromanaged the team, enjoyed this way of working.

At the end, the organization decided to cancel the coaching for this team. The organization wanted to become more Agile and this team was using Scrum in such a wrong way, that it could scare off others from doing Scrum.

Notes:

  • /1/ The New New Product Development Game: https://hbr.org/1986/01/the-new-new-product-development-game

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.