Schlagwort-Archive: Agile

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

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