Wollten Sie schon immer Scrum oder andere agile Praktiken einführen, nur um festzustellen, dass Ihre Organisation sie nicht annehmen würde? Früher musste man sich die Frage stellen: „Reicht es aus, individuelle Fähigkeiten anzuwenden, um sie agil zu machen?“

Ich habe lange darum gekämpft, Betriebsleiter zu werden und das Projektmanagement in eine funktionale (Silo-) Umgebung zu bringen. Ursprünglich bestand meine Kernaufgabe darin, Mitarbeiter in der IT zu managen, einschließlich Anwendungsentwicklung, Helpdesk und Infrastrukturteams.

In den letzten Jahren haben sich viele Unternehmen zusammen mit der Wirtschaft stark verändert. In diesem Fall ging die Anzahl der Mitarbeiter zurück, die Anforderungen an aktuelle Anwendungen und Infrastruktur blieben gleich, und die Nachfrage nach neuen und aktualisierten Anwendungen stieg. Um es kurz zu machen, ich war etwas verwirrt. Außerdem wird übersehen, dass während des Downsizing zusätzliche Aufgaben für IT-Mitarbeiter aufgrund von Anfragen aus der Benutzergemeinschaft anfallen, um zusätzliche Arbeit in den Bereichen Sicherheit, Asset Management und ihren eigenen Funktionsbereichen zu leisten.

Das Unternehmen wollte „zu den Grundlagen zurückkehren“, aber es gab eine Gelegenheit, dieser Gruppe Agilität zu verleihen. Ich würde nicht behaupten, dass sie Scrum ohne geschäftliche Genehmigung durchführen, aber sie sind agil, während sie jetzt dem Scrum-Framework folgen.

In meiner Rolle als Scrum Master musste ich oft einige Ereignisse mit Kalendereinladungen überdecken und Meetings nach Scrum durchführen, sodass das Team den Eindruck erweckte, mit dem Product Owner zu arbeiten. Tatsächlich waren sie es. Diese Person passt in jedem Fall zum Profil des Product Owners, erhebt aber nicht den Anspruch, Zeit für den eigentlichen Prozess zu haben. Sie erlauben mir, fortzufahren, weil sie in ihrem Kalender in der Besprechung erscheinen und es so aussieht, als wäre es meine.

Das Sprint-Planungsmeeting trägt keinen Titel. Der Product Owner schließt sich dem Rest des Teams in einem offenen Arbeitsbereich an, der mit Aufgabentafeln, mit Markern markierten Whiteboards, Postern und Karteikarten gefüllt ist. Er/Sie überprüft die Bedürfnisse von ihnen und ihren Stakeholdern (nicht überraschend nennen wir sie Kollegen und Kunden), und wir verwandeln sie in Geschichten und priorisieren sie. Nachdem alle diese Punkte besprochen wurden, wird die Arbeit in die nächsten zwei Wochen verschoben und das Team kann daran arbeiten.

Inzwischen machen wir jeden Tag unseren Stand-up und versuchen, es frei zu halten, damit das Team weitermachen kann. Eine weitere Einladung an Product Owner, sich mit Stakeholdern zu zeigen, um zu sehen, was ihr Team aufgebaut hat. Wenn die Gruppe uns Feedback gibt und geht, schließen wir mit einer Retrospektive ab und fangen von vorne an. Nach einigen Iterationen festigte sich das Team, und der Abteilungsleiter war froh, wieder einmal bekommen zu haben, was er wollte.

Jetzt, wo die Ergebnisse vorliegen, werden sie das akzeptieren wollen? Nein für diese Firma. Als Scrum-Experte konnte ich jedoch mithilfe von Agile Coaching-Techniken Effizienzen schaffen. Ja, manchmal reicht das.

Natürlich gab es in den letzten Jahren keine Upgrades und keine Standardisierung, was dazu geführt hat, dass unterbesetzte Helpdesks und Infrastrukturteams gestresst und überarbeitet sind. Von geschlossenen Einrichtungen bis hin zu bandagierten Computern, Server- und Netzwerkausfällen blieben die Probleme bestehen. Ich erwartete, dass mehrmals am Tag Anfragen hereinkamen und den Gang wechselten.

Da diese Organisation immer noch behauptete, funktional zu sein, nutzten sie sie, um Vorschläge zu machen, wie funktionale Bereiche in Zukunft funktionieren könnten. Das neu gebildete Team griff Teile des Scrum-Frameworks um sich herum auf und beschleunigte die Details. Erinnerst du dich an den Raum mit all den Whiteboards und so? Wir haben eines verwendet, um ein Kanban-Board zu erstellen und Scrum-Techniken anzuwenden.

Das Team begann, sich zu treffen und alle außer Routineaufgaben und Trouble-Tickets aufzuzeichnen. All diese Arbeit wurde für jeden, der es sehen möchte, an Bord gebracht.

Wir haben jedem eine Komplexität zugewiesen und da es der erste Lauf war, haben wir die Kapazität für den ersten Sprint geschätzt. Wir haben die Direktoren der Funktionsbereiche als Product Owner des Unternehmens eingesetzt, um zu priorisieren, was getan werden muss, bis es keinen Raum mehr für mehr Komplexität gibt. In diesem Fall wurde das Team zu einer bestimmten Menge an Arbeit verpflichtet, nicht unbedingt die Arbeit selbst. Als die Ad-hoc-Anfrage einging, behielt der Direktor die Möglichkeit, laufende Arbeiten zu zerstören, indem er ihr sogar mitten in einem Sprint eine höhere Priorität gab, aber dann musste er eine gleiche oder größere Menge an Komplexitätspunkten entfernen, und er beantwortete die folgenden Fragen: Geschäft, warum dieses Produkt erst im nächsten Sprint geliefert wird.