„Welche Spielräume haben Sie in Ihren Projekten, um auch mal andere Ansätze auszuprobieren und um bewusst neue, einfache Wege zu gehen? Inwieweit lassen Unternehmen den Projektleitern, Scrum Mastern und Product Ownern sowie Beratern freie Hand bei der Wahl des Vorgehens, in der Projektplanung, bei der Kommunikation oder bei der Art der Zusammenarbeit im Team (Stichwort Selbstorganisation)? Und mit welchen Ansätzen haben Sie Erfolg?“ Das fragt das Projektmagazin in der neusten Blogparade mit dem Thema „Mehr Erfolg durch neue Freiheiten im Projekt“.

Ich beteilige mich gerne an dieser Blogparade und beantworte die gestellten Fragen aus meiner Sicht. Ich bin Teil eines Teams (mit 5 Personen), welches für einen Großkunden Infrastrukturdienstleistungen erbringt. Das Produkt ist dabei eine Mischung aus Hard- und Software wie bspw. ein Auto, Flugzeug oder ein ICE. Damit der Kunde anonym bleibt, gehe ich auf das Produkt nicht näher ein. Wichtig ist, dass ein Produkt hergestellt wird (Hardware), welches über IT-Infrastruktur mit diversen IT-Systemen kommuniziert und spezielle Use-Cases für den Nutzer abbildet. „Ein Use-Case ist ein Anwendungsfall und bündelt alle möglichen Szenarien, die eintreten können, wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein bestimmtes fachliches Ziel zu erreichen“ (Quelle: Wikipedia).

Ausgangssituation

Eines Tages verlangte unser Kunde, dass wir im Projekt ab sofort agiler arbeiten und die verschiedenen Dienstleister stärker vernetzt werden. Er schlug uns dafür die Methode Scrum of Scrums vor. Die Idee war, dass wir einerseits mit der gleichen Software arbeiten (Jira – Software zur Vorgangs- und Projektverfolgung) und andererseits uns regelmäßig dienstleisterübergreifend austauschen. Wir sind insgesamt vier Dienstleister im Projekt, welche bis vor 12 Monaten noch eher nebeneinander statt miteinander gearbeitet haben:

  • IT-Infrastruktur Dienstleister (wir)
  • IT-Softwaredienstleister
  • Hardwarehersteller
  • Business-Consulting

Scrum of Scrums: kurz und knapp

Die Methode hinter Scrum of Scrums habe ich bereits ausführlich in meinem Artikel zur Skalierung von Scrum beschrieben und werde sie daher an dieser Stelle nur kurz skizzieren: Der einfachste Ansatz zur Skalierung von Scrum ist Scrum of Scrums. Stellen Sie sich ein Projekt mit sechs Teams vor. Jedes Team besteht wiederum aus 8 Teammitgliedern. Alle Teams halten ihr eigenes Daily Scrum Meeting ab. Anschließend bilden sich weitere (übergreifende) Scrum Teams, welche jeweils aus einem Vertreter der sechs Teams bestehen und sich wöchentlich treffen.

Scrum of Scrums in der Praxis

In unserem Projekt hat jeder Dienstleister sein eigenes Team, welches nach der klassischen Beauftragung des Kunden arbeitet. Dabei verwenden wir als Outsourcing Dienstleister unsere eigenen Tools und Arbeitsweisen. Früher haben wir uns direkt mit einem oder mehreren Ansprechpartnern des Kunden über die Aufgaben ausgetauscht. Durch das neue Scrum of Scrums arbeiten wir nun vernetzt agil und zusammen.

Scrum of Scrums in unserem Projekt

Zur Umsetzung haben wir im ersten Schritt gemeinsam analysiert: Wer muss mit wem eng zusammenarbeiten? Das erste Ergebnis war die Zusammenarbeit zwischen Hardware und Business-Consulting. Dies war wichtig, da speziell die Hardware nur schwer im Projektverlauf verändert werden kann und für eine Serienproduktion genauestens auf die Use-Cases der Fachabteilung abgestimmt werden muss. Inhaltlich dreht sich das Meeting dabei meist um das Fachkonzept.

Anschließend haben wir als Infrastruktur-Dienstleister die Aufgabe unsere Server und virtuellen Umgebungen an neue Hardware anzupassen. In diesem Zuge stimmt der Hardwarehersteller sich umfangreich mit uns in einem weiteren Meeting ab. Inhalt ist hierbei meist die technische Umsetzung von Use-Cases.

Zum Schluss gibt es eine weitere Abstimmungsrunde mit den IT-Software Dienstleistern, in welcher Software und Betriebsthemen abgeklärt werden (DevOps). DevOps ist ein Kunstwort aus den Begriffen Development und IT-Operations und bezeichnet einen Prozessverbesserungs-Ansatz. Damit Anforderungen nicht missverstanden werden, ist oft ein Vertreter aus dem Business Team ebenfalls beim Meeting anwesend. Eine Abstimmung zwischen Software und Hardware ist nicht notwendig, da wir die Umgebungen soweit virtualisiert haben, so dass es für den Softwarehersteller nicht wichtig ist, welche Hardware verwendet wird.

Aufgrund der Vertragssituation müssen Dienstleister vom Kunden weiterhin gesteuert werden. Aus diesem Grund hat jeder Kreis in der zweiten Ebene einen dedizierten Ansprechpartner des Kunden als Organisator und Scrum Master. Wir arbeiten dabei gemeinsam auf einen Jira Board des Kunden, welches sich mit unseren internen Ticketsystemen synchronisiert.

Übergreifend wird jede Woche ebenfalls ein Meeting in der Gesamtrunde durchgeführt. Dabei berichten die Vertreter des Kreises als auch ein Vertreter jedes Dienstleisters die Gesamtfortschritte und besprechen übergreifende Fragen. Alle Ansprechpartner und Entscheider des Kunden sind ebenfalls zu diesem wöchentlichen Meeting eingeladen. Zentrales Element ist ein Jira Board mit Epics damit jeder einen schnellen Überblick erhalten kann. Eine Epic ist kurz gesagt eine große Aufgabe (z.B. Einrichtung eines Webshops), die in weitere Unteraufgaben (Sicherung einer Domain, Installation eines Webshopsystems, etc.) strukturiert wird.

Implikationen für Zusammenarbeit und Erfolg

Durch diese neue Arbeitsweise hat sich speziell die Zusammenarbeit in komplexen Produktfragen, welche nur von mehreren Experten bearbeitet werden kann, verbessert. Auch haben sich der Zusammenhalt und Spaß im Projekt stark erhöht sowie auch die Bindung zum Kunden als auch das Commitment zum Produkt. Um Richtlinien nicht zu verletzen, wird jedes Meeting sowie jeder Kreis durch einen speziellen Ansprechpartner des Kunden durchgeführt. Wir haben zur Etablierung der Arbeitsweise knapp ein Jahr gebraucht und hatten dabei immer die volle Unterstützung des Managements des Kunden.

Meiner Erfahrung nach sind Auftraggeber heutzutage nicht nur offen für neue Ansätze, sie kennen sich häufig sogar so gut aus und wissen was sie wollen, dass sie selbst den Auftragnehmer auffordern, bestimmte Methoden  zu nutzen. Welche Erfahren haben Sie gemacht? Beteiligten Sie sich gerne mit ihrer Erfahrung an der Blogparade!

Genderhinweis: Ich habe zur leichteren Lesbarkeit die männliche Form verwendet. Sofern keine explizite Unterscheidung getroffen wird, sind daher stets sowohl Frauen als auch Männer sowie Menschen jeder Herkunft und Nation gemeint. Lesen Sie mehr dazu.

Helfen Sie meinem Blog, vernetzen Sie sich oder arbeiten Sie mit mir

Sie können dem Blog helfen, indem Sie rechts in der Seitenleiste oder in der Mitte/Ende des Beitrags auf eine Werbeanzeige klicken. Das Forschungsprojekt erhält dadurch einen Euro.

Vernetzen Sie sich in jedem Fall auf Xing oder LinkedIn oder kontaktieren Sie mich direkt für einen Austausch, wenn Sie gleich mit mir ins Gespräch kommen wollen. Werfen Sie auch einen Blick in meine Buchvorschläge zur Digitalisierung, vielleicht wollen Sie mir auch ein Buch empfehlen?

Ich arbeite gerne mit Unternehmen zusammen. Sie können mich ebenfalls gerne bezüglich folgender Punkte anfragen:

Sie haben eigene, interessante Gedanken rund um die Themenwelt des Blogs und möchten diese in einem Gastartikel auf meinem Blog teilen? – Aber gerne!

Avatar
Autor

Externer Doktorand an der Universität Erlangen-Nürnberg am Lehrstuhl für IT-Management. Ich untersuche wie sinnvoll skalierte Agilität im Zuge des digitalen Wandels zur Zukunftsfähigkeit von Unternehmen beitragen kann. Neben der Promotion arbeite ich Vollzeit in einem Unternehmen.

Schreiben Sie einen Kommentar

*

Durch die weitere Nutzung der Seite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen