-->

Mittwoch, 1. Dezember 2010

Der Loop-2-Fragebogen für Agile Teams V1.1.

In vielen Industrien und Dienstleistungsbereichen werden bereits seit langem ausführliche Evaluationswerkzeuge eingesetzt. Diese unterstützen Arbeitsgruppen und Teams unterschiedlichster Art durch das gezielte Abfragen von Best Practices bei der Reflektion ihrer Arbeitsweise und Arbeitsorganisation.

Im Bereich der Agilen Softwareentwicklung gibt es jedoch nur wenig Review-Instrumente, die breit einsetzbar sind. Entweder dienen sie wie der Nokia-Test eher einer Statusabfrage für das Top-Management oder sie zielen dezidiert auf Scrum ab und sind damit nur eingeschränkt für Teams geeignet, die andere Agile Methoden einsetzen.

Ich habe mich deshalb hingesetzt und einen breiter einsetzbaren Fragebogen entwickelt. Das Ziel war ein Werkzeug, dass agile Teams jeder Coleur dabei hilft, ihre Review-Meetings besser zu strukturieren und ihre Prioritäten sebst zu bestimmen.

Einen solches generisches Instrument zu entwickeln, war deshalb möglich, wei allen Varianten der agilen Softwareentwicklung drei wichtige Gemeinsamkeiten zugrunde liegen. Ideale Agile Entwicklerteams sind unabhängig vom jeweiligen Framework, d.h. unabhängig von Scrum, Kanban etc. immer:

  • Sich selbst organisierende und
  • lernende Teams,
  • die zusätzlich softwarespezifische Arbeitstechniken einsetzen.

Der so entstandene Fragebogen und die dazu gehörigen Erläuterungen liefern bereits durch die Fragestellung viele Hinweise auf Best Practices in agilen Entwicklungsteams. Dies ersetzt aber keine Fachliteratur und keine Schulungen oder Trainings.

Ihr könnt den Fragebogen frei verwenden (Details stehen in der Creative Commons Lizenz ganz unten). Hier ist die druckfertige PDF-Version. Dazu meine Bitte: Wenn Ihr den Fragebogen an Kollegen weiter geben wollt, so verschickt bitte nicht die Datei, sondern den Link zu diesem Blog:

http://blog.loop-2.net/2010/12/der-loop-2-fragebogen-fur-agile-teams.html

Ich freue mich über Rückmeldungen, Kritik und Verbesserungsvorschläge. Benutzt dazu am besten die Kommentarfunktion, dann haben alle anderen Leser auch etwas davon.

Halle, den 30. November 2010

Lucius Bobikiewicz


Der Loop-2-Fragebogen für Agile Teams

Version 1.1


Zielorientierung und Verantwortung

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W + G)
1
Das gesamte Team kennt die Ziele und Rahmenbedingungen des Projekts



2
Die Prioritäten des Kunden sind allen Teammitgliedern immer bekannt



3
Die Erfolge des Teams werden wahrgenommen und anerkannt



4
Die Einzelleistung jedes Teammitglieds ist für alle sichtbar






Koordination und Planung

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
5
Die Aufwandsschätzungen und die Arbeitspläne werden ausschließlich von Mitgliedern des Teams erstellt



6
Der aktuelle Projektplan wird immer mit allen Teammitgliedern abgestimmt.



7
Die Dauer der Arbeitsphasen zwischen zwei Planungs- intervallen sind den Projektphasen angemessen



8
Die Aufgabenliste für eine Arbeitsphase ist immer auf maximalen Durchsatz ausgelegt, es werden keine Puffer eingebaut



9
Wir pflegen in unserem Projektmanagement nur Daten ein, die wir für unsere Arbeit brauchen



10
Unser Projektmanagement ist leicht zu verstehen und angenehm zu benutzen



11
Jeder weiß, welche Probleme es gerade gibt und wer sich darum kümmert






Arbeitsplatz und Arbeitsprozess

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
12
Jeder hat alle Werkzeuge und Informationen, die er zum guten Arbeiten braucht, jederzeit zur Verfügung



13
Jeder bei uns kann die für seine eigene Arbeit notwendigen Entscheidungen selbst treffen



14
Alle Teammitglieder wissen, was die anderen jeweils gerade tun



15
Jeder kann jederzeit einen neuen Build mit dem eigenen Code und/oder dem neuen Code der Teamkollegen veranlassen



16
Jeder kann sich sich hier voll auf seine Aufgaben konzentrieren. Es gibt kein Multitasking und keine Unterbrechungen



17
Unser Auftraggeber ist immer verfügbar, wenn wir ihn brauchen





Ergebnisprüfung

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
18
Allen Teammitgliedern sind der aktuelle Projektfortschritt und die noch offenen Aufgaben jederzeit bekannt



19
Jeder von uns kann jederzeit einen vollständigen Testlauf anstoßen und die Ergebnisse der Tests sind für ihn selbst und für alle anderen sofort verfügbar



20
Die Abnahme von Zwischenreleases oder Meilensteinen findet zu definierten und sinnvollen Intervallen statt






Lernen

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
21
Probleme und Fehlschläge finden wir interessant, wir analysieren sie gerne, weil dies hilft, besser zu werden



22
Neue Erkenntnisse werden von uns sofort in den Arbeitsprozess integriert



23
Wir nehmen regelmäßig und systematisch Auszeiten, um über unsere Arbeit und unsere Arbeitsweise zu reflektieren



24
Das Experimentieren mit neuen Werkzeugen oder Abläufen gehört bei uns selbstverständlich zur Arbeit dazu



25
Wir wechseln intern immer wieder Aufgaben und Rollen



26
Wir tauschen uns immer wieder mit anderen Teams / anderen Organisationen aus und versuchen, von diesen zu lernen





Teamstärke

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
27
Unsere Auftraggeber schätzen die Zusammenarbeit mit uns



28
Bei uns herrscht eine Atmosphäre gegenseitiger Anerkennung und Wertschätzung



29
Wir verwenden gezielt Techniken oder Methoden, die sicher stellen, dass jeder von uns seine Sichtweise beitragen kann



30
Unser Team wählt seine Sprecher oder Teamleiter selbst



31
Ich arbeite gerne hier





Abschluss

Wertung
-2 bis 2
Gewicht
-2 bis 2
Score
(W+G)
32
Die Ergebnisse der letzten Befragung wurden umgehend ausgewertet und es wurden wirksame Maßnahmen ergriffen



33
Diese Befragung wird in einem festgelegten, verläßlichen Rhythmus durchgeführt



34
An diesem Fragebogen gibt es nichts mehr zu verbessern ;)





Wie der Fragebogen angewendet wird


Regelmäßige Durchführung

Da sich Entwicklungsmethoden und Projekte laufend verändern, gibt es keinen Fixpunkt in der Teamentwicklung. Die Frage “Was könnten wir besser machen” muss immer wieder gestellt werden. In Scrum gibt es hierfür die Daily Scrums und die Sprint Reviews. Genau so kann dieser Fragebogen eingesetzt werden. Es bieten sich hierfür sowohl zeitliche Intervalle an, z.B. alle zwei Monate, oder ereignisgesteuerte Intervalle, z.B. eine Rückschau nach jeder Veröffentlichung eines neuen Release.

Anonyme Befragung

Um eine gegenseitige Beeinflussungen oder eine Beeinflussung von einzelnen Teammitgliedern zu vermeiden, sollte der Fragebogen grundsätzlich anonym ausgefüllt werden. Desweiteren sollte er von allen Teammitgliedern ausgefüllt werden, damit er ein möglichst vollständiges Bild liefert.

Die Antwortskala

Bitte geben Sie für jede Aussage mit einer Wertung von -2 bis +2 an, wie weit diese ihrer Ansicht nach auf die aktuelle Situation zutrifft:
Überhaupt nicht
eher nicht
weiß nicht
eher ja
völlig
-2
-1
0
+1
+2

Beim Gewicht geben Sie mit der gleichen Skala an, wie sich der aktuelle Status ihrer Einschätzung nach auf die Arbeit des Teams auswirkt:
sehr negativ
eher negativ
akzeptabel
eher positiv
sehr positiv
-2
-1
0
+1
+2

Der Score errechnet sich dann einfach aus der Addition von Wertung und Gewicht. Ein Score von +4 zeigt beispielsweise einen sehr positiven Aspekt auf, während bei -4 dringender Bedarf an Verbesserungen besteht.

Auswertung

Identifizieren Sie mit dem Team zusammen :

  • die drei Aussagen mit dem höchsten Score, dass sind die Aspekte, die sehr positiv gesehen werden. Schreiben Sie diese an eine Tafel oder einen Flipchart, damit diese von allen wahr genommen werden.

  • die drei Aussagen, mit dem niedrigsten Score. Das sind die Punkte, bei denen der dringendste Bedarf für Verbesserungen besteht. Schreiben Sie auch diese an die Tafel. Wenn es mehr als drei mit höchstem Score gibt, dann einigen Sie sich auf die drei, maximal vier, die sie für besonders wichtig halten.

Diskutieren Sie für die Punkte, bei denen das Team den dringendsten Handlungsbedarf sieht, welche Maßnahmen zur Verbesserung ergriffen werden können. Entwickeln sie gemeinsam konkrete Maßnahmen und einen Arbeitsplan und bestimmen Sie Verantwortliche dafür.

Erläuterungen zu den Fragen


Zielorientierung und Verantwortlichkeit

Erst ein gemeinsames Ziel verwandelt eine Gruppe von Individuen in ein Team. Damit alle Mitglieder ihre Tätigkeit an dem Ziel ausrichten können, ist es notwendig, dass alle Teammitglieder das Ziel des Projekts und seine Rahmenbedingungen kennen.

Während das gemeinsame Ziel und die gemeinsame Beurteilung als Team der Kit sind, der die Gruppe zusammen hält, ist es gleichzeitig wichtig, auch jeden Einzelnen in die Verantwortung zu nehmen. Sonst kommt es zum “Wo alle zuständig sind, ist keiner zuständig”-Effekt.

Die Erfolge des Teams lassen sich während dem Projekt in Burn-Down-Charts messen oder beim Projektabschluss über die Kundenzufriedenheit, den finanziellen Ertrag und ähnlichem.

Auch die individuelle Leistung der einzelnen Teammitglieder sollte teamintern sichbar gemacht werden. Z.B. in dem über Reports aus dem Ticketsystem angezeigt wird, wer welche Aufgaben bearbeitet hat und wie lange er dafür benötigt hat. Oder wieviele Storypoints jemand im Laufe der Woche abgearbeitet hat. Oder indem auf der Startseite des Projektmanagementsystems angezeigt wird, wer wie oft von Kollegen um ein Code-Review gebeten wurde.

Wichtig ist, dass jedes Teammitglied weiß, dass seine positiven Beiträge von den anderen gesehen und werden.

Koordination und Planung

Komplexe Aufgabenstellungen erfordern das Wissen und die Erfahrung aller Beteiligten. Eine Planung unter Einbeziehung aller Teammitglieder ist in der Regel wünschenswert, in der Praxis kommt es aber immer wieder vor, dass einzelne Aspekte oder Aufgaben wie z.B. das Systemdesign doch nur von einem oder wenigen Spezialisten geplant werden können. Aber in diesem Fall sollte zumindest ein ausführlicher Review-Termin statt finden, in dem diese Spezialisten ihre Entscheidungen darlegen, begründen und mit den übrigen Teammitgliedern diskutieren.

Auch Planungsprozesse beanspruchen viel Zeit und Ressourcen. Deshalb ist es wichtig, dass diese so oft wie nötig, aber auch nicht öfter als notwendig statt finden. Da agile Entwicklung im wesentlichen ein Dreischritt von Planen, Umsetzen und Analysieren (Lernen) ist, hängt der richtige Rhythmus von der Veränderungsdynamik in der jeweiligen Projektphase ab. Eine Arbeitsphase sollte immer genau so lange dauern, bis das Weiterarbeiten anfängt, zu unreifen, nicht mehr verwendbaren Implementierungen zu führen.

Im agilen Vorgehen werden die Aufgaben so geplant, dass alle Beteiligten ohne Leerlaufzeit kontinuierlich arbeiten können. Dies entspricht den Prinzipien der Kritischen Kette von E. Goldratt.

Das Projektmanagementsystem soll auf allen Ebenen, von der User Story oder der Featurebeschreibung bis hin zum Bearbeitungsstatus und Workflow nur Daten enthalten, die die Entwickler benötigen. Pflichtfelder, die nur aufgrund von Verwaltungsvorschriften ausgefüllt werden, sind nicht nur wertlos, sondern vernichten sogar kostbare Entwicklungszeit. Auf der anderen Seite muss, was immer an Daten benötigt wird, darin auch für alle zugänglich abgelegt werden können. Falls notwendig gehören dazu auch Bilder, Diagramme, Videos etc.. Gleichzeitig sollte das Projektmanagementwerkzeug leicht und intuitiv zu bedienen sein.

Unbeseitigte Probleme führen bei allen Beteiligten zu “Stuff” (s.a. "Getting Things Done" von David Allen), zu Ablenkung und mentalem Overhead. Werden Probleme jedoch gemeinsam besprochen, bewertet und für alle sichtbar in eine Maßnahmenplanung umgesetzt, schafft dies Klarheit und Handlungsfreiheit für das gesamte Team. In Scrum wird für die Problemidentifikation das Daily Scrum Meeting und die Impediment-Liste verwendet. Andere denkbare Lösungen sind aber auch Team-Wikis oder Shared Spreadsheets.

Arbeitsplatz und Arbeitsprozess

Jeder Arbeitsplaz sollte selbstverständlich so ausgestattet sein, dass alle erforderliche Soft- und Hardware zur Verfügung steht. Dazu gehören neben der IDE und dem Projektmanagementsystem inbesondere die Testumgebung, der freie Zugriff auf Repositories, die Verfügbarkeit von Handbüchern aller Art, aber auch Hardware wie beispielsweise große Bildschirme oder Multi-Bildschirm-Setups.

Ein wesentliches Element eines motivierenden Arbeitsplatzes ist die Befugnis, die eigenen Aufgaben in Eigenregie organisieren und bearbeiten zu können. Dazu gehört die Freiheit des Wann, des Wie, des Womit etc.

Erst das Wissen um die Tätigkeit der anderen ermöglicht es den übrigen Teammitgliedern, Unterstützung und Hilfe zu geben. Eine Nachricht wie “Du fängst mit Task 231 an? Pass auf, die Methode in der Library XYZ hat noch keinen Freeze-Status” kann teure Fehl-Arbeit verhindern. Die Information über “was tue ich gerade” kann auf vielfältige Weise weiter gegeben werden. Außer dem Arbeiten im gemeinsamen Büro bieten sich heute beispielsweise auch Twitter, IM oder ein automatische Verknüpfung von Projektmanagement mit einem RSS-Feed an. Zum Beispiel so: “Michael has just opened Task 231 >>Save-Button<<; Workflow Status: Testing”.

Je flexibler eigener Code zusammen mit dem Code anderer Kollegen getested werden kann, desto leichter können Abhängigkeiten und unerwünschte Nebeneffekte identifiziert werden, ohne das zentrale Repository mit mangelhaften Implementierungen zu füttern. Das saubere Setup des Repositories ist entscheidend, richtig genutzt können auch sehr einfache Tools wie z.B. die Kombination von Dropbox mit Git perfekte Lösungen liefern.

Damit Unklarheiten nicht zu Fehlentwicklungen oder Verzögerungen führen, ist eine enge Abstimmung wichtig. Was angemessen und möglich ist, muss für jedes Projekt neu definiert und ausgelotet werden.

Ergebnisüberprüfung

Der gemeinsame Abgleich des Ist- mit dem Sollzustand schafft Klarheit über Prioritäten und Probleme, motiviert die Teammitglieder durch die Sichtbarkeit des Projektfortschritts und führt automatisch zur Synchronisation der nächsten Aktivitäten. Je sichtbarer und zeitnäher dieser Abgleich statt findet, z.B. über eine Wandtafel, die Login-Seite des Projektmanagementsystems o.ä. desto genauer und kleinteiliger kann sich das Team abstimmen.

Der freie Zugriff auf Testressourcen ermöglicht ein interaktives “Modelieren”. Die Teammitglieder können um so effizienter und effektiver arbeiten, je kürzer die Zeitspanne zwischen Codeerzeugung und Rückmeldung ist.

Feste Abnahmetermine und Meilensteine erzeugen Planungssicherheit, verhindern das unwillkürliche Abdriften des Projekts. In Verbindung mit gleichzeitigen Arbeitsphasen- und Projektreviews stellen sie sicher, dass der Fokus auf Qualität und Wertschöfpung aufrecht erhalten bleibt.

Lernen

Wirksames Lernen basiert darauf, dass über Fehler oder Unzulänglichkeiten offen und mit Interesse gesprochen wird. Alle erfolgreichen Teams pflegen eine Kombination aus Hochleistungsansprüchen bei gleichzeitiger no “No Blame”-Mentalität.

Lernen ist umso wirksamer, je schneller das gelernte in Lösungen umgesetzt werden kann. Ein ausschließlich strukturiertes Lernen, z.B. in Form von zweiwöchigen Review-Meetings führt dazu, dass viele wichtige Punkte in Vergessenheit geraten oder nur noch unvollständig rekonstruiert werden können.

Trotzdem ist auch das formalisierte Lernen, z.B. in Form des Daily Scrums und vor allem in Form von Sprint-Reviews und Projektreviews von großer Wichtigkeit. Die Formalisierung erzeugt Sicherheit und Verlässlichkeit, hält den Fokus auf die kontinuierliche Verbesserung aufrecht und stellt - sofern gut moderiert - sicher, dass auch “leise” Beiträge gehört werden.

Der Vergleich mit anderen Teams schafft ein Bewusstsein für das Entwicklungspotenzial, motiviert zur Aufholjagt oder erzeugt Stolz auf das Erreichte.

Änderungen in der Arbeitsweise sind immer mit dem Risiken eines Rückschlags verbunden. Aber nur wenn dieses Risiko akzeptiert und bewusst eingegangen wird, können echte Verbesserungspotenziale erschlossen werden. Auch scheinbare Fehlschläge beinhalten wichtige Lernerfahrungen und Wissenszuwachs!

Der breitest mögliche Wechsel von Aufgaben und Rollen stellt die Teammitglieder vor neue Herausforderungen, verbreitert die Wissens- und Erfahrungsbasis im Team und fördert die persönliche Entwicklung der Einzelnen.

Teamstärke

Ein Team ist nur dann ein Team, wenn die Mitglieder ein gemeinsames Ziel haben und gemeinsam für die Zielerreichung verantwortlich sind.

Soziale Wertschätzung und Anerkennung gehören für Menschen zu den wichtigsten Motivationsfaktoren.

In jeder sozialen Gruppe kann es dazu kommen, dass starke Persönlichkeiten Entscheidungsprozesse dominieren oder dass es zur Entwicklung von schädlichen Gruppendenken kommt. Techniken wie das Schätzpokern in Scrum, Ideajams oder moderierte, gecoachte Review-Meetings wirken dem systemisch entgegen und stellen sicher, dass auch eher stille Teammitglieder sich einbringen können und gehört werden.

Sofern die Mutterorganisation dies zulässt, kann die Wirksamkeit selbstorganisierender Teams soweit gehen, dass nicht nur die internen Abläufe, sondern auch die auch Sprecher und Teamleiter vom Team selbst bestimmt werden.

Die allgemeine Zufriedenheit mit dem Arbeitsplatz entscheidet über die innere Motivation und damit über die Leistungsfähigkeit. Allerdings kann die Frage “Ich arbeite gerne hier”  nur als Frühindikator bei neu auftauchenden Problemen verwendet werden. Hat sich in einem selbst organisierten Team beispielsweise bereits schädliches Gruppendenken etabliert, wird bald eine Abkoppelung von der Orientierung auf die Ziele, ein Ansteigen der Fehlerquote oder ähnliches zu registrieren sein. Trotzdem sind es dann aber nur noch die ehemaligen (!) Teammitglieder, die aufgrund ihrer Aussensicht verlässlich Auskunft über mögliche interne Probleme des Teams geben können.

Abschluss

Da sich Teams, Projekte und Technologien laufend verändern, sollte der Fragebogen, bzw. die damit verbundene Analyse zu festgelegten Intervallen durchgeführt werden. Dies können zeitliche Intervalle sein, z.B. alle zwei Monate, oder ereignisgesteuerte Intervalle wie z.B. nach jeder Veröffentlichung eines neuen Release.

Wie alle Aktivitäten in einer lernenden Organsation, muss auch der Review-Prozess selbst einem Review unterliegen. Deshalb schliesst der Fragebogen mit zwei rekursiven Fragen zur Auswertung und zur Qualität ab.

Lizenz

Der Fragebogen und die zugehörigen Erläuterungen stehen unter der "Creative Commons Lizenz 3.0" in der sogenannten "by-sa"-Form: http://creativecommons.org/licenses/by-sa/3.0/de/legalcode.

Sie dürfen alle Bestandteile frei verwenden und auch verändern, müssen aber in der Fußzeile aller Seiten in gleicher Schrift wie im Erläuterungstext den Vermerk anbringen: "Basierend auf dem Loop-2-Fragebogen für Agile Teams, Vers. 1.1"'.

Weiter müssen auch die neue und alle weiteren Fassungen die hier formulierte Lizenzbestimmung übernehmen.

30. Nov. 2010

Lucius Bobikiewicz