© Ekaphon maneechot/Shutterstock.com
Business Technology Magazin
Hybridisierung klassisch vs. agil - Handlungsoptionen identifizieren

Wenn agile Gehversuche scheitern

Jahrelang bestimmte klassisches Projektmanagement den Alltag und das Denken in Unternehmen. Ganz plötzlich und fast wie von allein sollen agile Ansätze wie Scrum oder Kanban gleich einem Allheilmittel alles anders und am besten sofort erfolgreicher machen. Allerdings widerspricht das dem Grundprinzip von Agilität. Sie lebt von Inspect and Adapt und dem kontinuierlichen, iterativen Anpassen, ohne dabei das Bestehende aus den Augen zu verlieren. Es geht dabei nicht um einen faulen Kompromiss. Jedoch gilt es, auf dem Weg hin zu agilem Projektmanagement Hybridität zuzulassen, damit der für Ihre Firma passende Agilitätsgrad entwickelt werden kann, ohne sich dabei selber zu überholen.

Jörn Grapp


In zahlreichen Workshops und Kundengesprächen oder grundsätzlichen Diskussionen zur Agilität kommt es oft zu folgenden Aussagen:

Bezüglich der Organisation: „Von komplett agil mit allen Meetings, Artefakten etc. bis hin zu durchgetaktet klassischen Unternehmensstrukturen mit Lenkungskreisen, Sitzungen etc. – alles Chaos!“ Bezüglich der Prozesse: „Wir haben wirklich schon viele Ansätze ausprobiert, aber wenn die Kollegen nicht mitziehen wollen oder ihr Handwerk nicht beherrschen, dann bleibt alles Theorie!“Bezüglich der Methoden: „Ich habe über fünfundzwanzig Jahre Erfahrung im Projektmanagement und entsprechend viele Methoden kommen und gehen sehen – nichts funktioniert richtig!“

Solche Klagen finden sich in allen Branchen, nicht zuletzt sogar in der agilen Softwareentwicklung, der Geburtsstätte des Scrum-Gedankens. Dies erscheint umso erstaunlicher, da doch alle Regeln genau für die Akteure des IT-Umfelds mit der bei Entwicklungsprojekten charakteristischen Komplexität entworfen wurden.

Dazu wird an dieser Stelle das abstrahierte Beispiel eines fiktiven Unternehmens mit ca. hundert Mitarbeitern skizziert. Es entwickelt seit zwanzig Jahren Software und hat nach einer zunächst klassisch-hierarchischen Ausrichtung mit Geschäftsführern, Stabsstellen, Bereichsleitern und Teamleitern von Entwicklungsteams eine Reorganisation hin zu Scrum umgesetzt. Es gibt in etwa doppelt so viele Scrum-Teams wie Scrum Master. Ein Scrum Master kümmert sich folglich um zwei Scrum-Teams oder mehr. Dabei gibt es jedoch teilweise zwei oder mehrere Product Owner (PO) je Scrum-Team. Das bedeutet, dass diese weiteren Product Owner Experten für jeweils eines oder mehrere Produkte sind und den hauptverantwortlichen PO unterstützen. Diese Strukturen sind über mehrere Jahre gewachsen und haben sich stark verfestigt, teils auch über die gesamte Zeit mit den gleichen Mitarbeitern. Warum performen die Teams jedoch nicht ausreichend und halten ihre Commitments nicht ein (= schwankende Velocity)? In dem oben beschriebenen, organisatorischen Gebilde gibt es diverse Probleme. Beispielsweise bearbeitet ein Team viele verschiedene Themen, Produkte oder Komponenten, und ein Scrum Master kann nicht durchgehend in beiden Teams anwesend sein. Daneben kann es vorkommen, dass Impediments nicht rechtzeitig oder gar nicht erkannt werden. Auch unterschiedliche Teamgrößen von unter fünf bis über zehn Personen sowie fehlende oder unzureichende Vertretungsregelungen können sich negativ auswirken. Ein weiteres...

Business Technology Magazin
Hybridisierung klassisch vs. agil - Handlungsoptionen identifizieren

Wenn agile Gehversuche scheitern

Jahrelang bestimmte klassisches Projektmanagement den Alltag und das Denken in Unternehmen. Ganz plötzlich und fast wie von allein sollen agile Ansätze wie Scrum oder Kanban gleich einem Allheilmittel alles anders und am besten sofort erfolgreicher machen. Allerdings widerspricht das dem Grundprinzip von Agilität. Sie lebt von Inspect and Adapt und dem kontinuierlichen, iterativen Anpassen, ohne dabei das Bestehende aus den Augen zu verlieren. Es geht dabei nicht um einen faulen Kompromiss. Jedoch gilt es, auf dem Weg hin zu agilem Projektmanagement Hybridität zuzulassen, damit der für Ihre Firma passende Agilitätsgrad entwickelt werden kann, ohne sich dabei selber zu überholen.

Jörn Grapp


In zahlreichen Workshops und Kundengesprächen oder grundsätzlichen Diskussionen zur Agilität kommt es oft zu folgenden Aussagen:

Bezüglich der Organisation: „Von komplett agil mit allen Meetings, Artefakten etc. bis hin zu durchgetaktet klassischen Unternehmensstrukturen mit Lenkungskreisen, Sitzungen etc. – alles Chaos!“ Bezüglich der Prozesse: „Wir haben wirklich schon viele Ansätze ausprobiert, aber wenn die Kollegen nicht mitziehen wollen oder ihr Handwerk nicht beherrschen, dann bleibt alles Theorie!“Bezüglich der Methoden: „Ich habe über fünfundzwanzig Jahre Erfahrung im Projektmanagement und entsprechend viele Methoden kommen und gehen sehen – nichts funktioniert richtig!“

Solche Klagen finden sich in allen Branchen, nicht zuletzt sogar in der agilen Softwareentwicklung, der Geburtsstätte des Scrum-Gedankens. Dies erscheint umso erstaunlicher, da doch alle Regeln genau für die Akteure des IT-Umfelds mit der bei Entwicklungsprojekten charakteristischen Komplexität entworfen wurden.

Dazu wird an dieser Stelle das abstrahierte Beispiel eines fiktiven Unternehmens mit ca. hundert Mitarbeitern skizziert. Es entwickelt seit zwanzig Jahren Software und hat nach einer zunächst klassisch-hierarchischen Ausrichtung mit Geschäftsführern, Stabsstellen, Bereichsleitern und Teamleitern von Entwicklungsteams eine Reorganisation hin zu Scrum umgesetzt. Es gibt in etwa doppelt so viele Scrum-Teams wie Scrum Master. Ein Scrum Master kümmert sich folglich um zwei Scrum-Teams oder mehr. Dabei gibt es jedoch teilweise zwei oder mehrere Product Owner (PO) je Scrum-Team. Das bedeutet, dass diese weiteren Product Owner Experten für jeweils eines oder mehrere Produkte sind und den hauptverantwortlichen PO unterstützen. Diese Strukturen sind über mehrere Jahre gewachsen und haben sich stark verfestigt, teils auch über die gesamte Zeit mit den gleichen Mitarbeitern. Warum performen die Teams jedoch nicht ausreichend und halten ihre Commitments nicht ein (= schwankende Velocity)? In dem oben beschriebenen, organisatorischen Gebilde gibt es diverse Probleme. Beispielsweise bearbeitet ein Team viele verschiedene Themen, Produkte oder Komponenten, und ein Scrum Master kann nicht durchgehend in beiden Teams anwesend sein. Daneben kann es vorkommen, dass Impediments nicht rechtzeitig oder gar nicht erkannt werden. Auch unterschiedliche Teamgrößen von unter fünf bis über zehn Personen sowie fehlende oder unzureichende Vertretungsregelungen können sich negativ auswirken. Ein weiteres...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang