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.


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


Beliebte Posts aus diesem Blog

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

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.

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.

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.

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.

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.

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?

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.

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt?