Agile is the new black - Nachlese zur Railsberry 2013

Prägend war der Vortrag insbesondere nicht, weil ich seiner Argumentation einfach zustimmen und folgen würde, sondern da diese teilweise provokant waren und daher zum Nachdenken animiert.

Ich mag hier jetzt nicht die gesamte Präsentation wiederholen, denn das würde den Rahmen eines Blog-Artikels sprengen. Davon abgesehen kann man die Slides von Fred auch hier finden. Doch ich möchte zumindest ein paar der interessantesten Aspekte herausgreifen und kommentieren.

Lange Vorrede, vielleicht noch gar nicht so viel Sinn…

Agile is agile…at least it should be

Der Titel des Vortrags bezieht sich auf das aus der Mode entlehnte und im Marketing-Speak gern missbrauchte “X is the new Y”, und Fred will klar machen, dass Agile Entwicklung nicht einfach nur das neue Y ist. Agile sollte im eigentlichen Wortsinne agil sein. Agile ist also nicht das neue “Wasserfall” oder dergleichen. Agile ist nicht ein Zustand in dem man sich befindet, sondern auf den man sich zubewegt, so abgedroschen und zenmäßig es vielleicht klingen mag. Ein Team ist nicht agil, weil es sagen kann “Wir arbeiten nach Scrum”, sondern wenn es in seinem Tun beweglich ist und agil bleibt.

Interessant ist nun, welche Konsequenzen man aus einer solchen Aussage ziehen kann oder gar sollte. Fred hat dazu seine persönlichen Agile-Smells definiert und sich mit der Agile-Score-Card ein Punkte-System für diese ausgedacht.

Team-Rollen

Die definierten Rollen sollten nach Fred auf das absolute notwendige Minimum reduziert werden. Die wesentlichen Personengruppen in einem (Agile-)Projekt-Team sind bekanntlich: Business, Management, Development. Und jede dieser Gruppen sollte möglichst wenige Rollen beinhalten.

Beispielsweise benötigt man im Bereich Management vielleicht nur einen “Gesamt Projektmanager” und einen “Iteration Manager”. Ein besonders schön provokantes Zitat zum Thema unnötige Management-Rollen möchte ich nicht unterschlagen:

Das ist nicht nur provokant, sondern schießt etwas über das Ziel hinaus. Wie ein anderer Teilnehmer (@sunny_io) der Railsberry so schön und richtig, so oder so ähnlich, gesagt hat:

Doch die Idee hinter der Reduktion der Team-Rollen ist denkbar einfach: Jede zusätzlich Rolle kann dazu führen, dass das Team an Agilität verliert. Frei nach dem “Motto viele Köche verderben den Brei.”

Konkret kann eine zu extreme Aufteilung der  Developer-Rolle in Front-End (und das kann man auch noch aufdröseln, z. B. in Template-Bauer, JavaScrtiptler, etc.), Back-End (dito) zu möglicherweise blockierenden Reibungsverlusten bei der Übergabe bzw. Abstimmungen zwischen diesen Rollen führen.

Für die Agile-Score-Card: Jede gesparte bzw. gestrichene Rolle +5 Punkte. Jede neue Rolle -10 Punkte.

Poly-skilled Developer

Quasi ein unmittelbares Ergebnis der obigen Überlegungen zu den Team-Rollen ist, dass insbesondere das Development Team mit möglichst vielen “poly-skilled developer” besetzt sein sollte. Poly-skilled meint Entwickler, die zum Beispiel nicht nur entweder mit der Datenbank oder dem HTML/CSS umgehen können, sondern im Extremfall mit beiden und allem was dazwischen liegt. Der Vorteil ist, dass ein Entwickler (oder auch ein Entwickler-Paar) ein Feature komplett und ohne Weitergabe-Abstimmungen in einem Rutsch umsetzen können.

Den Entwickler, der von allen DB-Systemen bis hinzu den CSS-Zicken aller Browser alles kann und alles weiss, findet man nicht ganz so leicht, und sicherlich gibt es Themen, für die ein tiefes und spezialisiertes Wissen von Nöten sein wird. Doch sind Team-Mitglieder, welche über mehrere Bereiche hinweg Themen bearbeiten können, sicherlich ein Gewinn für jedes Projekt.

Tools

Achtung vermeintliche Trivialitäten!?

Tools sollten uns helfen. Sie sollten uns helfen agil zu sein, sollten uns helfen unsere Beweglichkeit zu behalten, sollten uns nicht zwingen ein Problem nur aus einer Blickrichtung zu betrachten, muss nicht teuer sein um gut zu sein…Tools sollten leichtgewichtig sein, sonst sperren sie das Team ein.

Einfaches Beispiel: Story-Cards aus Pappe an einer Pinwand liefern mehr Information und schränken die Beweglichkeit eines Teams weniger ein, als irgendein mit teuren Lizenzen belegtes Prozessteuerungwegzeug.

Fred verteilt hier die Punkte nach den Kosten pro Tools:  Weniger als $50 gibt +20 Punkte.  -10 Punkte bei mehr als $200 . Mehr als $1000 schlägt -25 Punkte auf.

Agile Process Guides

Dieser Punkt schlägt in eine ähnliche Kerbe wie das Thema Tools, beziehungsweise ist es eine erste Präzisierung desselbigen.

Fred ist der Meinung, dass ein Guide immer zur Einschränkung der Agilität führt und daher vielleicht besser vermieden werden sollte.

Ich persönlich denke, ein solcher Guide kann hilfreich und sogar notwendig sein. Gefährlich und der Agilität wirklich abträglich wird er aber erst, wenn man ihm einfach unreflektiert, buchstabengetreu folgt und wenn dieser Guide, wie die 10 Gebote in Stein gemeißelt für alle Zeit gelten soll. Das Dokument muss selbst leben und muss sich evolutionär entwickeln. Ein gemeinschaftlich pflegbares Dokument ist aus meiner Sicht in der Tat zu bevorzugen. Doch sollte man dennoch Vorsicht walten lassen, sich nicht zu arg in der Diskussion um Details des Prozesses zu verstricken. Ein solcher Guide sollte vielleicht im Sinne einer Orientierungshilfe nur grob den Rahmen abstecken, aber nicht als schrittweise Handlungsanweisung im Sinne eines Algorithmus das Tun exakt vorgeben.

Agile-Score-Card: +20 Punkte wenn man keinen Guide hat. Immerhin +5 wenn es ein von allen pflegbares Wiki ist. -10 Punkte für ein geschlossenes Wiki. Und -25 Punkte für ein fixiertes PDF-Dokument .

Bug Tracking

Freds Kernaussage zum Thema Bug Tracking

“Don’t track bugs, fix them.” An zwei Fallbeispielen hat er deutlich machen können, dass das Tracking von Bugs die Gefahr birgt, dass die “Time to fix” unnötig lang wird. Ich stehe dem ganzen mit gemischten Gefühlen gegenüber. Einerseits gebe ich Fred recht: nur ein gefixter Bug ist ein guter Bug. Andereseits halte ich es für wichtig, dass zumindest eine Art von Dokumentation zu einem Bug existieren sollte. Zur Not nur, um die Existenz des Fehlers und auch die angefallen Aufwände zu erfassen. Wie gesagt, ich bin da selbst noch etwas unschlüssig, wo und wie hier das rechte Maß zu finden ist.

Agile-Score-Card-Punkte von Fred: Kein Bug-Tracking +25 Punkte. -10 Punkte, wenn Bugs getrackt werden. -25 Punkte, wenn man sogar Bug-Meetings abhält.

Zu guter Letzt

Wie bereits in der Einleitung erklärt konnte  ich jetzt bei weitem nicht alle spannenden Themen aus Freds Vortrag beleuchten. Das kann ich ja in einem kommenden Post noch nachholen. Die angegebenen Punkte sind die, die Fred auf der Railsberry angegeben hat. Diese sind nicht auf SlideShare enthalten, da natürlich auch diese, agilen Veränderungen unterworfen sind.

An dieser Stelle komme ich nicht umhin mich natürlich ganz herzlich bei Fred zu bedanken.

 thanks again for your inspiring talk, your insights, your support and efforts in sharing your agile-score-point slides with me.

Ich hoffe, ich konnte nach der Vorrede etwas Sinn oder zumindest Anregung zum weiteren Nachdenken liefern.

Ich freue mich über euere  Kommentare, Diskussionen und Anregungen.

Stay curious and use the source…