Freitag, 19. Juni 2015

Teambullshit oder wirkliche Teams. Mit dem Team gegen das Chaos.

Ordnung ins Chaos

Artikelübersicht
1. Teil Gegenseitige Hilfe ersetzt Chaos.
2. Teil Ein Held, der sich helfen lässt.
3. Teil Teambullshit oder wirkliche Teams. Mit dem Team gegen das Chaos.
4. Teil Vom Sprint zum Überblick. Durchblick kommt nicht von allein.


Im letzten Post dieser Reihe habe ich mir die Aufgabe gestellt, vertiefend in die neu zu schaffenden Teamstrukturen einzudringen. Diese kleinen, selbstständig agierenden Teams sind ein Weg, Ordnung ins Chaos der Firmen zu bringen, welches ich im Artikel Gegenseitige Hilfe ersetzt Chaos beschrieben habe. Bisher haben wir in unserem Beispiel von den 20 Mitarbeitern der Entwicklung 10 in neue Teams verteilt. Dieser Vorgang geschah auf freiwilliger Basis, weil Mitarbeiter intelligente Wesen sind und diktierte Verordnungen das Gegenteil von dem bewirken, was sie erreichen wollen. Die Macht des einfachen Mitarbeiters ist es, demotiviert Aufgaben zu erfüllen.

Eines unserer wichtigsten Voraussetzungen ist es, das Versprechen von flachen Hierarchien ernst zu nehmen und wirklich selbständige Teams zu schaffen. Diese haben einen konkreten Aufgabenbereich bekommen, den sie selbsttätig verwalten. Weiterhin war es wichtig, Managementaufgaben vom Team zu trennen und diese in die Managementebene zurückzubeordern. Da wären so wichtige Dinge wie der große Produktplan und die Priorisierung von Aufgaben.

Wie sollte sich ein solches Team nun organisieren? Ein Team ist ein Arbeitszusammenhang, der über einen langen Zeitraum hinweg Aufgaben zu lösen hat. Firmen mit Arbeitskräftepools, aus denen nach Beliebigkeit neue Teams zusammengesetzt werden können, sollten diese eher Würfeleinheiten nennen und nicht Teams. Die wichtigsten Eigenschaften eines Teams gehen auf diese Weise verloren. In einem Team haben sich die Mitglieder aufeinander eingestellt. Sie wissen wie die anderen ticken, Fähigkeiten und Fertigkeiten sind bekannt. Jeder hat seinen Platz. Das Zusammenwürfeln von Teams erzeugt jedes Mal neue Platzverteilungskämpfe. Die Einzelnen müssen sich wieder neu erfahren, um zu wissen, mit wem sie es zu tun haben. Der Grund für solche Würfelteams sind die Unfähigkeit des Managements, wirkliche Teams zu bauen, ordentliche Planungen durchzuführen oder ein ungebremstes Machtgefühl, mit Menschen machen zu können, was man will.

Wir haben also ein langfristig bestehendes Team mit Teambacklog und Sprintbacklog. Jeden Tag wird ein kurzes Abstimmungsmeeting, das sogenannte Daily Scrum, durchgeführt, welches den Arbeitsfortschritt und die bestehenden Probleme zeitnah aufdeckt. Jeder Sprint hat einen Anfang und ein Ende. Das Ende des einen Sprints ist der Anfang des neuen Sprints. Zwischen den Sprints sollte man die Uhr anhalten und auf den vergangenen Sprint zurückblicken. Am Anfang des Sprints plant man, welche Aufgaben in dieser Zeiteinheit erledigt werden sollen. Zu übernehmende Aufgaben werden gemeinsam mit dem Produktmanager abgestimmt. Er hat den großen Plan im Kopf und muss wissen, welches die dringendsten zu erledigenden Aufgaben sind. Nur hier hat er die Möglichkeit, in die Planungsstruktur des Teams einzugreifen. In den folgenden Tagen des Sprints sollte er das Team in Ruhe arbeiten lassen. Entwicklungsarbeit benötigt Konzentration über längere Zeiträume. Hereinplatzende Manager können sich oft gar nicht vorstellen, wie viel Zeit auf diese Art vergeudet wird.



Am Anfang des Sprints ist also ein Planning abzuhalten. Nach dem Planning ist das Sprintbacklog mit Aufgaben gefüllt. Ich empfehle zur Definition der Aufgaben einen Issue Tracker wie JIRA. Der verwendete Issue Tracker sollte in der Lage sein, verschiedene Aufgaben- bzw. anzufertigende Artefakttypen anzulegen und für diese Statusmodelle zu definieren. Jeder Artefakttyp bzw. jede Aufgabe hat so eine eindeutige ID, die von einem Tool vergeben wird und somit nicht von der Disziplin des Teams abhängt. Bei der Definition dieser Typen wird sichtbar, welche Arbeitsweise das Team gewählt hat, um seine Aufgaben zu erledigen. Gehen wir davon aus, dass die Teams das Requirements Engineering und die Softwarearchitektur als notwendige Bestandteile ihrer Entwicklungsarbeit erkennen, dann kann ich mein Objekt-Aufgaben-Modell empfehlen. Hier wird ausgehend von der Idee bis hin zur Anforderung das Requirements Engineering als Entwicklungsarbeit verstanden. Das Team- wie auch das Sprintbacklog werden mit User Stories und mit allgemeinen Aufgaben gefüllt. Solche allgemeinen Aufgaben können Untersuchungen zu neuen Techniken sein, Teamvorträge, Organisationsaufgaben und vieles mehr, eben alles Dinge, bei denen keine Entwicklungsartefakte erstellt werden. User Stories und allgemeine Aufgaben bilden in diesem Zusammenhang Planungsinstrumente für das Team. Für diese Einheiten, User Stories und allgemeine Aufgaben, werden Schätzungen durchgeführt. Schätzungen und Prioritäten sind die Grundlage für das Füllen des Sprintbacklogs.

In den 15 Artikeln zum Requirements Engineering, den 8 Artikel zum Usability Engineering und den 3 Artikeln zum funktionalen, logischen und technischen Architekturentwurf habe ich beschrieben, wie ich mir ein System vorstelle, mit dem man systematisch Software entwickeln könnte. In späteren Artikeln möchte ich dieses System weiter ausbauen und auf der Grundlage der Erfahrungen meiner Leser und meiner eigenen zukünftigen Erfahrungen verbessern. In diesem Wunsch spiegelt sich auch das zentrale Anliegen meines Blogs wider. Die Zwischenergebnisse der Arbeit werden vom Team im Daily Scrum reflektiert. Außerdem werden dort Probleme kurzfristig erkannt und Lösungen können eingeleitet werden.

Am Ende unseres Sprints sollten alle oder wenigstens fast alle Aufgaben erledigt sein. Im Review, der sprintabschließenden Veranstaltung, werden die einzelnen Aufgaben vom Produktmanager und dem Team bewertet. Dazu existiert eine eigene Testmaschine auf der ein extra angefertigtes Sprintrelease läuft. Auf keinen Fall sollten die Entwickler ihre Aufgaben auf ihren Maschinen vorstellen. Zu oft ist schon der Satz "Bei mir hat es aber funktioniert!" gefallen Mit der Anfertigung eines Teamreleases kommen wir zu einem weiteren wichtigen Prozess, der mit der Installation von Teams einher gehen sollte, nämlich dem Installieren eines automatisierten Builtprozesses. Bei jedem Einchecken in die Versionsverwaltung sollte die Software gebaut werden. Kann sie nicht gebaut werden, muss der entsprechende Entwickler automatisch informiert werden, damit er seinen Fehler zeitnah beheben kann. Auch das Anfertigen von Sprint-, Test- und Auslieferungsversionen muss geplant werden.

Im Review wird also die zurückliegende Sprintarbeit bewertet und für gut befunden oder zur Nacharbeit an den nächsten Sprint übergeben. Diese Nachbearbeitungsaufgaben sollten höchste Priorität haben, soweit der Produktmanager nicht entscheidet, sie zurückzustellen.

Eigentlich treffen das Review des letzten Sprints und das Planning des aktuellen Sprints aufeinander. Sie werden getrennt durch eine kurze Phase der notwendigen Besinnung und Korrektur, der Retrospektive. Hier fragen wir uns: Was ist schlecht gelaufen? Was waren sinnlose Schritte? Welche Arbeiten hätten wir außerdem durchführen müssen? Wie ein Raumschiff, welches durch kleine Kurskorrekturen auf der Bahn bleibt, steuert sich das Team durch den Entwicklungsalltag. Eine weitere wichtige Frage sollte uns hier beschäftigen: Verfügen wir über die notwendigen Soft Skills, um eine effektive Teamarbeit zu gestalten? Fehlende Bereitschaft mit anderen zusammenzuarbeiten, eigene Standpunkte in Frage zu stellen, Verantwortung zu übernehmen, die Grenzen des eigenen Tuns zu erkennen, sich auf andere verlassen zu können und sich gegen sinnlose Strukturen zu wehren, verhindern auf ganz harte Weise effektive Teamarbeit. Deshalb würde ich diese Eigenschaften auch nicht Soft Skills nennen. Es sind Hard Skills - Eigenschaften, die uns ausmachen.

vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen