Scrum — eine Revolution (6)

Scrum in Organisationen
Die Ideen die Scrum-Consultants über das Führen von Organisationen und großen Teams erarbeitet haben,  sind in den letzten beiden Jahren vermehrt, auch in deutschen Unternehmen angewandt und dabei erfolgreich eingesetzt worden. Einige Beispiele:

Da gibt es ein Unternehmen, dass ein „Programm“ durchführt in dem alle Entwickler, alle Business Analysts, einfach alle an einem Produkt arbeiten. Insgesamt mehr als 120 Mitarbeiter. Hier habe ich erfolgreich die Sprint Planning Meeting mit allen 120 Teammitgliedern in einem Raum durchgeführt. Bereits nach dem ersten Mal, waren alle Beteiligten mit dem Ergebnis so zufrieden, dass sich die Stimmung im Projekt verbesserte und das Meeting in dieser Form bis heute weiter geführt worden ist.
Nach ersten Schwierigkeiten, die bei der Größe dieses Projektes unweigerlich sind, ist dort auch das Konzept des Product-Owner Teams erfolgreich eingesetzt worden. Es hatte bei der Größe und Problematik des Projektes einige Zeit gedauert und viel Überzeugungsarbeit seitens des Managements, aber am Ende würde deutlich, dass dieses Team und das Product Owner Daily Scrum, die beste Form zum Managen dieses riesigen Projektes darstellte. Besonders gefreut hat mich, vor ein paar Wochen zu erfahren, dass man mittlerweile auf die zuvor eingeführten elektronischen Tools verzichtet: Das Storyboard liefert alle Informationen, die benötigt werden.

Ein anderes Unternehmen hat sich auf die radikale Umgestaltung des Software Lieferprozesses eingelassen. Wir haben in nur zwei Wochen Vorbereitungszeit ein Produkt Backlog für die gesamte Organisation erstellt. Nach etwa zwei Stunden gemeinsames Arbeiten wurden circa 160 Backlog Items identifiziert. Diese wurden dann in zwei weiteren Sitzungen á 1 Stunde priorisiert und geschätzt. Das Top-Management nahm danach noch einmal  Einfluss darauf und der erste Sprint wurde on-time um 09:00 Uhr morgens mit 6 cross-funktionalen Teams, 6 Product Owner und circa 40 eingebrachten Backlog Items gestartet. Das Sprint Planning dauerte genau 2 x 3 Stunden und alle gingen hoch motiviert in ihren ersten Sprint. Dieser war dann so erfolgreich, wie ich es erwartet hatte: Es gab keine offenen „Defects“, alles Vereinbarte wurde geliefert und ausnahmslos alle im Unternehmen waren zufrieden.

Aber damit war die Arbeit nicht abgeschlossen. Mit den Product Ownern zum Beispiel daran gearbeitet, dass die Product Backlog Items sprechender werden. Wir wollten erreichen, dass die Teams in Zukunft mit  User Stories konfrontiert werden. Wir wollten die Funktionalität als solche darstellen und jegliche Designaspekte herauslassen.

Daneben, war hier die Aufgabe, das Top-Management und das Mittlere Management so auf ihre neuen Aufgaben vorzubereiten und deren Tätigkeiten umzudefinieren, dass sie die Teams optimal unterstützen.
So wurde u.a. Aus den Teamleitern „Domainleads.“ Eine Namenskonvention, die ich von einem anderen Kunden übernommen hatte. Die Domainleads haben einerseits die Aufgabe die „Domain“ zu betreuen, also für die technologische Richtung der Firma zu sorgen und sie sind andererseits fachliche Führungskräfte, die die Karriere ihrer Mitarbeiter fördern. Sie sind fachliche Führungskräfte, ohne Managementaufgabe auf der täglichen Ebene. Sie steuern die strategische Ausrichtung des Unternehmens und sie stellen sicher, dass „ihre“ Mitarbeiter die notwendigen Skills haben oder entwickeln. Zusammen mit den ScrumMaster, die die Teams betreuen und sich darum kümmern, dass die Teams ihre Arbeit optimal bewältigen können, bilden die Domainleads den mittleren Management Level.
Die ScrumMaster organisieren sich als Team und die Domainleads selbst sind ebenfalls als Team organisiert. Die Produkte und Produktlinien werden durch die Product Owner vorangebracht und weiterentwickelt. Auch diese sind in einem Team, dem Product Owner Team organisiert.

Der Beweis ist also auch in Deutschland mittlerweile erbracht: Ganze Organisationen lassen sich nach den Prinzipien von Scrum steuern. Der Umbau zu einer Scrum-Organisaton ist jedoch nicht einfach, oder nebenbei zu erledigen. Sie benötigen tatsächlich Mitarbeiter, die sich diesem Ziel verschreiben und sie benötigen die Erfahrung eines Menschen, der das schon einmal gemacht hat. Meine Praxis zeigt mir immer wieder, dass vollkommen unnötige Fehler bei der Umgestaltung von Abteilungen oder Firmenbereichen gemacht werden.

Meist liegt es dann daran, dass nicht an die Möglichkeiten geglaubt werden, die entstehen, wenn man die Menschen einfach nur machen lässt:

Scrum ist nur ein Weg, der einem hilft einem Weg zu finden, die Dinge richtiger zu machen.

3 responses to “Scrum — eine Revolution (6)

  1. Stefan Schubert

    Wenn ich mir ansehe, wie viele Missverständnisse allein eine Scrum-Trainer-Firma durch unterschiedliche Aussagen zum selben Thema in einer mittelgroßen Firma erzeugt, bin ich schon sehr überrascht dass “ein anderes Unternehmen” (das genannte, das ja offenbar ähnlich groß oder größer ist) in so wenigen Wochen solche Erfolgsgeschichten erzeugt hat.

    Wir arbeiten seit ca. einem halben Jahr mit Scrum und die ganze Firma wird nach und nach infiziert – was gut ist. Allein, diese Reibungslosigkeit, dieses aalglatte wie man es hier liest, hatten wir nicht. Wir müssen immernoch viel und harte Überzeugungsarbeit leisten. Und wir diskutieren alle 10 Tage, zum Beispiel weil jeder Scrum-Trainer, den irgendeiner bei uns mal hatte, eine andere Theorie dazu vertrat, wie bzw. was man in Estimation-Meetings schätzt.
    Ein anderes Beispiel ist der Verzicht auf elektronische Hilfsmittel bei der Backlog-Priorisierung … schön wär’s. Aber im Moment sind wir damit völlig überfordert. Wahrscheinlich, weil wir nicht innerhalb von 2 Wochen Vorbereitungszeit in der Lage waren zu verstehen, wie man es denn dann richtig macht.

    Alles was ich sagen will: Ich lese diese Revolutions-Reihe mit Interesse, denke mir aber immer dabei: Es ist ja nur Marketing, er meint es ja nicht so😉

    Cheers
    Stefan

  2. Als Kommentar sowohl zu Boris Blogeintrag, als auch Stefans Kommentar kann ich nur sagen, dass alle Organisationen, in denen ich bisher Scrum eingeführt habe, so verschieden wie die Menschen sind, die darin arbeiten.

    Entsprechend unterschiedlich fallen die Erfolge und Probleme bei der Einführung von Scrum aus. Die Bandbreite meiner Scrum Coaching Aufträge geht hinsichtlich des Prodcut Backlog Setups von “Nach drei Tagen gemeinsamer Arbeit war Product Owner Team in der Lage, hervorragende User Stories ohne meine Hilfe zu schreiben” bis hin zu “nach einem Jahr wiederholtem Coaching wurde von Prodcut Owner Team noch immer nicht begriffen, welche Zutaten gute User Stories ausmachen” – und ich kann versichern, dass aus meinem Unternehmen keine widersprüchlichen Aussagen kommen😉

    Ergo gilt wie immer in Scrum und wie von Boris treffend am Ende seines Blogeintrags bemerkt: Probleme, die shon vorher bestehen, werden sichtbar gemacht. Der Unterschied besteht dann letztlich darin, wie Organisationen mit diesen neuen Erkenntnissen umgehen: Ob sie Änderungen (sprich: ggf. auch personelle Veränderungen) zum Besseren aktiv herbeiführen oder lieber wegschauen und mehr oder weniger still weiterleiden.

  3. Stefan Schubert

    Wenn er das so explizit gesagt hätte. Wenn ich mit einem übereinstimme, dann: Scrum schafft Transparenz. Wie gesagt – wir müssen sehr hart daran arbeiten, das dann auch umzusetzen. Und zu einem Konsens zu kommen ist mühsam…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s