Solche Meilensteine aus einer Rückwärtsplanung zu gewinnen, ist völlig in Ordnung. Deren Zahl ist ja auch übersichtlich, so dass sie notfalls sogar in ein Gantt-Chart passen.

Anschließend mit einer schlanken Vorwärtsplanung auf so einen Meilenstein hinzuarbeiten und dabei den Wert der früh gelieferten Features so zu maximieren, dass am Ende auch etwas “hinten runter” fallen darf, ist m.E. die eigentliche Kunst. Und zwar nicht, weil er keine Verfahren dafür gäbe, sondern weil es gilt, die Menschen im Projekt zu dieser Denkweise zu bringen. “Was, wir im Fachbereich sollen JETZT schon testen? Das machen wir doch immer erst kurz vor Projektende, also etwa heute in zwei Jahren!”

Da habe ich als Coach dann jeweils meine Aufgaben…

Anwenderschulung: Wir halten am ersten Tag mal 1h Anwenderschulung mit etwas Inhalt und messen, wieviel der Anwender davon kapiert. Daraus extrapolieren wir, wann wir mit den Anwenderschulungen für unsere 300 User anfangen müssen

Ich bestreite ja gar nicht, das agile Verfahren die beste und genaueste Vorwärtsplanung für ein Projekt liefern. Was aber fehlt ist die Rückwärtsplanung, und vor allem der Abgleich zwischen Vorwärts- und Rückwärtsplanung. Dazu gehören eben auch Aufgaben wie Anwenderschulung, Beschaffung von Hard- und Software, Steuerung von Dritten. Mit Meilensteinen meinte ich nicht Deploy und GoLive!

Und da sind agile Verfahren im Moment noch auf Unterstützung aus dem klassischen Projektmanagement angewiesen. Werder CFD noch Burn-Down-Chart helfen hier weiter.

danke für die schöne pointierte Antwort! Ich habe erst einmal lachen müssen über das schöne Bild mit dem Globus.

Ich könnte Ihnen jetzt Recht geben: Gantt kann bei SEHR grobgranularer Einteilung nützlich sein. Ich will aber lieber mal weiter provozieren und sehen, wohin wir damit kommen.

Zunächst zum Projekt-Setup: Warum stellen wir uns nicht so auf, dass wir sagen: Wir gehen morgen live! Mit Null Features, wirklich ein System, das nahezu nichts tut. Nur um zu sehen, ob unser Setup stimmt und wir in der Lage sind, innerhalb von 5 Minuten ein Feature zu releasen. Dann kann es also schon mal keine “kritischen Meilensteine” namens Deployment und GoLive (Inbetriebnahme) geben, denn die sind bereits heute erfolgt.

Als nächstes verstehen, entwickeln, testen und releasen wir ein Feature nach dem anderen und messen, wie schnell wir sind (Durchsatz). Das CFD zeigt ja die Steigung des Übergangs in den letzten Zustand.

Dann extrapolieren wir diese Schnelligkeit und schauen, wie viel Scope wir uns bis zum Endtermin erlauben können.

Dann schauen wir, wie viel Zykluszeit ein Feature im Durchschnitt braucht und machen daraus ein Control Chart mit Lower Control Limit und Upper Control Limit. Wir schedulen die Features dann so, dass vor dem Endtermin die kritischsten Features drin sind – so ein Feature muss ja spätestens am Endtermin minus UCL(Zykluszeit) begonnen werden, um sicher drin zu sein.

So, wozu brauchen wir jetzt noch Meilensteine und Aktivitäten auf einem Zeitstrahl? Nein, wir brauchen nur Fluss von Ergebnissen, keine Aktivitäten.

Sach ich heute mal so. Heut habe ich mal Lust auf Schwarzweiß-Malerei. Mal sehen, wie weit wir damit kommen.

Schöne Grüße
Matthias Bohlen

Wo in den CFD finde ich den Pufferzeiten im Projekt? Es gibt Projekte, die müssen zu einem bestimmten Tag X abgeschlossen sein (Mehrwertsteuerumstellung, …). Hier ist eine Rückwärtsplanung ein wertvolles Hilfsmittel, um kritische Meilensteine zu erkennen und den Projektleiter (oder das Team, den PO, den SM) in die Lage zu versetzen, Maßnahmen zu ergreifen und ggf. nochmal den Scope zu überprüfen.

Ich habe schon viele agile Projekte gesehen – das Thema Rückwärtsplanung kommt meist nicht vor – und der agile Werkzeugkasten sieht dazu auch wenig Nützliches vor – außer der Aussage, dass Rückwärtsplanung ja sowas von unagil ist

Leider kommt Rückwärtsplanung auch in Gantt gesteuerten Projekten nur selten vor – aber die Netzplantechnik bietet hier gute Möglichkeiten, um zu sehen, ob man noch “on track” ist oder nicht. Viele PM kennen allerdings nur Gantt und haben dann 400 Aufgaben im Gantt Chart und verbringen mehr Zeit damit, die Charts zu aktualisieren, als aktiv ihr Projekt zu steuern (das meine ich mit falschem Einsatz).

In meinem letzten Projekt hatten wir ein Gantt-Chart mit den wichtigsten Meilensteinen <=10 Tasks und CFD und Burn-Down für die Sprints. Eine super Kombination. Viele Grüße, Guido Zockoll

Es ist gut, die Themen bis zur eigentlichen Quelle zurückzuverfolgen, dann sieht man, was der ursprüngliche Autor (in dem Fall Gantt) eigentlich erreichen wollte: Maschinen hoch auszulasten, ein ganz anderes Problem als ein Projekt oder einen Service zu managen. Kein Wunder, dass Gantt-Charts dort nicht funktionieren, denn in Projekten oder Services geht es nicht um Auslastung, sondern um viele andere Qualitäten, die wichtiger sind.

Sehr erhellend, vielen Dank!

Eigentlich sollte ein “Boss” ja von sich aus neugierig sein auf das, was seine Mitarbeitenden an Ideen haben … und sie dabei unterstützen, diese 8 Punkte zu berücksichtigen. Wenn ein Mitarbeitender bereits vorher all das beherzigen muss, nur um mit 80% Chance die Genehmigung für die weitere Verfolgung der Idee zu erhalten, dann wird deren konkrete Umsetzung noch viel schwieriger sein …
Besser also: Hände weg von solchen Chefs ….

Hans-Peter, lieber Himmel, welche Grundeinstellung gegenüber einem Boss ist das denn? Damit limitieren Sie ja sofort den Fluss der Energie in einem möglichen Gespräch mit ihm! Welch ein Hindernis Sie damit aufbauen!

Nein, wirklich, hier geht es darum, den Boss für etwas zu begeistern, bei dem seine Energie und Aktivität benötigt wird. Alles andere können die Teams schließlich selber! Wenn Sie mit solch einem Bild im Kopf in ein Gespräch gehen, wird das nichts werden.

Gehen Sie davon aus, dass Ihr Boss seine Abteilung voran bringen will. Helfen Sie ihm dabei, das zu tun. Denken Sie in Ruhe nach. Arbeiten Sie die Vorteile Ihrer Idee heraus. Lassen Sie im Gespräch Ihre volle Energie sprühen – dann werden Sie auch Erfolg haben.

Besser also: Hände weg von solchen Chefs …. und einen neuen wirklich interessierten und innovationsoffenen Chef suchen …. die Firmen mit anderen Chefs werden ohnehin über kurz oder lang infolge Innovationsmangel dicht machen …. also lieber früher als zu spät das ohnehin schon sinkende Schiff verlassen!

Viele Innovationsoffene Firmen stellen allen Mitarbeitenden 1/2 oder gar 1 Tag pro Woche zu Verfügung, um an irgendwelchen frei gewählten Dingen zu arbeiten … das sind die anpassungsfähigen und überlebensfähigen Firmen!

danke für Ihre Frage! Was der Personaler seiner GF erklären sollte, ist folgendes:

Die Kosten für ein Entwicklungsvorhaben bestehen nicht nur aus Gehältern, sonst wäre 100%ige Auslastung genau das Richtige. Nein, die Gehälter werden bei weitem übertroffen durch die Kosten von Verzögerungen (siehe meinen neuen Blog-Artikel “Wenn der VerZug kommt”, dort liegen diese Kosten im Millarden-Euro-Bereich!).

Die GF muss versuchen, die Summe(!) aus Gehältern und Verzugskosten zu minimieren. Und da bei 95% Auslastung die Warteschlange noch nicht getaner Arbeit sechsmal so lang ist wie bei 80% Auslastung, sind auch die Verzugskosten sechsmal so hoch. Die GF sollte also ausrechnen, was ein Monat Verzug kostet und was im Vergleich dazu 20% ungenutzte Kapazität des Teams kosten.

Weiterhin kommt noch dazu: 100% ausgelastete Teams haben eine Reaktionsfähigkeit von Null. Deshalb kann die GF mit so einem Team keine Geschäftschancen ausnutzen, die sich kurzfristig bieten. Das mindert den Umsatz. Je mehr “Luft” im Prozess, desto agiler kann ein Team sein und desto schneller lassen sich spontane Chancen nutzen. Und das bedeutet mehr Geld.

Übrigens steigt die Zahl von Fehlern, die man beim Entwickeln macht, mehr als linear mit der Zeit, die bis zum nächsten Feedback vergeht. Diese Zeit hängt von der Länge der Warteschlange ab. Da Fehlerbehebung später wiederum Teamkapazität kostet, macht sich auch das umsatzreduzierend bemerkbar.

Und, um schließlich die Menschen nicht zu vergessen: Im Zeitalter von Fachkräftemangel bedeuten motivierte Mitarbeiter sehr viel! Wenn ein Mitarbeiter seinen hochqualifizierten Freunden erzählt, dass er im Job noch Zeit und Luft hat, etwas wirklich gut und wirklich zu Ende zu machen, werden ihn seine Freunde beneiden und vielleicht auch bei dieser Firma arbeiten wollen.

Sie sehen: Es gibt n+1 Gründe, warum diese 15-20% Luft einfach toll und sinnvoll sind – ökonomisch wie menschlich.

Viel Erfolg in der Entwicklung wünsche ich Ihnen!
Matthias Bohlen

P.S.: In meiner Flow-Schulung (siehe Menüpunkt oben, “Services/Schulungen”) erzähle ich Führungskräften immer wieder davon. Alle, die bisher dabei waren, haben gestaunt und beschlossen, für ihre Leute diese “Luft” zu spendieren.

Und noch besser die Benennung und Zuordnung der Abschreibungen.

Dass Inventar im Bild nur zwischen den Produktionsschritten steht, scheint mir ein bisschen eng. Dort entstehen zwar Halden, die auch abzuschreiben sind, falls der Fluss ins Stocken gerät. Doch auch um den Fluss herum existiert viel Inventar. Das Wissen des Entwicklungsteams ist zum Beispiel Inventar und wird mit dem Gehalt “aktiviert”. Wenn man das nicht sieht, versteht man nicht, dass auch dort Abschreibungen drohen.

Ein Training, dessen Inhalte nicht angewandt werden… Die nächste Reorg, weil da einer ein Managementbuch gelesen hat… Wissen, das veraltet, obwohl es angewandt wird…

Die Subsummierung unter den Begriff Lean find ich schade. Das sind ja Begriff aus der Theory of Constraints (TOC). Wer sich weiter damit beschäftigen will, findet dort eher Hinweise in der Literatur (z.B. “Throughput Accounting”) als bei Lean.

Jetzt fehlt nur noch ein Messinstrument für die Abschreibungen

Passen noch die traditionellen finanziellen Modellen zu agiler und lean Softwareentwicklung? Oder gibt es auch ein neues Verständnis über das Verhältnis zwischen Aufwand, Wert, Zeit und Geld? Wie kann es in Firmen umgesetzt werden?

Ein Feedback bzgl. der Codequalität und der umgesetzten Lösung im Detail erhält ein Entwickler oft nur dann, wenn ein anderer Entwickler an einer ähnlichen Stelle im Sourcecode (weiter)arbeitet. Kürze Zyklen (frühes commit, merge des feature branches) ermöglicht den Teamkollegen überhaupt erst zeitnah Feedback zu geben.

…

Du hast natürlich Recht, über diese (naheliegende) Kombination habe ich noch nie so direkt ‘drüber nachgedacht. Während eines Pomodoro-Abschnittes ist das WIP-Limit eben “1″.

Das bringt Fokussierung, Vermeidung von Multi-Tasking und Flow…

Mein bisheriger Blick lag bei “Die Pomodoro-Technik – Ein Mini-Scrum!” http://boeffi.net/tutorials/pomodoro-technik-ein-mini-scrum/

Obwohl die Konzepte von Kanban, Scrum, Pomodoro, … so ganz unterschiedlich sind, gibt es doch viel Gemeinsames…

In diesem Sinne

CU
Boeffi

Ich bin ein Fan von physischen Zetteln an einer physischen Tafel. Auf jedem Zettel steht eine ID, die in ein elektronisches Ticket Tracking System zeigt. Dort hebt man die Details der jeweiligen Anforderung auf.

Mir fehlt bei elektronischen Kanban-Tafeln immer das haptische Empfinden und das Geräusch, das ein Zettel macht, wenn man ihn von der Tafel abzieht. Im Standup-Meeting verbessert beides die Kommunikation der Beteiligten untereinander. Eine physische Tafel ist auch extrem flexibel: Man kann schnell mal neue Bereiche definieren, Zettel mittels Linien gruppieren, einen “Parkplatz” anlegen, eine “Müllhalde” definieren, einen süßen Riegel als Belohnung in die letzte Spalte hängen, eine Schachtel für die fertigen Tickets ankleben und vieles mehr. Ein elektronisches Tool braucht immer Zeit, es zu konfigurieren.

Elektronische Tafeln sind natürlich bei verteilten Teams manchmal unabdingbar. Doch auch hier würde ich zuerst versuchen, mit einem “Sticky Buddy” zurechtzukommen.

In letzter Zeit entwickeln sich Tools, die z.B. per Webcam die Zettel erkennen und eindeutig einem Issue im Tracker zuordnen können. Das ist natürlich dann am einfachsten – das “UI” wird durch die Zettel gebildet, und trotzdem hat man das elektronische System, das den Zustand richtig verwaltet und Statistiken führt. Feine Sache!

Schöne Grüße,
Matthias Bohlen