Wie Hochleistungsteams  funktionieren wurde vorgestern in der ZDF-Sendung “Abenteuer Wissen” am Beispiel von Regatta-Segeln erklärt. Der Beitrag ist noch online verfügbar und weist aus meiner Sicht viele Parallelen zur agilen Softwareentwicklung auf. Insbesondere die Retrospektive wurde in dem Beitrag als einer der zentralen Schlüssel für den Erfolg von Teams identifiziert. Dabei gilt sowohl die Selbstreflektion jedes Einzelnen, als auch die der ganzen Gruppe.

Bevor aus einer Gruppe allerdings ein Team wird ist es notwendig, dass alle ein gemeinsames Ziel vor Augen und auch verinnerlicht haben. Das heißt, in den Köpfen der Mitglieder ist zum einen ihre Teilaufgabe hinterlegt, zum anderen aber auch das Big Picture. (Für das Big Picture in der Softwareentwicklung eignet sich der “Elevator Pitch” hervorragend).

Wichtig ist für die Teambildung der richtige Charakter der Mitglieder.  Man braucht Leute mit den richtigen Wesenszügen und Kompetenzen, denen man vertrauen kann. Alle müssen sie unter einer klaren Führung zusammenarbeiten. Ein Team ist kein Ort der Selbstprofilierung oder individueller Machtstrategien.

Wer nähere Informationen zu dem Thema sucht, findet sicherlich was auf dem Blog von Winfried Berner. Dort habe ich einen interessanten Beitrag über die Geheimnisse gut funktionierender Arbeitsgruppen gefunden, der das Thema aus Sicht von Projektteams erläutert.

Ich habe in den letzten Wochen die UML als Kommunikationsmittel für mich entdeckt. Angefangen mit Activity Diagramme, die ich in Visio gezeichnet habe, über Use Case und Sequence Diagramme.
Ich rede an dieser Stelle aber nicht von UML als Modellierungssprache um daraus fertigen Code zu generieren oder gar erweiterte Ansätze wie MDD/MDA. Ich spreche von der UML als Mittel zur Kommunikation mit Stakeholdern oder Entwicklern.

Für mich der derzeit wichtigste Diagramm-Typ ist das Activity Diagramm. Das nutze ich zur Prozesserhebung und Modellierung. Es ist zwar komplexer als beispielsweise ein Sequence Diagramm, allerdings bietet es die Möglichkeit alternative Szenarien im Ablauf darzustellen. Diese Diagramme zeichne ich mit dem altbekannten Microsoft Visio. Allerdings nutze ich nicht die mitgelieferten Stencils, sondern die von Pavel Hruby, welche sich für das einfache Zeichnen ohne Validieren besser eignen. Zudem unterstützen diese Stencils die UML 2.2 und sind für alle gängigen Visio Versionen frei erhältlich.

Für die Sequence Diagramme nutze ich die Webanwendung Websequencediagrams.com. Ich habe bisher noch kein einfacheres Tool gefunden, um diese Art von Diagrammen zu erstellen. Besonders gefällt mir die Möglichkeit den Style einzustellen.  Für diejenigen, die weitere UML-Diagramme online erzeugen möchten, bietet sich die Website yuml.me an. Dort kann man neben Use Case Diagrammen auch Class- und Activity Diagramme erzeugen.  Alle Schaubilder können mittels URL in Webseiten, Wikis und Blogs eingebunden werden, was den einfachen Sketching und Kommunikations-Charakter unterstreicht.

So kann man mit diesen einfachen grafischen Methoden das Productbacklog detaillieren und User Stories für die einzelnen Sprints vorbereiten.

Ich habe seit längerem bereits keine Beiträge mehr verfasst. Das soll sich nun wieder ändern. Allerdings steige ich hier nur mit einem Verweis auf eine Präsentation von Xing ein, die Traian Kaiser und Mark Weber zum SCRUM Day 2009 vorgestellt haben.  Der Informationsgehalt ist ohne Tonspur nicht allzu groß, aber sehenswert ist sie dennoch.

Nachdem die Wikis sich inzwischen in vielen Unternehmen durchgesetzt haben, ist es vielleicht einmal Zeit einen kritischen Blick auf dieses Tool zu werfen.

Ich selbst habe 2005 ein Wiki eingeführt und war damals Feuer und Flamme für das allheilbringende Tool. Kommt doch mit einem Wiki ein echter Web 2.0 –Gedanke auf. Denn ein Wiki ist nach der Einteilung von O’Reilly eine Anwendung mit einem Web 2.0-Gehalt der Stufe 3. (Anwendungen, die nur online existieren und deren Funktionen auf Netzwerkeffekten basieren.) Zentrale inhaltliche Eigenschaft, ist die Entstehung der Inhalte durch die Benutzer. Soweit - so gut. Aber was passiert mit den Inhalten, die einmal in einem Wiki stehen?

Damit es auf Dauer in einem Unternehmen bestand haben kann, ist eine Form der Qualitätssicherung erforderlich. Diese erstreckt sich aber in den meisten Fällen nicht auf alle Bereiche des Wikis. So entstehen mit guter Absicht die unterschiedlichsten Dokumente. Das schöne daran – es können alle mitmachen (das liegt am Wiki). Dies birgt schon die erste Gefahr, dass Inhalte doppelt angelegt werden. Nachdem man es gemerkt hat, ärgert man sich, da die Arbeit nun umsonst war (liegt das auch am Wiki).

Was passiert aber mit den Dokumentationen, die in einem Projekt entstanden sind? Werden diese weiter gepflegt, wenn sich an den Systemen oder Prozessen etwas ändert? Dies geschieht meistens halbherzig – wir alle kennen die Gründe dafür (das liegt definitiv nicht am Wiki). Abgesehen davon, dass man selbst nicht mehr genau weiß, was alles im Wiki steht, hilft es neuen Mitarbeitern enorm sich in ein laufendes Projekt einzuarbeiten.

Binden diese neuen Mitarbeiter vorerst keine Ressourcen aus dem Team und haben dennoch die Möglichkeit einen Überblick zu bekommen – Volltextsuche sei Dank. So kann jeder, der zwei Stunden Ruhe haben, den Neuen mit dem Satz wegschicken: „Das steht doch im Wiki“ (das liegt am Wiki).

Sobald die zwei Stunden vergangen sind und die ersten Rückfragen entstehen, heißt es dann: „Das machen wir schon lange nicht mehr so, das solltest du nachdokumentieren“ (das liegt nicht am Wiki).

Und so bleibt ein Großteil der nicht ganz so häufig gelesenen Dokumentation doch aktuell – aber das liegt natürlich nicht am Wiki. Der Neue im Team hat dann auch den Überblick – nachdem er alles gelesen und nachdokumentiert hat – dank des Wikis.

Ich kann mir ein Arbeiten ohne die Wikis nicht mehr vorstellen. Es ist so einfach abteilungsübergreifend Dokumente zur Verfügung zu stellen, die von allen Beteiligten angereichert werden können.

Welche Inhalte in ein Wiki gehören muss man allerdings vorab festlegen, denn es sinnvoll diese nach Themen zu gliedern. Die Suche liefert  bessere Ergebnisse und die Benutzer können die volle Stärke dieses Tools nutzen.

Haben Sie andere oder ähnliche Erfahrungen gemacht? Lassen Sie es mich wissen!

Auf dem Xing Blog habe ich drei Artikel gefunden, in denen Traian Kaiser über die Einführung von Scrum berichtet.
Hintergrund dabei ist natürlich, die damit verbundene Möglichkeit, Kundenwünsche zeitnah umzusetzen und die Ship It!-Strategie besser verfolgen zu können.

Das größte Hindernis bei der Einführung von Scrum bestand wohl darin, die agilen Werte richtig zu kommunizieren und die neuen Rollen den vorherrschenden Jobbeschreibungen zuzuordnen.

Das benötigte Wissen haben die Projektmanager und einige Lead Engineers durch Scrum-Trainings erhalten.  Traian Kaiser beschreibt weiter, dass die Prozesse im Unternehmen und der Ablauf der Produktentwicklung  angepasst werden mussten - sich die Umstellung aber  insgesamt gelohnt hat, und sie nun für die Zukunft gerüstet sind.

So kann also eine Scum-Einführung in einem Unternehmen aussehen.  Die beschriebenen Hindernisse, wie das Verinnerlichen der agilen Werte, ist sicherlich eine der größten Herausforderungen für ein Unternehmen, welches nach Scrum arbeiten möchte.  Ich habe die Erfahrung gemacht, dass es tatsächlich schwierig ist Scum in Reinform anzuwenden.  Daher bediene ich mich vereinzelter Konzepte von Scrum und nenne es Scrumish

Die Artikel sind alle mal lesenswert und zeigen, dass es nicht so einfach ist, Scrum unternehmensweit einzuführen.