Feed on
Posts
Comments

Agile Systemadministration

Mein erster Beitrag in diesem Blog soll meine Erfahrung mit der agilen Systemadministration aufzeigen. Wir arbeiten nun seit drei Wochen nach dem Kanban-System. Ich plane, ab und zu mal ein Update hier zu posten.

Kanban – was heißt das?

Das Prinzip ist, dass sich das Team die zu erledigenden Aufgaben selbstständig nimmt und diese idealerweise nicht von einer einzelnen Person abgearbeitet werden. Entwickler nennen diese Zusammenarbeit “Pair Programming”, wir haben es in “Pair Doing” umbenannt. Die Aufgaben werden am sog. Taskboard vom Projektmanager (idealerweise; bei uns habe ich diese Rolle und ich bin dummerweise auch noch Team-Leader 🙂 ) auf Karten geschrieben und nach Priorität geordnet. Das Taskboard besteht aus drei Spalten:

“To do”, “in progress” und “done”

Jede Spalte hat nur eine begrenzte Anzahl an Karten. Die Anzahl kann vom Team bestimmt werden, sollte dann aber auch eingehalten werden.

Der Admin nimmt sich die oberste Karte aus der “To do”-Spalte und hängt diese “in progress”. Dabei schreibt er seinen Namen und die Startzeit auf die Karte. Danach ist er für diese Aufgabe “geschützt”, das heißt, dass er nur an dieser Aufgabe arbeitet und sich nicht um andere Dinge kümmern muss. Ist die Aufgabe abgearbeitet, wird die Karte mit einer Endzeit versehen und auf “done” gehängt. Bevor er sich eine neue Karte nimmt, sollte er Kollegen bei ihren Aufgaben, die noch “in progress” sind, unterstützen. Ziel des Systems ist es nämlich, eine Aufgabe schnellstmöglich von “to do” auf “done” zu setzen.

Und wo ist nun der Benefit?

Wir haben uns für Kanban aus mehreren Gründen entschieden:

* Durch die aktive Zusammenarbeit entsteht eine Redundanz. So wird vermieden, dass nur eine Person im Team die Kompetenz für ein Produkt hat
* Transparenz: Durch das offene Taskboard weiß jeder im Team, woran der andere gerade arbeitet. Das tägliche “Stand-Up Meeting” verstärkt dieses noch.
* Mehr Geschwindigkeit: Das mag kurz nach der Einführung noch nicht der Fall sein, sollte sich aber durch die Zusammenarbeit schnell einstellen.
* Erfahrungswerte: In der Software-Entwicklung hat es sich als effektiv erwiesen.

Besonderheiten im Zusammenhang mit der Administration

Wir sind nach der Implementierung von Kanban auf folgendes Problem gestoßen:

Kleine Aufgaben, die keinen Zettel am Taskboard rechtfertigen würden, müssen auch bearbeitet werden. Die erste Idee war nun, ein Zeitfenster einzurichten, in dem diese Aufgaben erledigt werden. Dieses sollte ursprünglich vormittags eingeplant werden, so dass man den Rest des Tages wieder mit den Aufgaben am Board verbringen kann. Das hat jedoch nicht funktioniert, da wir kleine Ad-Hoc-Anfragen am Tag so nicht bearbeiten konnten und auch keinen Support am Tag anbieten konnten.

Für diese “Helpdesk”-Tätigkeit sieht unsere Lösung nun so aus, dass wir ein Rotationsverfahren eingeführt haben: Jeden Tag haben wir einen anderen “Helpdesk”-Verantwortlichen, welcher primär die Helpdesk-Aufgaben abarbeitet. Dadurch sind die anderen Teammitglieder geschützt und können ihre Tasks abarbeiten. Den “Helpdesk”-Verantwortlichen des Tages kommunizieren wir mit einem Zettel vor der Abteilung. Unabhängig von Kanban haben wir sehr positives Feedback von den Usern bekommen, da nun sofort ersichtlich ist, wer der Ansprechpartner ist.

Was gibt es noch?

Kanban sieht es vor, dass jeden Tag ein sog. “Stand-Up”-Meeting stattfindet. Dabei spricht jedes Teammitglied der Reihe nach seine Aufgaben an und setzt damit die anderen Teammitglieder über den Status und evtl. aufgetretene Probleme in Kenntnis.

Ein bei uns häufig aufgetretenes Problem ist, dass eine Aufgabe nicht erledigt werden konnte, weil wir auf Feedback von anderen oder auf Lieferungen angewiesen waren. Hierfür gibt es sog. Block-Karten. Auf diese schreibt man den Grund des “Blocks” und die Startzeit und klebt die Karte über die eigentliche Aufgabe. Weiß man im Vorfeld, dass es zu einem Block kommen kann, sollte man die Aufgabe gleich feiner einteilen, so dass ein Teil der Aufgabe auf “done” gesetzt werden kann.

Zusätzlich sollte man in einem wiederkehrenden Intervall eine sog. Retrospektive führen. In dieser kann man aufgetretene Erfahrungen diskutieren. Evtl. aufgetretene Probleme werden auch auf Karten festgehalten und bis zur nächsten Retrospektive (hoffentlich) beseitigt.

Wenn ihr auch eine agile Systemintegration plant, kann Hilfe von erfahrenen Projektmanagern nicht schaden. Wir haben großes Glück mit http://twitter.com/stohh. Danke!

Im Netz habe ich noch eine Interessante Präsentation zu Kanban in der Systemadministration gefunden.

Leave a Reply