Scrum Gantt als Google Docs Sheet

Im letzten Post zum "Scrum Gantt-Chart" habe ich beschrieben was, warum und wie man aus Scrum-Daten ein Scrum-Gantt als Reporting-Tool erzeugt. Die Scrum-Planung ist weiterhin im Scrum-Backlog, aber das Management (allgemein: die Stakeholder) freut sich sicher über eine Roadmap im Gantt-Stil.

=> Implementierung das Gantt-Charts als Google Docs Sheet <=

Empfehlung:

• Sheet kopieren: GoogleDocs => Datei => Kopie erstellen...
• Das eigene Backlog im Eingabebereich auf der linken Seite einfügen
• Datum "BaseDate" und "Today" anpassen
• Zeilen und Spalten im Formelbereich an das eigene Backlog anpassen
• Jede Woche eine neue Version machen und den Stakeholdern veröffentlichen

Wenn die Spalten des eigenen Backlogs kompatibel sind, ist das eine Sache von 2 Minuten

==> Google Sheet

_happy_sheeting(:-)

Scrum Gantt-Chart

tl;dr

Ein Gantt-Chart aus Scrum-Daten verschafft mehr Überblick als ein Release-Burndown. Dazu erweitert man das Backlog um Kalenderspalten, in denen jeweils der Sprint markiert ist, in dem eine Story bearbeitet wird. Nebeneffekt: Management bekommt eine Roadmap und weiß was das Team macht. Steigert die Akzeptanz bei Gantt-verwöhnten Stakeholdern.

Das Scrum-Gantt gibt es jetzt hier als Google-Sheet.

Was

Das Gantt-Chart stammt aus der klassischen Projektplanung bei der sehr detailliert Aufgaben, Abhängigkeiten, Termine und Ressourcen verwaltet werden. Droht ein Termin zu platzen, dann bekommt die gefährdete Aufgabe mehr Ressourcen.

Das ist nicht die Sichtweise von agiler Entwicklung. Bei Scrum wird nicht von vorne herein das gesamte Projekt im Detail durchgeplant ist. Es wird nur geplant wird, was auch umgesetzt wird. Teams und nicht Ressourcen übernehmen Aufgaben. Eher wird der Scope reduziert oder ein Termin verschoben, als Ressourcen (die ja Menschen sind) umher zuschieben.

Mit der klassischen Detailplanung kann man ganz genau sagen, wie ein Projekt laufen wird, zumindest wie es laufen soll. Die Wahrheit stellt sich hinterher heraus. Und sie ist immer anders als geplant. Mit anderen Worten: die genaue Projektplanung führt nur dazu, dass man sich genau irrt. Ein Grund warum die klassische Projektplanung im Agile-Umfeld verpönt ist. Damit ist auch das Gantt-Chat, als Übersicht des klassischen Projektplans, in Misskredit geraten.

Warum

Dabei hat es das nicht verdient. Auch bei Scrum wollen Stakeholder wissen, wann was fertig wird. Scrum will die genaue Aussage darüber vermeiden. Aber trotzdem bleibt der Wunsch nach konkreten Aussagen. Das Interesse von Management und Kunden am Projektfortschritt ist berechtigt und kann mit einer Roadmap im Gantt Stil befriedigt werden. Nicht zuletzt hilft eine Roadmap-artige Übersicht auch dem überzeugten Scrum-Befürworter, rechtzeitig Scope und Termine zu steuern.

Überraschenderweise hält der Scrum-Standard alles bereit, um ein Gantt-Chart zu erstellen. Ein Gantt-Chart, das alle Anforderungen von Gantt-Chart-verwöhnten Stakeholdern erfüllt. Die Erzeugung des Gantt-Charts kann automatisiert werden. Sie kostet im Scrum Prozess nichts. Das Ergebnis ist auch nicht genauer als die bekannten Gantt-Charts klassischer Projektplanung. Aber es dient der Transparenz. Damit erfüllt es eine wichtige Funktion im Scrum. Gleichzeitig fördert das Gantt-Chart die Akzeptanz von Scrum durch wichtige Stakeholder (Management).

Hier geht es also um ein Gantt-Chart als Reporting-Tool, nicht als Planungstool. Die Planung ist komplett Scrum.

Wie

Ein Gantt-Chart aus Scrum-Daten zu erstellen ist sehr einfach. Jede geschätzte Scrum User Story hat Story Points. Die Story Points entstehen ganz normal wie bisher im Scrum Prozess. Aus vorangegangenen Sprints ist die Velocity (Story Points pro Sprint) bekannt. Die bisherige Velocity wird auch für die Zukunft angenommen.

Dann berechnet man für jede Story in welchem Sprint sie fertig wird und markiert den Sprint im Kalender. Done.

Daraus ergibt sich ein Backlog mit zusätzlichen Kalenderspalten in denen jeweils die Felder markiert sind in denen eine Story in Arbeit ist und/oder fertig wird. Das sieht dann so aus:

Bonus

Zusätzliche Ideen aus der Praxis:

• Abgeschlossene, "in Arbeit" und zukünftige Stories farblich unterscheiden.
• Zukünftige Velocity = letzte Velocity modifiziert durch Sondereffekte wie Urlaub.
• Ein zusätzliches Datumsfeld je Story, das angibt für wann ein Feature dem Kunden/Management "versprochen" wurde (Soll-Datum). Das Datum wird im Kalender markiert. Soll/Plan/Ist-Angaben helfen der Transparenz.
• Epic Stories weiter unten im Backlog können auch mal über mehrere Sprints gehen.
• Zusätzlich zur Scrum-Beschreibung der Story (Wer, Was, Warum) kann man einen kurzer Titel/Namen der Story vergeben. Das hilft der Übersichtlichkeit im Gantt-Chart.
• Bewährt hat sich eine eigene Hintergrundfarbe für Releases. Das sind oft Gruppen von Stories, die aus einem Epic hervorgegangen sind. Damit kann man Stories zu "Releases" oder "Milestones" gruppieren. 

Das Scrum-Gantt gibt es jetzt hier als Google-Sheet.

_happy_charting()

Neue Wege im IT-Management: Artikel im VentureCapital Magazin 12/2009

Im aktuellen Heft vom VentureCapital Magazin ist mein Artikel über Scrum erschienen (Volltext wegen Copyright nicht frei verfügbar).
Keywords: IT-Management Agile Entwicklungsmethoden Investoren Internet-Startups Softwareentwicklung Pitch Projektsteuerung Scrum Cloud-Computing Open Source Kapitalgeber Time to Market Scrum eliminiert Unproduktivität "The Mythical Man-Month" Frederick Brooks wenige Funktionen Output mit Scrum verbessert Scrum-Prinzipien doppelte Geschwindigkeit Games- und Internetbereich Microsoft, Intel, Yahoo, Accenture, Adobe und GE Healthcare Enfant Terrible Mainstream Jeff Sutherland OpenView Venture Partners Venture Capitals Erfolgschance Investments Qualität Effizienz Due-Diligence Prüfung Impediments Hindernisse Heiner Wolf Gründer CTO virtuelle Welt weblin 3 Mio. User Chief Scientist Open Virtual World Projekt Social Games und Virtual Goods

IT-Projekt der Bundeswehr in der Krise. Wie dumm kann man sein?

Die neue Nachricht: "beim IT-Projekt Herkules der Bundeswehr ufern die Kosten aus".

Eigentlich nicht ganz so neu. "Bereits im Juni hatte ein interner Bundeswehr-Bericht dem Projekt eine verheerende Bilanz ausgestellt".
Aber: Herkules kam in diesem Blog schon vor 5 Jahren vor: Grosse Softwareprojekte in der Krise.

Besonders interessante Fakten:

• IBM, Siemens und der Bund haben für das Projekt ein Joint Venture gegründet
• Seit 5 Jahren ist das Projekt in der Krise, aber Führungskräfte haben auch dieses Jahr Boni bekommen
• Der Bund hat nichts zu sagen, da er nur 49 % der Anteile hält
• Das Projekt "lässt sich inzwischen nicht einmal mehr kalkulieren"
• Ministerium: Grund für steigenden Kosten ist fehlender Wettbewerb

Ist eigentlich schon jemand aufgefallen, dass der Bund 100% zahlt. Bei jedem Drecks-Startup setzen Investoren, die 30 % zahlen, jemand in den Aufsichtsrat. Ab 50 % Finanzierung haben sie gerne die Mehrheit im AR.

Der Auftraggeber hat den Dienstleistern gestattet, eine Abwicklungsfirma zu gründen. Wahrscheinlich hat jemand das dem Bund empfohlen, "um alles zu bündeln". Aber die wichtigste Eigenschaft dieser Firma ist, dass man sie einfach dicht machen kann, falls etwas schiefgeht. Der Bund kann dann nicht mal gegen den Auftragnehmer klagen. Der ist ja dann gelöscht. Siemens/IBM sind fein raus. Eine speziell gegründete GmbH ist DIE Methode, um Verantwortung abzustreifen. Das weiss doch jeder.

"Der fehlende Wettbewerb lässt die Kosten explodieren", hä? Was erwartet man denn, wenn man eine Firma mit der Abwicklung von mehreren Milliarden Euro beauftragt. Wo soll der Wettbewerb denn herkommen?

Wer hat eigentlich diesen Vertrag verhandelt? Das ist ja nicht nur Dummheit, sondern Untreue. Vielleicht sollte man sich mal anschauen wo das Management vorher gearbeitet hat. Ob da nicht jemand aus dem Ministerium rüber gewechselt ist und jetzt gut verdient.

Wie wäre es mit einer parlamentarischen Anfrage: Arbeitet jemand, der auf Seite des Bundes den Auftrag verhandelt hat, jetzt beim Joint Venture oder bei IBM/Siemens?

_happy_moneywashing()

High-tech Businesslogik bei bluehands

Am Freitag habe ich meine alte Firma bluehands in Karlsruhe besucht und ich bin sehr beeindruckt. Bluehands macht Softwareentwicklung auf hohem Niveau. Die Kernkompetenz liegt bei der Umsetzung von Projekten mit .NET für Webanwendungen, Datenbank- und Backend, sowie komplexe branchenspezifische Businesslogik. "Umsetzung" ist dabei ein zentrales Wort. Denn das beginnt bei der Planung und Denken mit und für den Kunden und endet erst wenn das System im Produktiveinsatz läuft.

Selten habe ich so "dichte", kontrollierte und hochwertige Softwareentwicklung gesehen. Die Zahl der Projekte ist beeindruckend. Die hohe Qualität bei dieser Geschwindigkeit ist nur zu halten durch Agile Entwicklungsmethoden und ständige Innovation. Mittel wie Scrum, Nightly Builds, Unit Tests, automatische Codeanalyse, Versionskontrolle, DRY, KISS, Continuous Integration sind selbstverständlich. Dazu kommen Research-Projekte, Coder-Seminar, Effizienzanalyse und interne Weiterbildung. Aktuelles Beispiel: die Clean Code Developer Initiative.

Wer also eine Visualisierungslösung braucht, z.B. im Energiebereich oder in verarbeitenden Gewerben, wie Metall und Bau, oder ein komplexes Planungstool, wer will, dass bei der Planung mitgedacht wird und, dass das System installiert wird und dann läuft, dem kann ich www.bluehands.de nur empfehlen.

Und wir anderen Coder (zumindest die meisten) können da noch was lernen. Wir sind ja auch nicht schlecht organisiert (zumindest die meisten), aber da kann man sich eine Scheibe von abschneiden. Das ist den Jungs bei bluehands selbst wahrscheinlich gar nicht so bewußt. Two thumbs up.

happy_coding()

Reverse Engineering Requirements from Solutions

I just read an article about Planning For Fun In Game Programming. It starts with a discussion of requirements and solutions. The essential is:

"It can be compelling to write solutions instead of requirements. It is tempting to design a solution to a requirement at the same time as writing the requirement -- especially the interesting ones! Writing solutions feels more authoritative, more formal, more precise and more accurate. But it is counterproductive. By prescribing a given solution, we preclude any potential superior solutions. Prescribing solutions also limits our understanding of the problem domain and intent of the requirement."

This is so true.

Programmers and especially lead developers work by requirements. The lead developers plans and the programmer implements to meet the requirements. But very often the so called requirement paper comes as a series of solutions. Business development, product management, sales, and marketing know what users need. They offer their advice about the next killer feature or the next product in form of requirements papers. Sometimes they even explain in detail what needs to be implemented with examples. This is the point where requirements turn into proposed solutions. This is done in good faith, but with the risk as described in the article above.

(symbolic)

My favourite example is:

Cast:
Development (a lead developer)
Marketing (any other non-technical person)

Marketing: "can we add a cookie?"
Development: "yes, we can."
Marketing: "... and then we can always recognize a user?"
Development: "wait, do you want a cookie or do you want to recognize the user?"
Marketing: "recognize the user!"
Development: "but you said cookie."
Marketing: "It thought this is the same."
Development: "Not in our case, because this is not a Web application."

This is a short example, solved in 2 minutes. But the same problem can easily waste weeks of development time in more serious cases. Whatever Development gets, it is always the task of Development to understand the problem, not the proposed solution. If Development slavishly implements a proposed solution and it turns out to be the wrong solution, then it is the fault of Development.

Marketing tries to specify problems as good as it can. If it is very good, then we (Development) get a requirements document. Otherwise we get solutions. Usually we get a mixture, which is the best case. But we must not fall victim to proposed solutions and examples.

Whatever we get, it is our responsibility to "reverse engineer" the problem. To find out what they really want in order to produce the optimal result. We must not hide behind "their" requirements document and just do. Proposed solutions are just a tool to understand the real problem. It is our job, because we can.

happy_backtracking()