von Super User | Apr. 8, 2017 | Agile Methoden
Agile Methode: Elevator Pitch (Kurzpräsentation)
In einem Elevator Pitch stellt der Vortragende seine Ideen innerhalb von maximal 60 Sekunden dar. Es handelt sich also um eine meist mündliche Kurzpräsentation. In der Präsentationspraxis entwickelt der Vortragende im Vorfeld, seine Präsentation auf maximal einen Flip-Chart und verwendet dieses als Medienunterstützung für seinen Vortrag.
Der Elevator Pitch arbeitet mit folgender Aufgabenstellung:
„Stellen Sie sich vor, Sie befinden sich in einem Aufzug. In diesem Aufzug ist auch ihr potentieller Geldgeber.
Sie müssen ihn von ihrem Investitionsvorschlag überzeugen, bevor er den Fahrstuhl verlässt.
Eine solche Fahrstuhlfahrt dauert 60 Sekunden.“
Die daraus entstehende mündliche Kurzpräsentation kann als Video aufgezeichnet werden und dann als Anforderung schriftlich dokumentiert werden. In Agilen Projekten ist die Präsentation nur die Basis für eine spätere gemeinsame Diskussion über die hier beschriebenen Leistungsanforderungen. Wichtig ist, dass zumindest einige Mitglieder des Umsetzungsteams bei dem Elevator Pitch anwesend sind und an der nachfolgenden Diskussion beteiligt werden. Nur so ist sichergestellt, dass sie bei der späten Umsetzung der Leistungsanforderungen, diese auch ausreichend verstanden haben.
von Super User | Apr. 8, 2017 | Agile Methoden
Agile Methode: Product Owner (Produkt Verantwortlicher, Produkt Eigner)
Die Bezeichnung „Product Owner“ wird hier als Rolle verstanden. Analog zu dem üblichen Verständnis des Begriffes „Rolle“, kann ein Mensch mehrere Rollen haben.
Der Product Owner ist eine Kommunikationsschnittstelle zwischen den Stakeholdern und dem Entwicklerteam.
Stakeholder sind alle Personen, die
- an dem Produkt ein Interesse haben,
- von dem Produkt betroffen sind,
Dazu gehören insbesondere: die Auftraggeber, die Kunden, die Nutzer, die Kostenträger, das eigene Management, das Management des Auftrag gebenden Unternehmens, etc. Der Stakeholder Begriff ist hier also sehr weit gefasst. Aufgabe des Product Owners ist es, diese Stakeholder zu identifizieren und sie in die Produktentwicklung zu integrieren. Eine gute Methode zur Identifikation und Bewertung der Stakeholder ist die Stakeholder-Analyse. Da die Stakeholder Analyse aus dem klassischen Projektmanagement kommt, wird sie hier nicht dargestellt.
Wenn ich davon rede, dass der Product Owner etwas macht, bzw. „verantwortlich ist für…“, dann bedeutet das immer, dass er die Interaktion und Kommunikation zwischen den Stakeholdern, incl. des Entwicklerteams koordiniert. Anders gesagt: Der Product Owner tut nichts alleine! Er fasst keine einsamen Beschlüsse, erarbeitet keine selbständigen Lösungen oder entwickelt Konzepte alleine an seinem Computer. Alles, was er macht, macht er in Zusammenarbeit mit anderen Menschen und in Abstimmung mit diesen.
Im Focus der Rolle des Product Owners steht die Entwicklung und Weiterentwicklung des Produktes. Dabei erfasst er die Anforderungen der Stakeholder. Er hilft den Stakeholdern diese Anforderungen zu formulieren (z.B. in User Stories), gemäß ihres Wertes zu sortieren (Priorisieren) und den Aufwand des Leistungserstellungsprozesses für die einzelnen Anforderungen zu schätzen.
Die Ergebnisse dieses Prozesses werden im Product Backlog dokumentiert. Die Pflege dieses Product Backlogs ist die Hauptaufgabe des Product Owners.
Die andere Hauptaufgabe liegt in der Durchführung der Reviews. In den Reviews präsentiert das Entwicklerteam den Stakeholdern die erstellten Inkremente. Der Product Owner bleibt auch hier in seiner, die Kommunikation koordinierenden, Rolle. Die Begutachtung und Bewertung erfolgt durch die Stakeholder. Er ist lediglich dafür verantwortlich den Prozess des Reviews zu koordinieren und muss die Ergebnisse des Reviews mit den möglichen Veränderungen in dem Product Backlog dokumentieren. Anders ausgedrückt: Ein Review ohne Stakeholder – nur mit dem Product Owner – ist nicht agil.
Die wichtigsten Eigenschaften eines Product Owners liegen also im Bereich der Kommunikation und Moderation. Er sollte die „Sprache der Leistungsersteller“ ebenso gut sprechen wie die „Sprache der Anforderer“. Seine Aufgabe wird häufig darin bestehen, für beide Gruppen „zu übersetzen“. Wichtig sind auch gute Kontakte zu den Stakeholdern in der Auftrag gebenden und Auftrag nehmenden Organisation. Wenn er Erfahrung mit der Entwicklung ähnlicher Produkte hat, ist auch das hilfreich. – Hilfreich, aber nicht notwendig, da er selber keine Beschlüsse fasst.
{article 245}[text] {/article}
von Super User | Apr. 8, 2017 | Agile Methoden
Agile Methode: Produkt Vision entwickeln
Eine der ganz großen Visionen wurde 1961 von dem amerikanischen Präsidenten Kennedy formuliert:
„Ich glaube, dass das Land sich dem Ziel widmen sollte, noch vor Ende des Jahrzehnts einen Menschen auf dem Mond landen zu lassen und ihn wieder sicher zur Erde zurück zu bringen.“
Eine gute Vision besteht aus wenigen, unmissverständlichen Worten. Die Vision ist quasi die oberste Ebene der Produktbeschreibung. Ausgehend von der Vision werden dann die Epics, User Stories, Funktionsbeschreibungen und das erste Product Backlog entwickelt. Aber am Anfang steht immer die Vision.
Es gibt eine Reihe an Formaten, in denen Visionen formuliert werden können.
Die Vision kommt von den Anforderern, bzw. Auftraggebern. Der Product Owner unterstützt diese Stakeholder bei der Entwicklung einer solchen Vision.
In vielen Organisationen ist mit der Entwicklung einer Vision, auch die Aufgabe verbunden, einen Projektauftrag, Projektantrag, Projektfreigabe, Projektgründung oder Projektanbahnung zu entwickeln. Die Genehmigung eines solchen Projektauftrages durch die Auftrag gebende Organisation ist dabei eine Voraussetzung dafür, dass mit der Produktentwicklung begonnen werden darf.
In vielen Unternehmen ist die Erstellung eines Projektauftrages ein aufwendiger, streng formalisierter Prozess, der planungsintensiv ist und häufig sehr detailliert und excessiv durchgeführt wird. Die exzessive Planungsanforderung, bei der die Produktplanung im Vorfeld des Projektes durchgeführt wird, steht häufig im Widerspruch zu einem agilen Vorgehen.
Der Vorgang der Visionsfindung sollte so einfach wie möglich gehalten werden. Die Planung sollte nur soweit durchgeführt werden, dass eine Vertrauensschwelle der Entscheider überschritten werden kann. Es geht nur darum, die Basis für die nächste Finanzierungsentscheidung zu schaffen. Die Produktentwicklung muss gerade soweit spezifiziert werden, dass der wirtschaftliche Filter für die Freigabevorgaben für Produktentwicklungen durchschritten werden kann. Je höher die Freigabeanforderungen sind, bzw. je dichter der wirtschaftliche Filter, umso aufwendiger muss die Planung sein.
Nehmen wir einmal an, der amerikanische Kongress hätte Kennedy geantwortet:
„Wir können dem Vorhaben nicht zustimmen. Zunächst brauchen wir einen genauen Zeitplan für die Produktentwicklung. Bitte sagen Sie uns genau, welche Produktkomponente bis wann entwickelt ist und machen sie uns eine Aufstellung aller Komponentenkosten. Weder der Zeitplan, noch der Kostenplan dürfen überschritten werden. Außerdem brauchen wir eine Auflistung aller Risiken, wobei die Risiken in Risikokosten bewertet werden müssen. Ob die einzelnen Komponenten dann freigegeben werden, das ist natürlich davon abhängig, wie hoch sie die Kosten veranschlagen. Wir behalten es uns vor, diese Komponenten gegebenenfalls aus der Gesamtkonfiguration heraus zu streichen. Sollte der Zeit- oder Kostenplan- überschritten werden oder die Vision nicht verwirklicht werden, dann ist ihre Karriere zu ende.“
Glauben sie, dass dieses Vision realisiert worden wäre?
Häufig wird die Schranke zur Freigabe von Produktentwicklungen von dem Auftrag gebenden Unternehmen so hoch gesteckt, dass ein agiles Arbeiten bereits vor der Freigabe des Projektauftrages unmöglich ist. Viele der Vorhersagen, die sich hinter einer frühen Detailplanung und Kostenrechnung verbergen, basieren auf Annahmen, die auf Annahmen beruhen, die dann eine objektive Zahl ergeben. Die Annahme dahinter: 10% Eintrittswahrscheinlichkeit * 25% Eintrittswahrscheinlichkeit * 20% Eintrittswahrscheinlichkeit = 100% Sicherheit.
Ein agiler Weg besteht darin, zunächst nur die Finanzierung für die ersten Timeboxes zu vereinbaren und dann bei dem Review zu entscheiden, ob die Leistungserstellung weiter finanziert werden soll. Das gibt dem Team die Möglichkeit, sich auf die kurzfristigen Planungshorizonte zu konzentrieren und ihre Zeit nicht damit zu vergeuden, Funktionalitäten zu planen, die in dieser Form nie entstehen werden. Die Finanzierung erfolgt dann fließend mit dem Prozess der Leistungserstellung.
{article 245}[text] {/article}
von Super User | Apr. 8, 2017 | Agile Methoden
Agile Methode: Burnup Chart (Burn Up Chart)
Der Burnup Chart wird, genau wie der Burndown Chart, zur Darstellung der erbrachten Leistung innerhalb eines Leistungsentwicklungsprozesses verwendet. Der Unterschied zwischen den beiden Verfahren liegt nur in der optischen Darstellung der gleichen Sachverhalte. Welches der beiden Instrumentarien verwendet wird, ist eine Frage des persönlichen Geschmacks.
Die nachfolgende Abbildung zeigt beispielhaft einen Burnup Chart für einen Sprint, basierend auf der Anzahl der geplanten Task (Arbeitspakete)
Die Timebox ist hier auf 19 Arbeitstage begrenzt. Es sind 150 Tasks geplant. Mit zunehmender Abarbeitung der Tasks nähert sich der Burn Up Chart der roten Linie an. Liegt die Team Velocity über der Ideal Linie, dann kommt das Team schneller voran als geplant. Liegen die Werte unter der Ideal Linie, dann erfolgt die Arbeit langsamer.
Wenn der Brunup Chart zur Kontrolle der Produktentwicklung genutzt wird, dann kann der Entwicklungsfortschritt in Story Points gemessen werden. Veränderungen in der Planung der Story Point und der Entwicklungsdauer können mit dem Burnup Chart dargestellt werden.
Reduziert sich die Zahl der ursprünglich geplanten Story Point (Basisplan) zu einem bestimmten Zeitpunkt, dann sackt die schwarze Linie nach unten. Erhöht sich die Zahl der Story Points, dann geht diese Linie nach oben.
Ähnlich verhält es sich mit der Dauer der Produktentwicklung. Ausgehend von der schwarzen Linie auf der Zeitachse, verschiebt sich diese nach rechts, wenn die Produktentwicklung länger dauern soll, als ursprünglich geplant. Soll die Produktentwicklung verkürzt werden, verschiebt sich die Linie nach links.
von Super User | Apr. 7, 2017 | Agile Methoden
Agile Methode: „Product Owner“ Direkte Kommunikation
Ein Aspekt des agilen Arbeitens liegt darin, dass die Menschen direkt und Face-to-Face miteinander reden. Das ist die beste Form, um zu verstehen, was die andere Seite meint und die schnellste Form des Informationsaustausches.
Ein Aspekt der Rolle des „Product Owners“ ist die Kommunikation mit den Stakeholdern. Der Product Owner sammelt die Anforderungen der verschiedenen Stakeholder in direkten Gesprächen ein, Findet heraus, was – ausgehend von diesen Gesprächen für das Produkt als Ganzes von größtem Wert ist (Priorisierung) und schätzt in Interaktion mit dem Team den Aufwand.
Der Product Owner ist eine Kommunikationsschnittstelle und ein Informationsfilter zwischen den Leistungsanforderern und den Leistungsentwicklern. Er ist ein Informationsfilter.
In dieser Funktion als „Informationsfilter“ steht er im Wiederspruch zum dem agilen Grundsatz der direkten Kommunikation. Die Rolle dieses Informationsfilters ist nur darin begründet, dass die direkte Kommunikation von Team und Stakeholdern dazu führen würde, dass das Team nicht gleichzeitig mit allen Stakeholdern kommunizieren und eine Leistung erstellen kann.
Totz der Rolle des Product Owner ist der direkte Kommunikationsweg zwischen Team und Stakeholdern offen und gewünscht. Innerhalb einer Timebox der Leistungserstellung kann jedes Mitglied Unsicherheiten über eine direkte Nachfrage an den Product Owner klären, aber wenn es schneller oder einfacher geht, kann es auch direkt bei dem jeweiligen Stakeholder nachfragen.
Auch wenn die Pflege des Product Backlogs in der Verantwortung des Product Owners liegt, bedeutet das nicht, dass er diese Aufgabe alleine macht. Vielmehr koordiniert er die Interaktion von Stakeholdern und Leistungserstellungsteam. Wenn z.B. User Stories im Product Backlog verwendet werden, dann ist die aufgeschriebene Story nur ein Platzhalter für das Verstehen der User Story durch das Team.
Ebenso ist es natürlich, mit der Weiterentwicklung von User Stories von größeren zu kleineren Einheiten und dem Verstehen der Akzeptanzkriterien der Stakeholder durch die Leistungsersteller. Hier ist die direkte Face-to-Face Kommunikation zwischen Anforderer und Leistungsersteller der agile Weg des Verständnisses.
Spätestens beim Review kommen Leistungstersteller und Anforderer wieder zusammen und diskutieren über die Ergebnisse und damit über das gemeinsame Verständnis des Ergebnisses.
Ein Kernelement des Agil richtet sich gegen Kommunikationsfilter. Natürlich kann das Filtern von Informationen den Kommunikationsaufwand für jeden Einzelnen verringern. Auch die Informationsbeschaffung für die nachfolgenden Einheiten ist einfacher, weil die Informationen bei jedem Filter stärker verdichtet werden. Dem entgegen steht das Risiko einer Fehlinterpretation.
Ganz langsam und schwierig wird es, wenn das Team zwar verstanden hat, dass der Kunde „rot“ möchte, aber ein Detail nachfragen möchte.
Der rote Filter fragt dann den orangen Filter, der dann einen der Stakeholder fragt.
Der antwortet gelb, soweit bei dem gelben Stakeholder nachgefragt wird. Sonst antwortet er vielleicht blau oder pink.
Der grüne Leistungsersteller wartet in der Zeit auf die Information, ohne die er nicht weiter arbeiten kann.
Der orange Filter versteht gelb. Er meldet das dem roten Filter weiter. Der wird jetzt auch gelb und meldet das dem Team weiter.
Das Team verwirft die Ergebnisse und macht jetzt gelb.
Was passiert, wenn den Stakeholdern, in der Mehrheit blau und pink, das Ergebnis irgendwann präsentiert wird?
{article 245}[text] {/article}
von Super User | Apr. 5, 2017 | Agile Methoden
Release Backup
Das Release Backup ist ein Planungstool, das bei der Aufteilung der Funktionalitäten eines Produktes unterstützt und hilft diese Entwicklung der Funktionalitäten im Zeitverlauf über mehrere Releases zu verteilen.
Die Bezeichnung für die Release Planung unterscheiden sich innerhalb der Organisationen. Sie wird auch als langfristige Produktplanung oder meilensteingesteuerte Planung bezeichnet. Wenn nach jedem Sprint eine Auslieferung erfolgt, kann die Aufteilung in Releases auch als Sprint Mapping bezeichnet werden.
Die Fragen der Stakeholder, die mit der Release Planung beantwortet werden:
- „Wann werden wir welche Inkremente geliefert bekommen?“
- „Welche Funktionen werden wir bis zum Ende des Jahres bekommen?“
- „Bis wann müssen wir wieviel Geld bereitstellen?“
Mit einem Release werden Funktionalitäten an den Kunden ausgeliefert. – So zumindest der Zusammenhang, in dem ich den Begriff Release hier verwende.
Je nach Vertragssituation, Stakeholder Wünschen und Produkteigenschaften, muss eine Entscheidung über die Kadenzen mit denen die Leistungen an den Kunden ausgeliefert werden, vereinbart werden. Die agilen Prinzipien empfehlen diese Auslieferungszyklen möglichst klein zu halten. Einerseits, um frühzeitig ein Feedback zu erhalten und so Fehlentwicklungen zu vermeiden, andererseits damit die (Teil-)Produkte am Markt möglichst früh einen Deckungsbeitrag generieren können.
Denkbar sind folgende Kadenzen:
Bei manchen Produktentwicklungen werden Minimum Relesable Features (MRFs) festgelegt. Es handelt sich um minimal freigegebene Funktionen, also um die Funktionen, die pro Release mindestens als Inkremente erstellt werden müssen. Das ganze Konzept dieser MRFs ist etwas schwierig, weil es nur dann realisierbar ist, wenn die Funktionen in einem Product Backlog alle vergleichbar sind. Außerdem sollen die User Stories, die in einer Timebox erstellt werden, ja nach Möglichkeit verbindlich sein. Das MRFs Konzept beinhaltet das Risiko, dass Timeboxes über die bearbeitbaren Anforderungen hinaus vollgestopft werden, so nach dem Motto: Vielleicht sind sie ja schneller. Wichtig sind ja sowieso nur die MRFs.
Ein Produkt, das in dem Portfolio Backlog steht, ist zumeist nur sehr ungenau beschrieben. Die Beschreibung wird eben ausreichend sein, um die wirtschaftlichen Kriterien zu überprüfen und daraus die Priorität zu bestimmen, die das Produkt in Relation zu den anderen Produkten im Portfolio Backlog haben.
Wahrscheinlich werden einige Funktionalitäten beschrieben sein und andere eher unklar bestehen. Die Genauigkeit der Schätzung für die einzelnen Funktionen und für den Aufwand der Produkterstellung kann sehr unterschiedlich sein. Das ist immer davon abhängig, wie genau der Auftraggeber und das eigene Unternehmen eine Kosten-Leistungsschätzung haben möchte und welche Kriterien in dem Unternehmen zur Wirtschaftlichkeitsprüfung von Investitionen zugrunde gelegt werden.
Für die Erstellung des Release Backups ist das zunächst nicht wichtig. Wir nehmen die Informationen die bisher erarbeitet wurden. Für das Release Backlog werden sie weiter entwickelt, überprüft und verfeinert.
Zunächst wird festgelegt:
- Wie viele Releases gemacht werden sollen.
- Wie lange die einzelnen Releases dauern sollen. Die Dauer der Releases kann auch als Timebox für die Produktentwicklung verstanden werden.
- Wie viele Aufwandspunkt, z.B. Story Points innerhalb eines Release abgearbeitet werden kann. Dafür können z.B. die Erfahrungen mit der Team Velocity genutzt werden.
Wenn zusätzliche Anforderungen dazu gekommen sind, werden diese Anforderungen ergänzt. Anders Ausgedrückt: es müssen neue User Stories geschrieben werden. Auch der für das Gesamtprojekt geschätzte Aufwand muss für jede Funktion oder User Story neu geschätzt werden.
Die Prioritäten, die jetzt aus Perspektive der Funktionalitäten basierend auf dem Wert der jeweiligen Funktionalität aus Stakeholder Sicht ermittelt werden, sind ausschlaggebend für die Reihenfolge, mit der die Funktionalität in den Releases bearbeitet wird.
Daraus entsteht ein Release Plan, der den Leistungserstellungsprozess des Produktes in mehrere große Einheiten unterteilt. Genau wie alle anderen Backlogs muss dieses Backlog regelmäßig überprüft und an die neueste Entwicklung angepasst werden.
von Super User | Apr. 5, 2017 | Agile Methoden
Agile Methode: Portfolio Backlog
Das Portfolio Backlog ist eine Ideensammlung für neue Produkte, die erstellt werden könnten. Die Ideen, die hier enthalten sind, sind nach Prioritäten bewertet. Die Bewertung erfolgt nach wirtschaftlichen Kriterien. Neben der Priorität wird auch der Aufwand abgebildet, der für die Umsetzung der Produkte geschätzt wird.
Wenn ein Produkt in den Leistungserstellungsprozess übernommen wird, rückt das nächste Produkt eine Priorität nach oben.
Wenn wir das Vorgehen als agilen Prozess verstehen, dann wandert das Produkt jetzt in die Release Planung und wird dann mit Release Backlog weiter verarbeitet.
von Super User | Apr. 4, 2017 | Agile Methoden
Agile Methode: Agile Unternehmensplanung auf mehreren Ebenen
Wenn wir die agilen Planungsprinzipien betrachten, dann wird deutlich, dass Planung auf mehreren Ebenen ansetzt. Die meisten agilen Systeme beschäftigen sich primär, mit einer sehr niedrigen Planungsebene, etwa auf der Ebene eines einzelnen Projektes, das mit einem kleinen Team realisiert wird. Diese Perspektive verschleiert, das Agil auf allen Unternehmensebenen angewendet werden kann.
Leider herrscht hier die übliche Begriffsverwirrung und Mehrdeutigkeit, wie sie in der Betriebswirtschaftslehre üblich ist.
Beginnen wir also oben, bei der Unternehmensstrategie. Ich möchte hier nicht weiter darauf eingehen, ob und wie diese Agil gestaltet werden kann oder sollte. Wichtig ist für mich an dieser Stelle nur, dass aus dieser Unternehmensstrategie abgeleitet wird, welches Unternehmensportfolio an Produkten erstellt werden soll.
Das Portfolio enthält die Leistungen, die neu erstellt werden sollen oder an denen umfangreiche Veränderungen vorgenommen werden sollen. Diese Begriffsauffassung weicht von einer Reihe an anderen Definitionen von Produkt Portfolio ab. Im Marketing würde ich eine andere verwenden. Nach meiner Auffassung sind agile Methoden ideal für eine Neuentwicklung von Leistungen geeignet. Für eine kontinuierliche Weiterentwicklung eines Produktes sind andere Methoden besser geeignet. Z.B. ein Lean Management-Ansatz.
Die agile Methode die hier dafür vorgestellt wird, ist das Portfolio Backlog.
Mit Hilfe dieser Methode werden die Fragen beantwortet:
- Welche Produkte werden in der Zukunft in unserem Unternehmen mit höchster Priorität und möglichst bald entwickelt werden?
- Welchen Aufwand erwarten wir für die Entwicklung dieser Produkte?
- Welche Haupteigenschaften sollen diese Produkte haben?
Betrachten wir die Ebene der einzelnen Produkte, dann treffen wir hier auf das nächste Abgrenzungsproblem. Nehmen wir das Beispiel Microsoft Office. Sind die Komponenten des Office Paketes (Word, Excel, Powerpoint, etc.) Komponenten eines Produktes oder sind es eigenständige Produkte? Ist das Produkt Word 10 ein eigenständiges Produkt oder nur ein weiteres Release von Word 7? Wie auch immer dieses philosophische Problem gelöst wird, wichtig ist hier, dass die meisten komplexen Produkte nicht in einem Zyklus entwickelt werden, sondern in mehreren Releases.
Das kann mit der Methode des Release Backlogs geplant und in der zeitlichen Abfolge in der Produkt Roadmap dargestellt werden.
Eine Ebene tiefer betreten wir die Betrachtungsebene von Scrum. Hier geht es um die Planung und Umsetzung eines Release oder eines kleinen Produktes mit einem Team. Natürlich gibt es auch agile Vorgehensweisen um auch Scrum Projekte mit mehreren Teams zu organisieren. Die Scrum Guide betrachtet diese aber nur am Rande.
Zur Planung der Leistungserstellung wird hier das Product Backlog verwendet. Mit dieser Methode werden die Timeboxes oder in der Scrum Terminologie „Sprints“ geplant. Aus dem Product Backlog werden die Leistungen ausgewählt, die in den einzelnen Sprints erstellt werden sollen.
In dem Product Backlog werden die gleichen Fragen beantwortet, wie in den vorhergehenden Backlogs, nur auf einer niedrigeren Ebene:
- Welche Funktionalitäten sind von dem größten Wert und bekommen so eine höhere Priorität?
- Welchen Aufwand erwarten wir für die Entwicklung der Funktionalitäten?
- Welche Eigenschaften sollen die Funktionalitäten haben?
Erst auf Ebene der Timeboxes, bzw. Sprints nähern wir uns der Ebene der Leistungserstellung. Aber wir haben sie noch nicht ganz erreicht. Auch bei der Planung der Sprints wird nur geplant. Während des Sprint Planing wird festgelegt, was innerhalb einer Timebox geleistet werden soll und mit welcher Priorität – natürlich wieder unter Berücksichtigung des geschätzten Aufwandes. Gesteuert wird der Sprint über ein Kanban Board.
Bisher wurde nur geplant. Erst nach dem Sprint Planing beginnt die eigentliche Leistungserstellung. Hier erfolgt die Steuerung dann über und in dem Daily Standup Meeting.
Wieviel Planung ist in Agil?
Wenn ich das oben gesagte im Zusammenhang lesen, dann liegt der Schluss nahe, dass agilem arbeiten ein mehrstufiger Planungsprozess vorausgeht, der sehr komplex ist. Auf jeder Planungsstufe werden die gleichen Fragen beantwortet – nur immer bezogen auf kleinere Einheiten:
- Was ist von größtem Wert und sollte zuerst gemacht werden?
- Welche Anforderungen werden an die Leistung gestellt?
- Welchen Aufwand erwarten wir bei der Leistungserstellung?
Die präferierte agile Methode ist dabei das Backlog. In diesem Backlog werden allerdings nur die Ergebnisse festgehalten. Es ist also ein reines Tool zur Abbildung von Ergebnissen. Mit welchen Methoden die Ergebnisse entstehen, z.B. mit einer klassischen Risikoanalyse oder einer Schätzung des Kapitalwertes sind von den agilen Methoden nicht vorgegeben.
Die präferierte Methode für Feststellung von Anforderungen ist die User Story. Jede andere Methode zum Beschreiben der Anforderung ist aber auch möglich.
Die Basis für die Schätzung des Aufwandes erfolgt in Story Points. Die Schätzung erfolgt nicht in absoluten Kosten oder Zeitwerten, sondern in einer Schätzung der relativen Größenverhältnisse der User Stories. Wobei das natürlich nicht zwingend vorgeschrieben ist. Die Story Points können in Personentage und darüber in Kosten umgerechnet werden. Die Leistungsfähigkeit eines Teams wird als Team Velocity ermittelt und in Story Points pro Sprint gemessen. Die durchschnittlich erstellten Story Points pro Sprint bilden die Basis für die Zahl an Funktionalitäten, die innerhalb der nächsten Sprints erstellt werden sollen.
Die Pläne der verschiedenen Ebenen werden ständig überprüft und neuen Gegebenheiten angepasst.
Wenn jetzt einige Leser sagen: „Schön, – wenn wir jetzt mal die ganzen neuen Worte weglassen -, so haben wir doch immer schon gearbeitet. Was soll ich jetzt agil besser machen?“ Dann fällt mir nur die Antwort ein: „Lerne die neuen Worte“. Wenn Sie bisher anders gearbeitet haben, dann liegt im agilen Arbeiten ein großes Verbesserungspotential.
{article 245}[text] {/article}
