Jeff und Ken über den neuen Scrum Guide 2016

Nach mehreren Jahren wurde der offizielle Scrum Guide aktualisiert. Die aktuelle Fassung ist hier verfügbar:

Eine wichtige Änderung im Scrum Guide 2016 sind die explizit aufgeführten Scrum Values:

  • Courage
  • Focus
  • Commitment
  • Respect
  • Openess

Die Bedeutung dieser Werte wurde/wird systematisch unterschätzt (vgl. auch Gründungstreffen der Scrum User Group Karlsruhe, 2009). Die Werte sind Teil einer Kultur, die viele kritische Aspekte von Scrum kompensiert.

Ein Beispiel hierfür ist, dass in vielen Scrum Teams sehr respektlos über nicht agilen Unternehmensteile geredet wird, obwohl diese häufig mittelfristig die tragenden Säulen der sich ändernden Organisation sind und viele gute Mitarbeiter dort ihr Bestes tun, damit die Organisation erfolgreich ist. Hier ist ein respektvoller Umgang miteinander Grundlage, um gemeinsam zu lernen und gemeinsam die Organisation weiter zu verbessern.

Wie Ken es schön zusammenfasst: Lebt man diese Werte, dann ist Scrum „ein Ort an dem Du leben möchtest“, ohne diese Werte sei Scrum „ein Ort, an dem Du nicht unbedingt sein möchtest“.

Spannend ist die Diskussion rund um den Wert „Commitment“. Ein Scrum Team „versucht nicht sein Bestes“ sondern es commitet sich auf die Dinge die im Sprint Planning als Ziel besprochen werden. Wichtig ist jedoch auch das Commitment über den Sprint hinaus – eine Verpflichtung auf die Organisation und die Zielsetzung des Vorhabens als solches. Hierzu gibt/gab es in der Vergangenheit immer wieder auch Verwirrungen.

Ein weiterer Punkt der neu aufgenommen wurde ist, dass Sprint Ziele nun Teil des Scrum Guides sind. Die bisher empfohlene Praxis ist damit zu einem „Muss“ geworden.

Das Video in dem Jeff und Ken über den neuen Scrum Guide bzw. vor allem über die Scrum Values sprechen ist bei vimeo zu finden:

Scrum Guide Refresh (July 2016) from Scrum Inc. on Vimeo.

Bas Vodde zu Large-Scale Scrum (und SAFe)

Die Konferenz Adventures with Agile (AWA) fand vor kurzem in London statt. Einige interessant Vorträge sind via YouTube zugänglich, u.a. ein Vortrag von Donald Reinertsen sowie ein Vortrag von Bas Vodde, einem der beiden Autoren von LeSS.

Bas Vodde geht in seinem Vortrag auf die Entstehung und Grundsätze des Large-Scale Scrum (LeSS) ein. Personen die sich mit der Skalierbarkeit agiler Ansätze beschäftigen bekommen hierbei interessante Einblicke, wie LeSS bei Nokia Networks sich langsam herausgebildet hat.

Interessant ist, welche Grundzüge von LeSS Bas betont:

  • Bei der Produktentwicklung stets den Kunden bzw. den Kundennutzen im Auge behalten (customer centric whole product focus) und eben nicht abstrakte Prozesse- oder Systemlandschaften mit deren „Ownern“ befriedigen.
  • Die Bedeutung von Feature-Teams. Ohne Feature-Teams ist LeSS nicht möglich, da nur mit Feature-Teams Abhängigkeiten aufgelöst bzw. drastisch reduziert werden können.
  • Die Unterscheidung zwischen „Multi-Team Scrum“ (LeSS) und „Multiple Scrum-Team“ Ansätzen und die unterschiedliche Sichtweise auf die Skalierung von Scrum Praktiken.
  • Verlagerung von Verantwortung (und Entscheidungsbefugnissen) in das Team bzw. in die Teams. Damit geht einher, dass koordinierende Rollen abgeschafft werden. Für Koordination, Abstimmung und Klärung sind die Teams alleinig verantwortlich.
  • Der grundlegende Überzeugung „Less is More„: Durch konsequente Eliminierung von Prozesselementen (Rollen, Artefakte, Prozess-Schritten) wird Raum geschaffen für echte, für mehr Verbesserungen. Dahinter steckt das Zusammenspiel von übertragener Verantwortung und geschaffenem Gestaltungsspielraum durch konsequente Reduzierung von Vorgaben.

 

Im zweiten Teil wird „dem Elefanten im Raum“, dem Scaled Agile Framework (SAFe) einiges an Zeit eingeräumt. Bas erklärt, weshalb er Ansätze wie SAFe für schädlich für eine echte Agilisierung von Unternehmen hält. Im besten Fall wäre SAFe ein „workaround in a context where the real (hard) questions are not answered“. Hierbei bezieht er sich u.a. auf die Etablierung von Featureteams, die sich im Großen und Ganzen selbst organisieren können (Verantwortung übernehmen, Gestaltungsspielraum erhalten), was letztendlich dem Aufbrechen aller existierender Strukturen entspricht.

Diese Einschätzung wurde vor mehr als einem Jahr aus meinem LeSS Kurs auch durch Craig Larman vermittelt. Viele LeSS Praktiken oder Ideen können zunächst in einem „mäßigen“ Umfeld erfolgreich eingeführt werden. Ähnlich wie einer Scrum-Einführung im Kleinen, stößt man aber schnell an die Grenzen, falls die Trägerorganisation an ihren existierenden Strukturen und Rahmenbedingungen festhalten will.

Ein Muster, das sich übrigens auch in Larman’s Laws of Organizational Behavior wieder findet:

Larman’s Laws of Organizational Behaviour

  1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
  2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
  3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, „religion“, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
  4. Culture follows structure.

http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior

 

Scrum.org announces CIFScrum.org announces CIF

Kurzmitteilung

Finally the long awaited CIF (Continuous Improvement Framework) has been announced by Ken Schwaber / Scrum.org („Scale Scrum beyond your Team„).

A first overview has been made available to the public.

Time to cover CIF in our series about scaling Agile/Lean!Finally the long awaited CIF (Continuous Improvement Framework) has been announced by Ken Schwaber / Scrum.org („Scale Scrum beyond your Team„).

A first overview has been made available to the public.

Time to cover CIF in our series about scaling Agile/Lean!

Session über Agile@Scale auf dem PMCamp 2012Session über Agile@Scale auf dem PMCamp 2012

Ich hatte eine kleine Session zu Agile@Scale auf dem PM Camp 2012.

Ausgehend von der Fragestellung, warum Skalierung von Agilität eine Rolle spielt und was man darunter versteht haben wir gemeinsam verschiedene Ansätze diskutiert.

Ein Tweet von spacedani aus der ersten Hälfte:

Eine Betrachtung/Diskussion weiterführender Prozess-Frameworks für Agilität im Großen wie Disciplined Agile Delivery (DAD) oder Scaled Agile Framework (SAFe) konnte jedoch auf Grund der vielfältigen Grundsatzdiskussionen oder Beharren auf “Wahrheiten” nur bedingt erfolgen.

Hier der Tafelaufschrieb:

image

Neuer Anlauf: Eine Session (Panel / Fishbowl) auf der DeutscheScrum 2012 (15.-16.11.2012 in Darmstadt) und später auf der Agile Tour 2012 Germany (22. November in Stuttgart). Im Rahmen der Agile Tour gibt es auch das erste SAFe Meetup in Deutschland.

Eine Betrachtung/Diskussion weiterführender Prozess-Frameworks für Agilität im Großen wie Disciplined Agile Delivery (DAD) oder Scaled Agile Framework (SAFe) konnte jedoch auf Grund der vielfältigen Grundsatzdiskussionen oder Beharren auf “Wahrheiten” nur bedingt erfolgen.

Hier der Tafelaufschrieb:

image

Neuer Anlauf: Eine Session (Panel / Fishbowl) auf der DeutscheScrum 2012 (15.-16.11.2012 in Darmstadt) und später auf der Agile Tour 2012 Germany (22. November in Stuttgart). Im Rahmen der Agile Tour gibt es auch das erste SAFe Meetup in Deutschland.

Studien: Erfolg agiler Methoden (agile success rate)

Die Bedeutung agiler Methoden und Frameworks ist unbestreitbar: Was früher noch innovativ war dürfte heute als Stand der Technik angesehen werden. Selbst relativ veränderungsresistente Unternehmen der „late Majority“ versuchen sich mittlerweile daran ihre Prozesse zu agilisieren.

So hat nun mittlerweile nahezu jedes Unternehmen in irgendeiner Form Erfahrungen mit agilen Methoden gesammelt. Diese Erfahrungen sind nicht nur positiv, sondern weisen – wie einiger der hier vorgestellten Studien nahelegen – auch auf viele Herausforderungen hin, mit denen Unternehmen bei der Einführung von agilen Methoden zu kämpfen haben.

Ernüchternde Ergebnisse der Studie „Softwaretest in der Praxis“

Durch Diskussionen mit einem meiner Kunden bin ich auf die Studie „Softwaretest in der Praxis“ aufmerksam geworden. Die Studie wurde 2011 durchgeführt und die Ergebnisse (PDF) sind teilweise beunruhigend: Laut der Studie sind klassische Qualitätssicherungsmaßnahmen in der Praxis gleich gut oder besser als die praktizierten Maßnahmen in den meisten agilen Projekten.

Qualität als kritischer Erfolgsfaktor bei agilen Methoden (agile success rate)

In Projekten in denen agile Methoden / Frameworks genutzt werden, spielt die Qualität der erzeugten Artefakte jedoch eine sehr wichtige Rolle. Da häufig Zwischenartefakte / Mittler fehlen, muss sichergestellt sein, dass durchgängig hohe Qualität erzeugt wird.

Kurz: Qualität ist ein kritischer Erfolgsfaktor für agil durchgeführt Vorhaben und für agile Organisationen. Fehlende Qualität wird schnell zu einem Problem.

Die Studie „Softwaretest in der Praxis“ im Detail

Die Umfrage zum „Softwaretest in der Praxis“ hat aufgrund der außerordentlich hohen Beteiligung von Testern, Entwicklern und Managern praktisch repräsentativen Charakter:

  • fast 1100 Projektleiter, Qualitätsbeauftragte, Testmanager und Tester
  • fast 270 Entscheider und Manager
  • ca. 420 Business Analysten, Entwickler, Betriebsverantwortliche und andere
Die Bedeutung agiler Methoden und Frameworks ist unbestreitbar: Was früher noch innovativ war dürfte heute als Stand der Technik angesehen werden. Selbst relativ veränderungsresistente Unternehmen der „late Majority“ versuchen sich mittlerweile daran ihre Prozesse zu agilisieren.

So hat nun mittlerweile nahezu jedes Unternehmen in irgendeiner Form Erfahrungen mit agilen Methoden gesammelt. Diese Erfahrungen sind nicht nur positiv, sondern weisen – wie einiger der hier vorgestellten Studien nahelegen – auch auf viele Herausforderungen hin, mit denen Unternehmen bei der Einführung von agilen Methoden zu kämpfen haben.

Ernüchternde Ergebnisse der Studie „Softwaretest in der Praxis“

Durch Diskussionen mit einem meiner Kunden bin ich auf die Studie „Softwaretest in der Praxis“ aufmerksam geworden. Die Studie wurde 2011 durchgeführt und die Ergebnisse (PDF) sind teilweise beunruhigend: Laut der Studie sind klassische Qualitätssicherungsmaßnahmen in der Praxis gleich gut oder besser als die praktizierten Maßnahmen in den meisten agilen Projekten.

Qualität als kritischer Erfolgsfaktor bei agilen Methoden (agile success rate)

In Projekten in denen agile Methoden / Frameworks genutzt werden, spielt die Qualität der erzeugten Artefakte jedoch eine sehr wichtige Rolle. Da häufig Zwischenartefakte / Mittler fehlen, muss sichergestellt sein, dass durchgängig hohe Qualität erzeugt wird.

Kurz: Qualität ist ein kritischer Erfolgsfaktor für agil durchgeführt Vorhaben und für agile Organisationen. Fehlende Qualität wird schnell zu einem Problem.

Die Studie „Softwaretest in der Praxis“ im Detail

Die Umfrage zum „Softwaretest in der Praxis“ hat aufgrund der außerordentlich hohen Beteiligung von Testern, Entwicklern und Managern praktisch repräsentativen Charakter:

  • fast 1100 Projektleiter, Qualitätsbeauftragte, Testmanager und Tester
  • fast 270 Entscheider und Manager
  • ca. 420 Business Analysten, Entwickler, Betriebsverantwortliche und andere

Agile means agile

Zitat

Agile means agile

Agile meint Agilität; die Fähigkeit sich schnell auf Änderungen einzustellen.

Agile does not mean delivering faster. Agile does not mean fewer defects or higher quality. Agile does not mean higher productivity. Agile means agile – the ability to move quick with easy grace, to be nimble and adaptable. To embrace change and become masters of change – to compete through adaptability by being able to change faster than your competition can. This agility is supported by both lean and agile practices.

Craig Larman, Bad Vodde: Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum. Kapitel „Be Agile“.

 

Ein paar Bücher (agile bookshelf)

In letzter Zeit bin ich immer mal gefragt worden, welche Bücher rund um Agilität, agiles Projektmanagement und Agilität im Großen ich empfehlen könnte („Agile Bookshelf“).

Zur ein Bild zur Inspiration, welche Bücher interessant sein könnten, wobei ich viele noch nicht richtig einsortiert habe:

Ein paar Bücher rund um Agilität (Agile Bookshelf)

Interessant ist auch, dass man gute Bücher nach einigen Jahren ganz neu lesen kann. Spannend sind auch heute noch Klassiker wie „The mythical man month“ von Brooks, die helfen sich die grundsätzlichen Herausforderungen und die Entwicklung unserer Disziplin vor Augen zu führen.

Aktuell häufiger in Nutzung:

  • Bücher zu Agilität im Großen (Scaling Agile) wie „Agile Software Requirements (Leffingwell)“ und „Practices for Scaling Lean & Agile Development (Larman/Vodde)“
  • Bücher für die Praxis wie „Agile Retrospectives (Derby/Larsen)“, „Game Storming (Gray, Brown, Macanufo)“ und „Agiles Coaching (Davies, Sedley)“

Weitere Empfehlungen zu „Agile Bookshelf“

Wer Empfehlungslisten mag, der kann in folgenden Listen nachsehen:

Stefan Hagen veröffentlicht auch immer mal wieder Tipps zu Büchern, so auch dieses Wochenende: Buchtipps zum Wochenende.

Scaling Agile: Scaling the Lean / Agile Enterprise – Ein Workshop mit Dean Leffingwell

Die Themen Agilität und Lean sind im Unternehmensalltag angekommen. In vielen Fällen geschieht die Einführung Bottom-Up: Einzelne Teams entscheiden sich für ein agiles Vorgehen bzw. Framework wie Scrum, erst in einem zweiten Schritt wird über ein koordiniertes Rollout von agilen Vorgehensweisen und grössere Änderungen in der Organisationsstruktur nachgedacht.

Die Praktiken in Scrum, wie sie die letzten Jahre vielfach diskutiert wurde, fokussieren sehr stark auf die Teamebene. Das Team als Kern der Wertschöpfung mit einzelnen Menschen die sich selbst organisieren und gemeinsam ihre Regeln definieren.

In der Realität steht man vielfach vor der Herausforderung, dass erfolgreiche Teams zwar die Bedingung für ein erfolgreiches Unternehmen sind, dies alleine aber nicht ausreicht. Möchte man skalieren („scaling agile“) und kann die betroffene Organisation nicht in weiten Teilen neu aufstellen, so muss man viele Kompromisse eingehen (ScrumBut) oder teure und riskante Reibungsverluste hinnehmen.

Wie kann es also gelingen systematisch agile/lean Vorgehensweisen und Strukturen zu skalieren? Dean Leffingwell gibt mit seinem Scalable Agile Framework (SAF) eine Antwort darauf.

Website http://scaledagileframework.com/

Anfang Juli 2012 hatte ich Gelegenheit Dean Leffingwell persönlich kennen zu lernen und ihm Heidelberg zu zeigen. Zudem konnte ich vor dem Scrum Day 2012 in Walldorf an seinem zweitägigen Workshop „Leading the Lean|Agile Enterprise: A Two-day Workshop for Leaders, Managers, and Executives“ teilnehmen. Dieser Workshop und intensive Diskussionen mit Dean haben mich davon überzeugt, mich weiter mit dem SAF zu beschäftigen. Der Workshop selbst war sehr interessant, wobei es nicht immer leicht war Dean zu folgen, da er in einer unglaublichen Geschwindigkeit ein wichtiges Thema nach dem nächsten behandelte. Alles war durchgetaktet und entsprechend anstrengend war es für alle Teilnehmer.

PM Camp 2012 am Bodensee

Letztes Jahr war ich beim ersten PM Camp und begeistert von den Diskussionen des gemischten Publikums. Die dort anwesenden Projektleiter hatten meist umfangreiche  Erfahrungen mit  klassischen und agilen Projekten, Teams und Organisationen. So wurden sowohl Teamprozesse in agilen Teams beleuchtet als auch davon berichtet, wie hilfreich klassisches Projektmanagement beim Turnaround eines russischen Stahlwerks war.

Diesen Juni fand ein PM Camp auch in Wien statt, an dem ich leider nicht teilnehmen konnte.

Wie Stefan Hagen berichtet, finden auch dieses Jahr im November (8.-10.11.) wieder ein PM Camp in Dornbirn am Bodensee statt. Ab sofort kann man sich für das PM Camp registrieren.

Ich erwarte spannende Diskussionen über Themen wie

  • die Widersprüche zwischen Agile (= flow) und Projekt (= Einmaligkeit)
  • Skalierungsansätze in agilen Unternehmen und Projekte in diesem Umfeld
  • allgemeiner Erfahrungsaustausch zu agilem und traditionellem Projektmanagement
Freue mich auf das PM Camp und bin sicher, dass es auch dieses Mal eine sehr spannende Veranstaltung sein wird!