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

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

Optimieren wir uns zu Tode?

Als jemand, der mehr als fünfzehn Jahre in der Welt des IT-Service-Management-Prozessmanagements verbracht hat, musste ich das Buch von Guther Dueck aus dem Jahr 2020 Heute schon einen Prozess optimiert? Das Management frisst seine Mitarbeiter lesen/1/. Typisch für ihn bietet Dueck uns einen provokanten, teils vernichtenden, jedoch humorvoll geschriebener Weckruf. Er behauptet, dass das moderne Management von “Pacesetters” und “Controllers” dominiert wird. Sie sind so sehr auf Optimierung und Profit fokussiert, dass sie den Willen zu Innovation und Unternehmertum abtöten. Jedoch ohne mehr Kreativität und Tatkraft werden wir die Herausforderungen der Digitalisierung, des Klimawandels etc. nicht bewältigen. Ein agiles Mindset kann helfen.

Projekt-Kick Off – Wie Du einen Auftakt gestaltest, der alle Kräfte freisetzt!

Ein typisches Szenario:  Zum Auftakt wird das neue Projekt vom Verantwortlichen vorgestellt. Die vorbereitete PowerPoint-Präsentation zeigt in bunten Bildern, welche Traumschlösser vom Team umgesetzt werden sollen. Doch statt der erhofften Aufbruchsstimmung macht sich Widerstand breit. Diskussionen kommen auf. Das Kickoff-Meeting wird zur Bühne der Lauten. Miese Stimmung macht sich breit. Die Lauten werden lauter, die Stillen werden leiser.  Kommt Dir das bekannt vor? Häufig werde ich gefragt: "Maria - wie sieht das in der Praxis aus? Wie gestalte ich als Moderator ein strukturiertes Meeting?". In diesem Artikel stelle ich Dir EINEN alternativen Ablauf einer Kickoff-Veranstaltung in fünf Schritten vor. Ein Gestaltungsvorschlag, der Impulse und Mut zum Experimentieren neuer Formate bieten soll.  Was es ermöglicht: Förderung des Projekterfolg Frühes gemeinsames Verständnis des Projekts Missverständnissen wird vorgebeugt Es werden hilfreich Hinweise sichtbar, WIE d

Agiles Mindset – Gibt es das überhaupt? Eine wissenschaftliche Perspektive

Es ist in aller Munde: Das Agile Mindset. Es wird als wichtiger Erfolgsfaktor und gleichzeitig riesige Hürde und Herausforderung in agilen Transformationsvorhaben beschrieben. Der ein und andere hat verbunden mit einem gescheiterten agilen Vorhaben vermutlich schon mal gehört „Die hatten einfach nicht das richtige Mindset“. Doch was ist dieses agile Mindset? Gibt es das überhaupt?