Posts tagged ‘Scrum’

Otto InnoDays 2016: Start einer Blogpost-Serie

Ich war bei den Otto InnoDays 2016 dabei. Auf Twitter konnte man die Veranstaltung unter dem Hashtag #innodays2016 verfolgen.

Dieser Blogpost ist der Auftakt einer kleinen Blogpost-Serie zu dem Thema. Ich habe mit Otto vereinbart, dass ich hier keine Lobhudelei betreibe und offen alles beschreiben darf. Ich darf insbesondere auch das benennen, was in meinen Augen besser gemacht werden kann (lediglich persönliche Beleidigungen darf ich hier nicht veröffentlichen – will ich auch gar nicht :-). Und mir ist Einiges aufgefallen, was besser gemacht werden kann. Das sollte aber nicht den Blick auf das trüben, was schon erreicht wurde. Im Vergleich mit ähnlichen Veranstaltungen in anderen Firmen waren die Otto InnoDays 2016 auf jeden Fall ganz vorne mit dabei. Und wenn ich dann bedenke, dass Otto ein Konzern mit über 4.000 Mitarbeitern und kein eBusiness-Unternehmen mit nur 200 Mitarbeitern ist, ziehe ich meinen Hut. Von den Otto InnoDays 2016 können sich viele vermeintlich agilere Unternehmen eine große Scheibe abschneiden.

Ich plane, in den nächsten Wochen die folgenden Themen in dieser Blogpost-Serie zu behandeln:

Teil 1: Warum ich zuerst skeptisch war und dann doch teilgenommen habe.

Als Otto in Person von Sabrina Hauptman mich fragte, ob ich teilnehmen wollte, war ich mir unsicher, wieviel mir das wirklich bringt. Schließlich hatte ich schon ähnliche Veranstaltungen besucht: Hackathon, FedEx Day und wie sie alle heißen. Was sollte hier jetzt so besonders interessant sein – außer dass das Format jetzt auch von Konzernen praktiziert wird?

Details…

Teil 2: Die Ziele und der Ablauf

Die InnoDays sollten zum Querdenken anregen und auch Platz für disruptive Ideen bieten. Die InnoDays erstreckten sich insgesamt über zwei Wochen. Es begann mit einer Aufwärmphase, gefolgt von der Ideengenerierung. Die Ideen wurden dann gefiltert (Abstimmung mit den Füßen) und die selektierten Ideen prototypisch umgesetzt. Die Ergebnisse wurden zum Abschluss vorgestellt und von einer Jury bewertet. Außerdem gibt es einen definierten Prozess, wie die „Sieger“ in den Roadmap-Planungsprozess eingespielt werden.

Details…

Teil 3: Der Kulturwandel

Der Otto-Konzern will sich modernisieren und fit für das digitale Zeitalter werden. Dazu sind im Bereich eCommerce in den letzten Jahren beachtliche Erfolge erzielt werden. Skaliertes Scrum mit mit einer auf Verticals basierenden System-Architektur stellt die technische Basis bereit, auf der Business Agility (um mal ein Buzz-Word zu benutzen) möglich wird.

Die InnoDays sind ein weiterer Schritt in Richtung einer auf agilen Werten beruhenden Unternehmenskultur. Bei den InnoDays habe ich erlebt, wo diese Schritte bereits mutig gegangen werden, aber auch wo alte Strukturen immer wieder hervorbrechen.

Details…

Teil 4: Die Projekte

Es wurden insgesamt 18 Projekte durchgeführt. Ich habe mir diese inhaltlich angesehen und nach verschiedenen Kriterien klassifiziert. Wieviele disruptive Ideen waren bei den Projekten wirklich dabei? Wieviele Projekte basierten auf spinnerten Ideen, die sich am Ende nicht umsetzen lassen würden? Welche Projekte sprechen neue Zielgruppen an und welche optimieren „nur“ den existierenden Service für die existierenden Kunden? Und woran liegt es, dass es so gekommen ist, wie es gekommen ist?

Details…

Teil 5: Die großen Filter

Bei den InnoDays wurden Ideen bzw. Projekte mehrfach gefiltert. Zuerst wurden die Ideen durch Abstimmung mit den Füßen gefiltert. Bei der Abschluss-Präsentation wurden die Sieger herausgefiltert. Diese gehen in einen Roadmap-Planungsprozess, in dem erneut gefiltert wird.

Dieses Vorgehen entspricht dem Stand der Kunst für solche Veranstaltungen. Allerdings ist der Ansatz aus meiner Sicht noch nicht optimal. Radikale Ideen sind in ihrer ersten Fassung fast immer Mist. Sie müssen durch verschiedene Köpfe wandern, dort verändert und mit anderen Ideen kombiniert werden. Dann können wirklich großartige Dinge entstehen. Der große Filter-Ansatz verhindert diesen Prozess und tendiert daher dazu, mittelmäßige Ideen Realität werden zu lassen. Das ist schon mal nicht so schlecht, weil immerhin die schlechten Ideen ausgesiebt werden. Es geht aber viel besser: Diverge & Merge ist leistungsfähiger als Diverge & Filter.

Details…

Teil 6: Ein paar Thesen

Aus den InnoDays können Otto und andere Unternehmen viel lernen – auch über die internen Prozesse und Strukturen. Ich habe dazu ein paar Thesen zusammengeschrieben. Vielleicht helfen diese, in der Zukumft noch bessere InnoDays zu gestalten.

Details…

Teil 7: Zusammenfassung

Think, Create, Learn: das war das Motto das Otto InnoDays 2016. Wie stellt sich die ganze Veranstaltung rückblickend vor dem Hintergrund dieses Mottos dar?

Details…

 

 

May 1, 2016 at 12:52 pm 7 comments

ASMM: Agile Scaling Maturity Model

During a presentation of our approach to scaling agile I constructed „Stefans Agile Scaling Maturity Model“ (SASMM, not trademarked) in an ad-hoc fashion: The number of scaling practices you don’t need. It was a joke but I think there might be something behind the curtain.

Let’s start with the Agile Scaling Cycle: We start with reducing dependencies between teams and with the outside context. Then we do some work and need to coordinate the remaining dependencies. During this work we generate insights and detect organizational impediments. These direct us during the further development of the company. The evolved structures and processes of the company give us additional options for reducing dependencies and we start a new loop through the Agile Scaling Cycle. The whole cycle is driven by the agile scaling principles (which are just the agile/lean principles reformulated for scaling; see http://scaledprinciples.org).

Bild

The trick here is to reduce dependencies to the point where coordination becomes dead simple. When we went through the Agile Scaling Cycle several times the company should be more mature, teams should be less dependent and in consequence we need very few coordination practices. Therefore the first formula to compute the scaling maturity on a scale from 0 to 10 (the higher the score more mature) could be:

ScalingMaturityLevel = 10/NumberOfCoordinationPractices

Of course some coordination practices are more agile than others. A dependency matrix is less agile than a shared Sprint Review. So we could weight the practices by the additional weight they put on the process. But that would be another blogpost and in the end I’m not convinced that maturity models are valuable.

April 9, 2014 at 10:28 am Leave a comment

Scrum: Just following the hype?

From time I meet people who say that their management introduced Scrum just because it is a hype. Honestly I doubt that. I have introduced Scrum and other agile approaches since 2000 into various companies and I have spoken to dozens (if not hundreds) of managers. And every manager was able to explain why he wanted Scrum/agile. Sometimes expectations were excessive but I have never met a manager who didn’t know why he wanted Scrum and just followed the hype blindly.

I think the misconception of the employees is caused by a communication fail. As George Bernard Shaw said:

The single biggest problem in communication is the illusion that it has taken place.

The managers know why they want Scrum and normally they even have communicated it:

  • once
  • in an email
  • hidden between a lot of other stuff

And that is just not enough to make a real change happen. Even if employees have read the message there is a lot of doubt:

  • Does the manager really know what Scrum is?
  • Would he really do what is necessary?
  • Was the message just ad-hoc and now there is another most-important thing?

Therefore managers should

  • communicate the intended change (together with the “why”) personally and face-2-face
  • renew the message continuously
  • model the wanted behavior themselves

 

February 26, 2014 at 12:15 pm Leave a comment

Agile Skalierung: eine Kollage

In diesem Blogpost versuche ich mal eine Sammlung der verschiedenen Sichtweisen auf das Thema agile Skalierung (also der Organisation von agiler Entwicklung, wenn mehr als ein Team notwendig ist).

Scaled Agile Framework™ (SAFe)

Das Methodenframework SAFe von Dean Leffingwell erfährt im Moment viel Beachtung und ist höchst umstritten:

Die deutschsprachigen SAFe-Protagonisten, mit denen ich selbst gesprochen haben, stimmen der o.g. Kritik interessanterweise im Wesentlichen zu. Sie argumentieren aber, dass SAFe trotzdem ein erster Schritt hin zu ein ganz klein wenig mehr Agilität sein kann, dass man SAFe sowieso nicht so implementieren würde, wie es beschrieben ist und dass man direkt nach der Implementierung damit anfangen müsste, es sofort zu ändern (überspitzt: wieder zu demontieren).

Ein SAFe-Trainer meinte, er sähe die größte Gefahr von SAFe darin, dass viele SAFe-Trainer und Coaches Agilität nicht verstanden hätten und daher keinen sinnvollen Einsatz von SAFe sicherstellen könnten. Wer sich tatsächlich für SAFe entscheidet, sollte also viel Aufwand darin stecken, den agilen Erfahrungshintergrund der Trainer/Coaches intensiv zu durchleuchten (das gilt natürlich generell für die Auswahl von Coaches/Trainern). (Vielleicht sollte man sogar prinzipiell immer jemanden mit an Board holen, der SAFe für Unsinn hält 🙂

Disziplined Agile Delivery (DAD)

DAD von Scott Ambler hat lange nicht die Aufmerksamkeit wie SAFe erreicht. Das erklärt vielleicht auch, warum es deutlich weniger Kritik dazu gibt.

Large Scale Scrum (LeSS)

LeSS von Craig Larman und Bas Vodde ist eigentlich gar keine echte eigene Methode, weil schlicht das Scrum-Framework für die Skalierung interpretiert wird.

Agility Path

Agility Path von scrum.org liefert im Gegensatz zu SAFe, DAD und LeSS keine Struktur für skalierte Agilität, sondern definiert den Prozess, wie man zu dieser Struktur kommt. Ähnlich wie SAFe und DAD ist es direkt kommerzialisiert.

Auch bei Agility Path könnte man diagnostizieren “im Westen nichts Neues”. Das, was Agility Path ausmacht, haben Ken Schwaber und andere agile Praktiker schon vor Jahren beschrieben. Man begleitet die Einführung und Ausbreitung von agil kontinuierlich und setzt dafür ebenfalls Inspect&Adapt ein (häufig bildet man ein Transitionsteam dafür).

Enterprise Transition Framework™ (ETF)

Das ETF von Agile42 scheint mir im Grunde fast identisch mit Agility Path zu sein. Vielleicht ist einer der Gründe für die Existenz, dass Agile42 die Scrum-Zertifizierungen der Scrum Alliance anbietet und ein Gegenpol zu Agility Path von der Konkurrenz-Zertifizierungsorganisation scrum.org schaffen wollte.

We don’t need no new methods

Und dann gibt es noch die Gruppe derjenigen, die meinen, dass man für agile Skalierung keine neuen Methoden braucht und schon gar keine mit Trademarks. Die Prinzipien, die wir für die agile Skalierung brauchen, kennen wir bereits seit Jahren. Die Praktiken für die Skalierung sollten schrittweise passend zum Unternehmen gefunden werden. Inspirieren sollte man sich bei der Suche nach geeigneten Praktiken von der Praxis (z.B. bei anderen Unternehmen) und nicht von Methoden. (Dieser Gruppe gehöre ich selbst an).

Was fehlt?

Wenn Ihr noch Ressourcen kennt, die das Bild vervollständigen, hinterlasst mir einen Kommentar zu diesem Artikel. Ich werde den Artikel dann ergänzen.

February 14, 2014 at 10:58 am Leave a comment

Agilität, Skalierung und Kundenbegeisterung

In vielen Fällen reicht es heute nicht mehr aus, mit nur einem kleinen agilen Team an einem Produkt zu arbeiten. Dann müssen mehrere Teams gemeinsam arbeiten. Für die Koordination wurden Frameworks/Methoden wie SAF oder DAD vorgeschlagen. Jetzt gibt es einen weiteren Vorschlag: man braucht gar kein zusätzliches Framework zur Skalierung. Stattdessen sollte man sich an den agilen Prinzipien orientieren und seinen eigenen Weg finden. Zusätzliche Praktiken zur Koordination werden situativ verwendet, wenn sie helfen, die Prinzipien besser umzusetzen. Eine Gruppe von agilen Experten (inkl. meiner Wenigkeit) hat diese Prinzipien zusammengeschrieben und unter http://scaledprinciples.org veröffentlicht. Wer die Prinzipien unterstützt, kann sich dort auch als “Unterstützer” aufführen lassen. Die Skalierungsprinzipien sind in diese Bereiche gruppiert:

  • Begeisterte Kunden
  • Zufriedene produktive Mitarbeiter
  • Globale Optimierung
  • Unterstützende Führung
  • Kontinuierliche Verbesserung

Markus Gärtner hat die Prinzipien zu globaler Optimierung in seinem Blog detaillierter beschrieben und kommentiert. Die Prinzipien zu zufriedenen produktiven Mitarbeitern hat Andreas Schliep detaillierter beschrieben und kommentiert. Ich möchte hier die Prinzipien rund um begeisterte Kunden etwas genauer betrachten:

Begeisterte Kunden sind der Garant für jedes Unternehmen, langfristig zu wachsen. Die Aufgabe der Produktentwicklung ist es, die Grundlage für dieses Wachstum zu schaffen.

Ich meine, dass für Unternehmen der Kundennutzen im Fokus stehen sollte und nicht das Geld. Ich bin (wie viele andere auch) davon überzeugt, dass begeisterte Kunden ein sehr verlässlicher Indikator für den langfristigen finanziellen Erfolg des Unternehmens sind. Ein starker finanzieller Fokus führt hingegen meist zu unzufriedenen Kunden (Qualität von Produkt und Service wird reduziert, um Kosten zu sparen) und damit langfristig zu finanziellen Einbußen. In diesem Kontext waren uns zwei Prinzipien wichtig:

  1. Definiere, was Wert bedeutet schafft
  2. Produziere kleine, lieferbare Inkremente

Definiere, was Wert bedeutet und schafft

Das gemeinsame Verständnis über die wertschöpfenden Elemente muss gerade in einer skalierten Produktorganisation bei allen Mitarbeitern vorhanden sein. Leitbilder helfen dabei, die strategischen Ziele zu erreichen. Ein klares Wertverständnis gibt gemeinsame Orientierung.

Bei der Entwicklung mit nur einem Team ist dieses Prinzip relativ leicht umgesetzt. Das Team arbeitet im direkten Kontakt mit der Business-Seite (Product Owner, Anwender, Kunden) und baut darüber sehr schnell ein Verständnis darüber auf, was die Kundenbedürfnisse sind und wie das entwickelte Produkt diese Bedürfnisse befriedigt. Dadurch steigt die Verbundenheit des Teams mit den Kunden, den Kundenbedürfnissen und dem Produkt. In der Folge bringt das Team selbst Ideen dazu ein, wie die Kunden durch aktuelle Technologien begeistert werden können. Bessere Produkte, begeisterte Kunden und nicht zuletzt zufriedenere Mitarbeiter sind die Folge. In skalierten Umfeldern besteht die Gefahr, dass zusätzliche Hierarchien für die Koordination der Teams eingeführt werden, die die Teams wieder stärker von den Kunden und der Wertschöpfung entfernen. Auch in skalierten Umfeldern sollte jedes Teammitglied wissen, ob und wie das Gesamtprodukt die Kunden begeistert und was der Beitrag des eigenen Teams dazu ist.

Produziere kleine, lieferbare Inkremente

Inkremente bauen aufeinander auf und beinhalten stets den Nutzen und die Funktionalität der vorherigen Inkremente. Daher eignen sie sich ausgezeichnet zur Herstellung und Messung von Mehrwert. Ein lieferbares Inkrement eines Produktes hat somit qualitativ alle Eigenschaften, die man zur Auslieferung braucht, wobei die Produktorganisation Stück für Stück die fehlenden funktionalen und nicht-funktionalen Eigenschaften ergänzt. Im Idealfall kann der Wert eines Inkrements sofort in Nutzen für den Kunden umgesetzt werden. Doch auch wenn das nicht möglich ist, bieten kleine, lieferbare Inkremente die Basis für die kontinuierliche Verbesserung des Produkts, sie minimieren Risiken und reduzieren Komplexität.

Scrum fordert auslieferbare Produktinkremente nach jedem Sprint – es darf keine offenen Restarbeiten an den Funktionalität dieses Inkrements geben. Dadurch werden Risiken effektiv minimiert und es entsteht Transparenz über die reale Leistungsfähigkeit des Teams. Außerdem können Produktinkremente bei Bedarf sofort durch Kunden benutzt werden. Die Time-2-Market reduziert sich. Dadurch wird Feedback aus dem Produktivbetrieb früher generiert und die Wertschöpfung durch das Produkt beginnt früher. In skalierten Umfeldern ist es deutlich anspruchsvoller, lieferbare Produktinkremente zum Sprintende fertig zu stellen. Schließlich müssen dafür die Beiträge aller Teams noch während des Sprints integriert werden. Trotzdem sollte man dieses Ziel auch in skalierten Umfeldern verfolgen. Risikominimierung ist schließlich in skalierten Umfeldern noch wichtiger als für ein einzelnes  Team (der potenzielle Schaden in einem Großprojekt ist einfach deutlich größer). Ich finde hier ein Toyota-Motto hilfreich: “Wenn etwas schwierig ist, mache es häufiger!” Dann wirst Du nämlich lernen, wie es einfacher gehen kann.

January 29, 2014 at 6:15 am 2 comments

Buchtipp: “Software in 30 Tagen”

Die beiden Scrum-“Erfinder” Ken Schwaber und Jeff Sutherland haben 2012 ihr erstes gemeinsames Buch mit dem Titel “Software in 30 Days” veröffentlicht. Ich habe das Buch ins Deutsche übertragen. Es trägt – wenig überraschend – den Titel “Software in 30 Tagen“. Das Buch richtet sich an Manager und will diese von Scrum überzeugen.

Holger Koschek hat bereits eine ausführliche Besprechung des Buches in seinem Blog veröffentlicht. Holger bemängelt Schwächen in der Übersetzung. Ich freue mich über konkrete Verbesserungsvorschläge für eine eventuelle zweite Auflage der deutschen Ausgabe: Einfach E-Mail an: stefan.roock AT it-agile.de (Oder: wer mir das Buch mit entsprechenden Annotationen zusendet, bekommt von mir ein frisches Exemplar zurück).

Ich möchte über Holgers Buch-Beschreibung hinaus auf ein paar Punkte hinweisen, die mir beim Übersetzen durch den Kopf gingen:

  1. Das Buch führt eine Reihe von interessanten Fallbeispielen an. So kann man z.B. lernen, wie es für Adobe möglich und sehr effektiv war, auch in einem Multi-Team-Setting in jedem Sprint vollständig integrierte auslieferbare Produktinkremente herzustellen.
  2. In den Fallbeispielen sind die Product Owner immer hochrangige Manager und nicht umgeschulte Business-Analysten, die zu vorgegebenen Features die Details aufschreiben. Ich habe über die Besetzung der Product-Owner-Rolle hier gebloggt.
  3. Die Sprints in den Fallbeispielen sind relativ lang (eher Monatssprint als 2-Wochen-Sprints). Das harmoniert meiner Meinung nach sehr gut mit der Besetzung der Product Owner-Rolle durch Top-Manager. Auch über die Sprint-Länge habe ich an anderer Stelle gebloggt.
  4. Zu den langen Sprints passt die Sichtweise auf Sprints als Investitionseinheit. Jeder Sprint soll einen positiven ROI (Return on Investment) haben und wenn der Product Owner nach dem ersten Sprint des Projekt beendet, soll er trotzdem ein Produkt haben, das er einsetzen kann und dessen Wert die Kosten des Sprints übersteigen.
  5. Wie Holger bereits schreibt, zieht sich das Thema empirisches Management als roter Faden durch das Buch. Ich denke, dass dem Aspekt des empirischen Managements in der Praxis immer noch zuwenig Aufmerksamkeit gewidmet wird. Eine Kurzeinführung in empirische Prozesskontrolle findet sich z.B. hier. Was das für die Scrum-Meetings bedeutet, habe ich in einem Blog-Post beschrieben.
  6. Im zweiten Teil des Buches geht es um verschiedene “Implementierungsweiten” von Scrum: Scrum auf Projektebene (Scrum PRN), Einrichtung einer dauerhaften Organisationseinheit zur Durchführung von Scrum-Projekten (Scrum Software Studio), Scrum für das ganze Unternehmen (Enterprise Scrum).
  7. Und zum Abschluss gibt es Hinweise, wie Scrum mit Scrum eingeführt werden kann.

Der erste Teil des Buches ist meiner Meinung nach eine für Manager verständliche Einführung in Scrum. Der zweite Teil des Buches kann auch für erfahrene Praktiker die eine oder andere Inspiration liefern.

January 5, 2014 at 7:31 pm Leave a comment

Shades of Scrum: Empirical Management Meetings

Ken Schwaber defines empirical process control (aka empirical management) as one of the pillars of Scrum. Empirical management means to recognize what is (reality) and to base decisions on facts. Empirical managements needs:

  • Transparency (we need to be able to see the facts and should not rely on things that aren’t provable)
  • Inspection (we have to evaluate and interpret the transparent facts)
  • Adaptation (we modify the plan according to the inspection)

The Sprint Review, the Sprint Retrospective and the Daily Scrum are empirical management meetings in Scrum. In the Sprint Retrospective for example we first create transparency about the way we work (the Gather Data phase) then we inspect what we have found (the Generate Insights phase) and then we adapt the way we work (the Decide What To Do phase).

Applying these three steps of empirical management to the Daily Scrum and Sprint Review meetings often is an interesting exercise since a lot of “Scrum” teams miss adaptation and sometimes even inspection. And it gets worse when teams use additional meetings like a Scrum of Scrums where there are no “by-the-book-checklists” around on how to do them. So they just pollute the meeting we status reports and don’t inspect and adapt.

When looking at a meeting I suggest discussing if it is an empirical management meeting. If it is I would design the meeting backwards with the end in mind. Who should adapt what? When we know that we can easily find out how to inspect and finally what transparency we need.

So here is my “checklist” for the design of an empirical management meeting:

  1. Define what you want to adapt in what way. (Adaptation)
  2. Find out what you need to learn in order to be able to adapt. (Inspection)
  3. Find out what you need transparency about to do the inspection. (Transparency)

If you want to adapt the release plan as the result of the Sprint Review we need to inspect velocity during the Sprint Review and would therefore check what features where implemented and count story points. If we want to adapt the Product Backlog with new ideas that would improve the product we would probably have customers at the Sprint Review and gather feedback and ideas from them.

November 26, 2013 at 12:58 pm 2 comments

Older Posts