Im Marmot LIFE Magazin #4 (2012) schreibt Alpinist Stefan Glowacz: “So ist der Plan, die Realität sieht anders aus.” Was war passiert? Ein Team von vier Experten in Patagonien, ein Berg (Fitz Roy), eine Route in der Ostwand und ein Sturm, der das Team in die Knie zwingt. Stefan Glowacz schreibt weiter: “In diesen Momenten bekommt der Mensch seine Grenzen gnadenlos aufgezeigt.”

By Winky from Oxford, UK (Flickr) [CC-BY-2.0 (http://creativecommons.org/licenses/by/2.0)], via Wikimedia CommonsViele der Grenzen, die uns umgeben, erkennen wir nicht so deutlich, wie ein Alpinist in einem Inferno von Wind, Kälte und Schnee. Nur die Natur zeigt uns treu und beharrlich, was wir nicht beherrschen. Meist erkennen wir erst nach dem Start, geschäftlich wie privat, was das Wichtigste auf unserer Reise sein wird. Ein Plan hilft, denn die Planung selbst war wertvoll. Ab jetzt heißt es: Erfahrungen machen und sich den Gegebenheiten anpassen, denn man weiß nicht, was als nächstes aus dem Nichts auftaucht. Ein Plan ist die letzte Schätzung, bevor es auf die Reise geht.

In der agilen Produktentwicklung akzeptieren wir unsere Grenzen. Wir gehen davon aus, dass wir vor dem Start nicht alles wissen, nicht alles planen können und akzeptieren, dass es auf unserem Weg zum Produkt stürmisch zugehen kann. Wir gehen auf eine Expedition. Sehen die Route durch die Wand, zum Gipfel hin aus der Entfernung unscharf vor unseren Augen und doch kennen wir das Ziel. Meter für Meter steigen wir hinauf, immer den nächsten Tritt, den nächsten Griff suchend. Jeder Abschnitt des Berges stellt eigene, neue Anforderungen an uns. Schrittweise verfeinern wir somit unsere Vision. Durch das Beschreiten des Weges beginnen wir zu verstehen – Etappe für Etappe mehr. Es wird greifbar, den Gipfel im Kopf, gehen wir die nächsten Meter an, soweit wir voraussehen können.

Stefan Glowacz schreibt: “Der limitierende Faktor im Himalaya ist bekanntlich die Höhe der Berge, in Patagonien sind es die unberechenbaren und gefürchteten Stürme. Rein statistisch gesehen stehen dem Kletterer nur zwei bis drei Schönwettertage [...] zur Verfügung, [...]“. In beiden Fällen ist die Zeit der begrenzende Faktor für die Expedition. Das ist in der Produktentwicklung nicht anders. Auch hier ist die Zeit knapp und zusätzlich ist es riskant, zu viel zu planen. Grund hierfür sind wie auch am Fels die externen Bedingungen, die sich stetig ändern. Neue Bedingungen stellen neue Anforderungen an uns, auf die wir uns einstellen müssen. Gerade das führt in der Produktentwicklung dazu, dass man keine Zeit an Anforderungen verlieren sollte, die sich ändern werden. Zu Beginn alle Anforderungen gleich zu behandeln ist verschwenderisch. Daher steigen wir mit einer soliden und grundlegenden Planung auf und haben die richtigen Fähigkeiten im Rucksack. Mit Disziplin und mentaler Stärke reagieren wir auf sich ändernde Bedingungen und haben auch den Mut, eine Expedition abzubrechen. Frei nach dem Motto: “Ein sehr guter Bergsteiger kommt wieder nach Hause.”

Was bringt uns in der Produktentwicklung sicher nach Hause?

Ein fernes Ziel haben, lässt uns die Route selbst wählen, jedoch die Richtung steht und wir richten uns daran aus. Nicht am Start alles im Detail planen, denn auf der Strecke werden wir wertvolle Entdeckungen und Erfahrungen machen, die wir vorher nicht erahnen konnten. Nicht alle Anforderungen gleich behandeln, sondern die wichtigen zuerst und den Rest hinten anstellen. Das vermeidet Verschwendung. Nicht zu viele Themen ins Backlog packen, denn ein zu großer Rucksack kann nicht weit getragen werden. Ein zu großes Backlogs zeigt nur, dass ein Team überlastet mit der geplanten Arbeit ist. In diesem Sinne: sicher starten und sicher ans Ziel kommen.

Avatar of Sven Winkler
Sven spricht viele Sprachen: Von Java und Perl über C# bis XML - sogar ein wenig Japanisch kann er. Der erfahrene ScrumMaster, Product Owner und Software-Architekt aus Nürnberg gibt unumwunden zu, dass er gerne und viel redet, vor allem über Agile Softwareentwicklung im Allgemeinen und Scrum im Speziellen. Aber es gibt immer wieder einen Moment, in dem es ihm vor Freude die Sprache verschlägt: Wenn er erlebt, wie die Menschen, die er auf ihrem Weg mit Scrum unterstützt, plötzlich den Wert ihrer Arbeit spüren.
  • http://yascrum.blogspot.com/ Sebastian Radics

    Hallo Sven, 
    danke für die schöne Verbindung mit der Natur! 

    Deine Vorschläge bzgl. der Produktentwicklung kann ich ebenfalls unterstützen. Die Versuchung ist groß schon am Anfang zuviel Zeit zu investieren und dann ein größeres Backlog zu produzieren, als es tatsächlich sinnvoll ist. 

    Im Verlauf stellt man dann fest, dass sich noch deutliche Veränderungen ergeben, Dinge evtl. nicht mehr so wichtig sind und evtl. deutlich eher ein bereits sinnvolles Produkt fertig ist (und die bereits geplanten “goldenen Türklinken” nicht benötigt werden).

    Eine große Herausforderung ist dabei die wirklich wichtigen Sachen (hoher Wert, aber auch hohes Risiko dahinter) zu finden. Oft schlägt das auch auf die technische Ebene durch – und ein als klein eingeschätzter Teil wird “plötzlich” sehr groß und kann unter Umständen das Ziel gefährden…

    Wie pufferst Du das ab? Wenn Du einen fixen Termin hast – wie sicherst Du ab, dass Du den Termin erreichen kannst? 

    • http://twitter.com/svnwnk Sven Winkler

      Hi Sebastian,

      danke für Deine Rückmeldung und schön, dass der Beitrag Dir gefällt. Konkret bräuchte ich noch ein paar Hinweise auf Dein Szenario. Um was für technische Probleme handelt es sich, bspw. im Team und Code-Qualität oder organisatorische wie mangelnde Testumgebungen, Pre-Live-Umgebungen in der eigenen Firma und/oder beim Kunden? Prinzipiell kann sich dahinter die gleiche Auswirkung (Symptom) verstecken, bspw. die Terminverschiebung. 

      Lange Rede, vorab schon mal ein paar Antworten – lass es mich so sagen: ;-)

      In der Produktentwicklung begeben wir uns wie beim Erschließen einer Route auf Neuland: Technische Probleme sind nie ausgeschlossen und ein stürmisches Umfeld meist nicht weit entfernt.

      Zum einen ist es wichtig, dass Du deine Geschwindigkeit kennst, nur dann erreichst Du auch den Gipfel. Deine Geschwindigkeit lernst Du allerdings erst nach dem Start kennen, wenn Du schon in der Wand bist und auf die ersten Probleme triffst.

      Wichtig ist, dass das ganze Team dabei hilft, die riskanten Stellen zu identifizieren und wie Du sagst schnellstmöglich anzugehen, sodass neue Erkenntnisse zur Verfügung stehen.

      Ein Puffer oder Slack hilft, damit ihr auch taktisch agil bleibt und kurzfristig auftretende Probleme kompensieren könnt. 

      Bei schwierigen Problemen immer das gesamte Team an der Lösung arbeiten lassen. Im SP2 ein gemeinsames Bild entstehen lassen (UML) und gegenseitig die Lösungsvorschläge testen. Immer dann zeichnen wenn es um wichtige, strittige oder riskante Themen geht bzw. das Team interagieren muss. “Diagrams capture the knowledge that all Team Developers must keep in their head in order to work efficiently.” (R. C. Martin)

      Letztlich bleibt immer nur die Zeit, die uns gegeben ist. Zeit können wir nicht strecken, oder nur bedingt, indem wir in Bewegung bleiben. Mir ist es wichtiger, dass meine Teams clevere, ausgeruhte Entscheidungen treffen – anstatt lediglich Stunde um Stunde Zeit auf eine Aufgabe zu verschwenden.

      Prinzipiell kann Deine Frage auch in das vertragliche gehen. Hier gilt es bei einem fixen Termin und Änderungen am Inhalt auch den Gesamtinhalt des Auftrags anzupassen. D. h. für Änderungen einen Tausch vorzunehmen und etwas Gleichgroßes aus dem Backlog zu entfernen.

      Zu technischen Problemen fällt mir noch ein, dass es hilft keine zu komplexen Strukturen aufzubauen, jedoch darauf zu achten, dass wir erweiterbar bleiben. Konkret erkennt sollte man die Dinge erweiterbar halten, die sich sehr wahrscheinlich ändern oder besser noch, die Dinge, von denen man weiß, dass sie sich schon einmal geändert haben. Hier hilft uns die loose Kopplung bspw. durch Interfaces und Pattern (Strategie, Command, etc.)

      Prinzipiell hängt viel an den Schätzungen, die mein Team mir geben kann und wie vertraut sie im Zusammenspiel mit der Technik, den Leute im Team und der Domäne sind. Da wir beim Schätzen schlecht sind und immer diverse Szenarien auslassen hilft uns hier eigentlich nur ein empirischer Prozess und ein gut vorbereitetes Product- und Sprint-Backlog.

      Letztlich ist es ein Zusammenspiel aus vielen Dingen, damit wir Deadlines halten. Nicht zu wenig trägt dazu bei, dass wir den Kunden direkt einbinden, damit er jederzeit das bekommt was er braucht – das geht natürlich auch nur mit einem Kunden, der seiner Verantwortung nachkommt und schnelle Lieferung sowie Reaktion auf seine Wünsche wertschätzt und respektiert.

      Soweit hab ich hoffentlich ein paar Dinge getroffen, die Du wissen wolltest, wenn nicht, dann einfach nachhaken :-)

      Viele Grüße, Sven :-)

      • http://yascrum.blogspot.com/ Sebastian Radics

        Hallo Sven, 
        danke für die schnellen und guten Antworten – haben mir schon geholfen!

        Nachgehakt ;-)

        Konkret geht es bei den technischen Problemen um Folgendes (Beschreibung eines bereits passierten Problems): 

        * Wir müssen eine Implementierung bis 01.12. fertigstellen
        * Wir beginnen mit der Planung + Implementierung am 01.08. und investieren etwas Zeit in das zusammenstellen des Backlogs und nehmen die ersten Teile intensiv auseinander und später folgende Teile belassen wir mit groben Schätzungen. Wir sind mit der Planung im grünen Bereich und sind zuversichtlich, dass der Termin ok ist.
        * Nach 2 Sprints (4 Wochen) decken wir eine technische Bausstelle auf, die den Aufwand für die Implementierung des Teils deutlich nach oben laufen lässt. “Plötzlich” ist der Termin in Gefahr.

        Gut ist, dass wir das zeitlich früh(er) erkennen, als evtl. mit anderen Methoden. Trotzdem ist der Termin in Gefahr… 

        Wie analysierst Du im Vorfeld den technischem Background? Und wie stellst Du dabei sicher, dass eben nicht erst einige Sprints später solche deutlichen Probleme gefunden werden. Gehst Du dann schon technisch mehr in die Analyse, wenn das Backlog erstellt wird – spaltest Du also “Epics” schon zu Beginn weiter auf und führst etwas mehr Detailanalyse durch?  

        Arbeitest Du dann mit Zielkorridoren – wir schließen die Implementierung zwischen dem  10.11. und 22.11. ab… und wie veränderst Du ggf. den Korridor im Implementierungsverlauf?

      • http://twitter.com/svnwnk Sven Winkler

        Hi Sebastian,

        viele Fragen, ich versuche Dir ein paar Antworten zu geben :-)
        Klingt soweit alles gut, was ihr gemacht habt. Früh das Team einbezogen, die Risiken schnell angegangen, wenig Zeit auf unwichtigere Anforderungen verschwendet und daher Zeit gespart beim Start und dann eine unerfreuliche Entdeckung gemacht. Dazu eine Schätzung über die Epics und dadurch einen Releaseplan abgeleitet… hm…

        Beim technischen Background muss ich mich auf mein Team verlassen. Hier ist es wichtig das Team in die Spezifikation der wichtigsten/nächsten Stories mit einzubeziehen. Das habt ihr gemacht, wenn ich das richtig interpretiere. Wichtig ist auch, dass das Team so schnell wie möglich die wichtigsten Stories kennenlernt und strategisch einen Überblick über die Geschichten bekommt. Letztlich geht es immer darum, dass wir ein gemeinsames Bild erzeugen und dann später im Detail im Sprint Planning 2 unsere Ideen bzgl. Design und Architektur im Gespräch und in Skizzen testen.

        Wo ich gerade hänge sind die technischen Probleme. Liegt es an einem Legacy-System, welches mit viel technischer Schuld vollgestopft ist, eine unflexible Standardsoftware oder daran, dass die Technologie unbekannt war, mit der ihr gestartet seid. – Okay, mein Geist schreit gerade danach es genauer zu verstehen, ich halte ihn mal zurück ;-) – es kann technisch an so Vielem liegen, was vorher nicht immer einzusehen ist. 

        Die riskantesten Stellen gilt es im Vorfeld zu testen. Also die Top-Stories einmal kurz in Sachen Architektur und Design testen. Mit testen meine ich, dass das Team sich trifft und anhand von Verhalten und Struktur gemeinsam die wichtigsten Punkte durchspielt (bspw. mit UML). Das ist immer dann sinnvoll, wenn es um zentrale Punkte der Anwendung geht, wenn Uneinigkeit herrscht, wenn Abstimmung untereinander notwendig ist. So kann im Vorfeld die eine oder andere Hürde aufgedeckt werden. Man erwischt evtl. nicht alle, aber ein paar und die großen Fragezeichen sollte man genauer beleuchten und als Risiko beachten.

        Wie ihr mit Eurem Problem umgeht hängt zum einen von der Schwierigkeit ab, der ihr gegenübersteht. Ist das ganze Produkt gefährdet, kann die Anforderung vielleicht anders umgesetzt werden? Lässt sich an der Funktion etwas drehen? Hilft es vielleicht einen Experten im Vorfeld im gleichen Sprint schon an der Lösung vorzuarbeiten, sodass das Team dann zum Sprintstart performen kann? Ist die Anforderung gar nicht möglich umzusetzen? Oder ist das Produkt mit der Technologie nicht möglich? Muss vielleicht der Inhalt des Auftrags angepasst werden? Vielleicht hilft uns auch das Gesetz der großen Zahlen und wir haben mit etwas Glück die anderen Anforderungen überschätzt (okay, ja ich würde mich da nicht drauf verlassen). In jedem Fall kann sein, dass etwas hinten wegfällt. Das rechtzeitig kommunizieren. 

        Ich wünsch Euch viel Erfolg!

        Viele Grüße,
        Sven :-)

      • http://twitter.com/svnwnk Sven Winkler

        Wenn es auf den Zielkorridor knapp wird, dann gilt es über den Scope zu verhandeln :-)