Scrum@Work

Auf der Suche nach Infos zu Selbstorganisation und Command & Control, bin ich auf diesen, zwar etwas älteren, aber sehr interessanten Artikel bei www.joelonsoftware.com gestoßen.

Er erläutert, warum Command & Control, trotz seines breiten Einsatz in der “Kriegsbranche” nicht für die Software Entwicklung taugt. In Kürze nennt er folgende wichtigen Punkte:

1. der Software Entwickler im Allgemeinen ist etwas sind eine recht gebildete Spezies und wissen vieles oft besser. Das ist nicht ironisch gemeint – sie haben wirklich oft recht. Diese Spezies ist rel. schwierig mit Kommandos ohne allzugute Begründung zu überzeugt.
2. Das nächste Problem ist, dass die Standard-Aufgaben in der Software Entwicklung wesentlich komplexer sind, als die Standard-Aufgaben beim Militär. “Rechte Flanke zum Angriff”, kann ich 100 Leuten zurufen und man kann davon ausgehen, dass jedem einzelnen klar ist, was zu tun ist (weil es sich um wiederholende Tätigkeiten handelt). Bei “Entwickelt das Web Frontend!” ist das schon schwieriger. Hier braucht man ein Team, das in der Lage ist, sich auf neue Gegebenheiten einzustellen – und zwar jeder einzelne. Der Manager des Teams wird nicht in der Lage sein, sich kontinuierlich um jedes einzelne Teammitglied zu kümmern, sondern immer nur sehr kurz (er hat ja noch die anderen Teammitglieder).
3. das letzte Argument greift auf das Erste zurück. Die Software Entwickler sind die, die am besten Bescheid wissen, was zu tun ist. Der Manager kann dies im Detail oft gar nicht wissen (schließlich haben sich ein paar sehr intelligente Leute den Kopf darüber zerbrochen und damit einen Wissensvorsprung gegenüber dem Manager).

Der IT Manager kann sich also nicht auf Command & Control verlassen, weil er zwingend Mitarbeiter braucht, die selbst in der Lage sind, zu denken und zu handeln (zumindest Ersteres versucht man beim Milität auf das zwingend notwendige zu begrenzen).

Ein IT Manager, der seinen Leuten alles vorkaut und vorgibt rennt in eine Sackgasse und wird sich auf Dauer immer mehr im Micromanagement verfangen.

Ein IT Manager, der dagegen ein selbstorganisiertes Team hat weiss, dass er sich auf das Team verlassen kann, und kann sich um strategische Themen kümmern.

Heiko Uncategorized

Nachdem unsere Buttons am Scrum Gathering gut angekommen sind und wir Nachfragen erhalten haben, ob es noch mehr gibt:

pimpyourscrum.cybermanufaktur.de

Heiko Uncategorized

Ein etwas unerwarteter, aber durchaus positiver Effekt, wurde in der letzten Retro deutlich. Ein neues Teammitglied hob’ hervor, dass das Team ihr ständig helfen würde und sie auf alle Fragen sofort eine Antwort bekommen würde. Mit  “das kenne ich auch anders” klebte Sie das Post’It an die “Was lief gut”-Wand.

Auch dem Team ist aufgefallen, dass es sehr einfach ist, Sie mit Arbeit zu “versorgen”.

Mir ist aufgefallen, dass das früher anders war. Da musste man sich als Teamleiter immer darum kümmern, dass neue Mitglieder betreut wurden und dass sie mit der “richtigen” Arbeit versorgt wurden. Ein nicht immer ganz einfacher Job, der gerne auch dazu führte, dass man den “Neuen” uneffektive Arbeit zuteilte – Hauptsache, sie waren “versorgt”.

Scrum und der Fokus auf “Selbstorganisiertes Team” sorgt für ein ganz anderes und viel besseres Umfeld, neue Teammitglieder in ein Team zu integrieren. Damit sinkt die Gefahr, dass ein Team durch die Änderung in die Formingphase der Teamuhr zurückfällt.

Das Team und der neue Mitarbeiter sind sehr viel schneller produktiver, als früher!

Heiko Uncategorized