Archive | August, 2012

Was können Softwareteams von Fußballteams lernen? Das Spiel

27 Aug

Das Spiel dauert 90 Minuten und für professionelle Teams findet es mindestens einmal die Woche statt. Softwareteams dagegen machen keine Pause ein Sprint dauert typischerweise zwischen einer und vier Wochen. Trotzdem können wir Entwickler noch einiges über Agilität von den Fußballern lernen. Im Fußball sind die Feedback-Zyklen viel kürzer, aber dazu später. Fangen wir mit dem Ursprung des Fußballs an, der in England stattfand:

1. Kein Kick and Rush

Früher wurde in England “Kick and Rush” gespielt, also schießen und stürmen. Das war die Taktik. Damit kommt man heute im Fußball nicht mehr durch. In der Softwareentwicklung sollten wir ja nicht ungefragt nur den Anforderungen der Person hinterherlaufen, die am lautesten schreien kann. Dadurch geraten ältere Backlog-Aufgaben, Fehler, Anforderungen von anderen Personen und eigene Produktvisionen aus dem Blick. Das Team sollte gemeinsam alle Aufgaben im Blick haben und gemeinsam mit allen Stakeholdern die Wichtigkeit einzelner Aufgaben erkennen und die eigenen Ideen nicht vergessen. Ein Komitee hilft dabei.

2. Taktik während des Spiels anpassen

Fußballer haben keine Probleme ihre Taktik während eines Spiels anzupassen. Der Trainer entschiedet, dass es in der aktuellen Spielphase besser ist, den Sturm zu stärken, also spielt man einfach offensiver. Nur so kann man ein Spiel gewinnen: Measure, Learn, Adapt. Auch im Softwareprojekt sollten wir schnell reagieren können. Wenn unser neues Feature nicht vom Kunden angenommen wird, sollten wir es verändern, schauen ob es damit besser geht und weiter verbessern. Es gibt aber immer noch genug Menschen in der Softwarebranche, die glauben, dass man durch eine lange Analysephase genau weiß, was man entwickeln soll. Das klappt weder in der Softwareentwicklung noch im Fußball. Zugegeben: Beim Fußball ist das Feedback viel schneller und direkter (Wenn wir beispielsweise den Sturm stärken, erkennen wir eventuell schnell Schwächen in unserer Abwehr). Wir sollten also Mechanismen in unser SOftware oder unsere Entwicklung einbauen, um schneller Feedback zu erhalten. Ich werde dazu in den nächsten Wochen hoffentlich noch mehr schreiben. Der JIRA Issue Collector oder JIRA Mobile Connect sind aber gute Beispiele dafür, wie man auf einfache Weise schnell Feedback einsammeln und in die Entwicklung rückkopplung kann.

3. Neue Ideen in Freundschaftsspielen testen

Will ein Trainer eine Taktik ausprobieren, wird diese im Freundschaftsspiel getestet. Auch wenn es hierfür keine Punkte in der Bundesligatabelle gibt, sind diese Spiele doch sehr wertvoll. Ob die Änderungen im späteren Punktspiel verwendet wird, ist dabei nicht wichtig. Auch die Erkenntnis das etwas nicht funktioniert, hilft dem Trainer und der Mannschaft. Warum gönnen wir den Softwareentwicklern keine oder wenig Zeit neue Sachen auszuprobieren? Es gibt wenige Unternehmen, die Ihren Mitarbeitern Zeit geben, neue Ideen in Prototypen umzusetzen. Xing führt beispielsweise unternehmensweite Prototype Tage durch, Atlassian macht jedes Quartal ein Ship-It Tag. Ohne Innovationen können wir nur auf das reagieren was andere machen.

4. Die Besprechung nach dem Spiel

Beim Fußball gehört die Spielanalyse zu jedem Spiel dazu. Am nächsten Tag wird das Match gemeinsam mit allen Spielern noch einmal analysiert: Was ist gut gelaufen, was können wir im nächsten Spiel verbessern? Nur so steigert man sich als Team! Ich habe das Gefühl, dass Retrospektiven oder Kaizen immer noch nicht regelmäßig und ernsthaft in Teams durchgeführt werden. Warum gehört es nicht am Sprintende dazu, noch einmal darüber zu sprechen, was gut gelaufen ist und was man im Ablauf besser machen kann? Hier können wir sehr viel von Fußballteams lernen!

5. Feier den Sieg

Hat man den Klassenerhalt geschafft, die Champions League Qualifikation erreicht oder vielleicht auch die Meisterschaft gewonnen, wird gefeiert. Es ist Zeit, sich selbst und das Team für die harte Arbeit zu belohnen. Wenn eine Softwareversion oder ein größeres Feature released oder deployed wurde, sollten wir auch eine kleine Feier organisieren. Mal locker als Team zusammensitzen und auf den Erfolg blicken. Wir machen das viel zu wenig. Nach einem erfolgreichen Release schauen wir viel zu schnell auf das nächste, anstatt mal kurz anzuhalten und den Moment zu genießen.

Lust auf noch mehr Parallelen zwischen Fußballspielern und Softwareteams? Hier ist mein Team-Vergleich-Post.

Tags: , , ,

Was können Softwareteams von Fußballteams lernen? Das Team

16 Aug

Seit der EM im Juni, habe ich über Fußballteams nachgedacht und einige parallelen zur agilen Softwareentwicklung entdeckt. Es gibt einiges, was im Fußball gang und gebe ist, wir aber in der Softwareentwicklung noch nicht alle begriffen haben. Die ersten 5 Punkte behandeln das Team. In einem folgenden Blogpost geht es denn um die Taktik vor und während eines Spiels:

1. Spezialisierung auf Sturm macht Sinn, ist aber kein Zwang

Wenn ein Abwehrspieler alleine mit dem Ball vorm Tor steht, sollte er schießen!  Ja es gibt Spezialisten dafür (die Stürmer). Was aber, wenn der gerade nicht da ist? Im Fußball ist die Entscheidung klar: Schießen! Wie sieht’s in der Softwareentwicklung aus? Sollten wir nicht auch der QA helfen, wenn Not am Mann ist? Natürlich! Auch wenn jemand sich hauptsächlich um das Design kümmert, nützt es doch nichts, wenn die Software aufgrund eines Aufgabenstaus bei den Testern nicht released werden kann. Wir müssen dabei genau wie auch beim Fußball nicht gleich alle Generalisten werden. Das Fußballteam will gewinnen und wir wollen gute Software ausliefern.

2. Der Torwart ist ein Spezialist

Genau das widerspricht sich mit Punkt 1, erinnert mich dennoch an die QA-Rolle bei Atlassian. Der Torwart organisiert die Abwehr. Er ist eigentlich der spielende Coach für die Abwehrspieler. Er greift als letzter Mann ein, wenn seine Abwehr den Ball nicht unter Kontrolle bekommt. Er ist also der letzte Mann, der uns vor der Niederlage bewahren kann. Bei Atlassian sind es auch nicht die QA Mitarbeiter, die ausschließlich testen. Sie koordinieren und helfen den Entwickler, die dann letztendlich die Tests durchführen. Wenn es aber ein wenig schwieriger wird, oder bei Ressourcenmangel, springen die QA-Mitarbeiter ein, und führen die Tests selbst durch. Genau wie beim Torwart, der auch nur in den brenzlichen Situationen eingreifen muss.

3. Das Team hat das gleiche Ziel

Gute Teams wissen, wo Sie hinwollen. Im Fußball kann man die Teamleistung gnadenlos sehen. Anhand der Tabelle. Schwarz auf Weiß. Das Feedback, ob ein Spiel gut war oder nicht, bekommt man sofort nach dem Spiel. Das hilft, das Fußballteam auf das Ziel Klassenerhalt, Meisterschaft, Champions-League oder was auch immer, einzuschwören. Alle müssen ihren Teil dazu beitragen, das Ziel zu erreichen. In der Softwareentwicklung sind die Ziele meist nicht so klar und eindeutig auszumachen. Jeder Entwickler sollte die Vision eines Produktes kennen. Jeder sollte sofort wissen, wie nah man der Vision schon gekommen ist und welche Featureideen uns eher von der Vison abbringen. Ändert sich das Ziel, muss das Team dies wissen. Alle User Stories, die in der Sprintplanung besprochen werden, sollten auf das Erreichen der Vision ausgerichtet sein.

4. Der Trainer ist für die Vision verantwortlich

Das Fußballteam konzentriert sich auf das nächste Spiel. Es kennt zwar die Vision des Vereins und hilft dabei dies zu erreichen, allerdings richtet der Trainer die Taktik der Mannschaft aus: Er schont Spieler vor einem schweren Spiel oder trainiert Standards, da das nächste gegnerische Team damit Probleme hat. Auch in agilen Teams sollten die Entwickler das Ziel kennen, es ist aber meist der Produktmanager oder Product Owner, der den Überblick behält. Sie legen fest, was für den nächsten Sprint geplant wird. Somit können sich die Entwickler auf die Fertigstellung der Aufgaben und wie sie diese umsetzen wollen, konzentrieren.

5. Für jede Position, sollte es einen Ersatzspieler geben

Der Trainer macht die Mannschaftsaufstellung. Für jede Position setzt er einen Ersatzspieler auf die Bank. Wenn während des Spiels der Stürmer verletzungsbedingt ausfällt, kann er den Ersatzstürmer von der Bank einwechseln. Auch bei der Softwareentwicklung ist es immer gut nicht nur einen Datenbankspezialisten im Team zu haben.  Verlässt dieser das Unternehmen oder ist aufgrund von Krankheit oder Urlaub nicht da, hat man ja noch Ersatz. Auch wie bem Fußball ist es immer schwierig Starentwickler zu ersetzen, aber letztendlich geht es um das Team.

Anforderungen, Epics & User Stories festhalten – The Atlassian Way

6 Aug

Ich werde oft (meist von größeren Firmen) angesprochen, wie wir uns denn das Aufschreiben von Anforderungen mit JIRA vorstellen und wie wir das bei Atlassian handhaben. Jetzt  ist es so, dass bei uns die verschiedenen Teams auch verschiedene Vorgehensweisen haben, deshalb kann es sein, dass man auf bei Atlassian auf Teams trifft, die eine andere Vorgehensweise bevorzugt… und das ist völlig in Ordnung (Agiles Manifesto: Individuen und Interaktionen über Prozesse und Werkzeuge)

User Story Doku – so machen wir es

Wir schreiben meistens nur einen Einzeiler als User Story auf (Als (A) möchte ich (B) machen, so dass (C)…). Dann erzeugen wir damit einfach einen Issue in GreenHopper/JIRA  und bauen darauf auf. Wir vermeiden es, Spezifikationen zu schreiben. Wenn man das Problem in kleine Häppchen zerteilt und Einzelheiten dokumentiert, fällt meistens auf, dass man ziemlich offensichtliche Sachen dokumentiert, die entweder für jeden im Team klar sind oder die viel einfacher durch ein Mockup beschrieben werden können.

Aber gerade wenn man mit einem größerem, nicht mehr ganz frischen Softwareprojekt zu tun hat, muss man mehr Sachen berücksichtigen, als in einer Zeile in einer User Story steht. Also packen wir mehrere User Stories in eine Wiki-Seite und diskutieren diese.

Hier sind die Vorteile, die wir mit diesen Ansatz sehen:

1. Eine Seite, eine Quelle, ein Problem

Keep it simple! Normalerweise haben wir eine Seite mit dem Epic. In dieser Seite werden alle User Stories zu diesem Epic aufgeführt. Alles auf einer Seite zu haben, hilft dem Auffinden von Informationen ungemein.

Zusätzlich pflegen wir noch eine “Machen wir nicht”-Liste auf dieser Seite. Dies ist extrem wichtig, damit alle den Umfang des Epics verstehen. Dadurch versuchen wir zu vermeiden, dass falsche Erwartungen geweckt werden und es hilft dem Team beim Fokussieren und dem Management besser zu verstehen, was gemacht wird und was nicht!

2. Flexible Struktur

Der Vorteil von einem Wiki gegenüber einem Tool zum Anforderungsmanagement, ist die Agilität in der Dokumentation. Man muss nicht immer alles machen, was ein Tool einem vorschreibt. Mach, was du auch wirklich nur benötigst und sei agil!

3. In Details eintauchen

Verlinken ist eine Basisfunktion eines Wikis. Wir benutzen es häufig. Man könnte beispielsweise zu folgenden Details verlinken:

  • Kunden Interviews, um den Kontext darzustellen
  • Seiten und Blogposts von ähnlichen Ideen
  • vorausgegangene Diskussionen oder technische Dokumente
  • Links auf externe Informationen

Damit kann man ein einfaches Dokument erstellen und der Benutzer kann in die Tiefe der Informationen eintauschen.

4. Lebendige Dokumentation = Lebendige Stories

Auch unsere Kunden nutzen dieses Feature häufig: Ist erst mal das Gerüst für ein Story fertig, wird oft die JIRA Integration von Confluence genutzt: Aus der Seite heraus werden GreenHopper Stories erzeugt. Diese werden dann automatisch in Confluence angezeigt und man kann den Fortschritt von hier aus beobachten. Wenn also die Entwickler die Storie fertig haben, kann man das direkt con der Wiki Seite aus sehen.

5. Die Weisheit der Masse

Gerade in größeren Unternehmen erreicht man mit einer Dokumentation in einem Wiki, dass Mitarbeiter aus anderen Abteilungen an Diskussionen teilhaben und ihre Ideen teilen können. Es ist immer wieder faszinierend zu sehen, dass Kollegen aus anderen Teams tolles Feedback geben und Anregungen einbringen, an die man noch gar nicht gedacht hat.

6. Zusammenarbeit!

Der wahrscheinlich wichtigste Aspekt an dieser Vorgangsweise ist der, dass alle involviert sind. Schreibe niemals eine Spezifikation allein. Teile deine Ideen mit dem Team und sammle das Feedback. Kommentiere, stell Fragen, involvier andere in die Diskussion. Besonders wichtig ist dies für verteilte Teams!

7. Gestalte deine Stories ansprechend

Benutze Tools wie Gliffy oder Balsamiq, um besser Probleme darzustellen oder füge Bilder, Videos oder anderen interaktive Inhalte hinzu. Tu was immer notwendig ist, um das Problem klarer mit deinen Team zu kommunizieren.

Herausforderungen – das haben wir gelernt

Und jetzt einige Herausforderungen, die wir mit dieser Vorgehensweise haben:

1. Dokumentation hat die Tendenz veraltet zu sein

Was passiert, wenn du Feddback für ein Feature bekommst und du es daraufhin änderst. Passt du die Dokumentation an? Das ist ein große Herausforderung mit jeder Art von Dokumentation.

2. Eine offene Diskussionskultur

“Wie schaffe ich es, dass Leute meine Seite kommentieren?”, “Wie motiviere ich Mitarbeiter, mehr Spezifikationen und Stories im Wiki festzuhalten?”. Dies kann wirklich schwierig sein. Wir haben eine Seite mit Tipps, die vielleicht helfen können, eine bessere Akzeptanz für das Wiki zu generieren.

3. Fang an

Auch wenn wir dazu raten, dass jeder sein eigenes Format wählen sollte, brauchen einige Leute doch manchmal ein Richtlinie oder ein Template. Also fang an und schreib eine Anleitung oder auch schon das erste Beispiel-Epic ins Wiki und versuch deine Kollegen bei der Erstellung zu beteiligen.

Vielen Dank an Sherif Mansour für die vielen internen Infos.

Tags: , , , , , , , ,

Follow

Get every new post delivered to your Inbox.

Join 26 other followers