Hier wie versprochen nun das erste Eintauchen in das Assessment-Modell. Die folgenden Ausführungen beziehen sich auf das PAM 4.0
Edit 15.01.2013: Möglichkeit für Diskussionen haben wir bei LinkedIn: http://tinyurl.com/43zj38vn
Allgemeines zu MAN.3
Die große Herausforderung bei MAN.3 liegt darin festzulegen, was ein Projekt ist. Scrum wird nicht auf den langen Planungshorizonten operieren, die du von Projekten gewohnt bist. Wenn du also noch in Projekten denkst und arbeitest, müsstest du alles mit traditionellen Planungswerkzeugen machen. Wenn du wirklich agil entwickelst, kannst du ein Release, oder einen Supersprint (z.B. PI bei SAFe) als Projekt ansehen. Generell empfiehlt sich auch im agilen so etwas wie ein Projekthandbuch anzulegen (meist ein Wiki) in der du alle Definitionen und Entscheidungen für dein Vorhaben dokumentieren kannst. Die Rohdaten für deine Argumente sind oft über verschiedene Artefakte und Werkzeuge verteilt. Trage Links o.ä. im Wiki zusammen damit du schnell alles findest. Nicht nur für das Assessment, sondern für deine tägliche Arbeit.
Ein zweiter wichtiger Punkt: Deine agilen Backlogs bieten einen sehr schönen Mechanismus um Arbeit zu definierern und nachzuverfolgen, jedoch beschränkt sich dies in der Regel auf die Tätigkeiten, die im Engineering angesiedelt werden. Die Arbeit von Scrum Master, Product Owner, Konfigurationsmanager usw. müssen aber für Automotive SPICE auch geplant und verfolgt werden. Ob du dazu ein eigenes Backlog für die “administrativen” Dinge anlegst oder das auch alles in die eigentlichen Backlog packst (mit einer Filtermöglichkeit in Deinem Tool) ist dabei egal. Achte nur darauf die Wertschöpfung der Entwickler*innen nicht zu behindern, wenn du deren Backlogs mitnutzt.
Diskussion der Base Practices
BP1: Define the scope of work
Das ist ein Thema, das recht unabhängig von den agilen Ansätzen ist. Der Scope des Projektes muss mehr sein, als eine Beschreibung des Produkts oder Inkrements. Das PAM will hier „Projektziele“ und „Kontext“ sehen. Notiere also in deinem Wiki die Ziele für das was du als Projekt definiert hast oder verweise auf einen entsprechenden Projektauftrag für das übergreifende Projekt und beschreibe auch den Kontext. Für das was Du als Projekt definiert hast, sind die Ergebnisse von Planungs-Events nützlich: Sprint Goals, PI-Objectives, Epics, Story Maps usw. stelle aus den Artefakten, die du ohnehin generierst eine aussagekräftige Definition des Project Scopes zusammen.
Die VDA-Guidelines sprechen explizit „Tickets“ als Arbeitspakete an. Storymaps wären dementsprechend auch ein gutes Werkzeug, um den Scope zu beschreiben. Neben diesen Planungsaspekten empfiehlt es sich, im Wiki auch Abgrenzungen zu notieren: Was ist definitiv nicht im Projekt-Scope?
Gemäß den Guidelines, musst Du auch zeigen können, wie sich Deine Doku unterwegs geändert hat. Es muss klar sein, dass dies lebende, aktiv genutzte Artefakte sind.
BP2: Define project life cycle
Den Lebenszyklus kannst du aus deiner Roadmap und dem verwendeten agilen Framework herleiten. Dokumentiere die wichtigen Meilensteine (wie Samples, Releases) in deinem Wiki oder in deinem Planungswerkzeug. Bezüglich der Ausführung kannst Du auf das von Dir verwendet Framework verweisen, es beschreibt den Lebenszyklus für eine Iteration oder eine Super-Iteration (z.B. PI in SAFe). Die Zusammenarbeit mit Kunden und Lieferanten bezüglich derer Lifecycle solltest Du auch im Wiki beschreiben.
BP3: Evaluate feasibility of the project
Hier geht es nicht nur um die technische Machbarkeit, sondern auch um die Prüfung, ob das Projekt im aktuellen Setting erfolgreich sein kann. Für die technische Machbarkeit verwendest du bei Scrum oder skaliertem Scrum Erkenntnisse aus Spikes, Prototypen und Inkrementen. Auch bei der Projekt-Machbarkeit hast du gute Karten: Durch das Pull-Prinzip bei der Planung kann es nicht sein, dass Ressourcen überlastet werden. Du musst nur sicherstellen, dass die Abschätzungen deiner Teams bis zu dem Meilenstein reichen, den du als Projektende definiert hast. Zusammen mit Velocities und Daten zur Zielerreichung bei vorhergehenden Releases, PIs usw. kannst Du nachweisen, dass ihr zuversichtlich seid, dass es klappt. Auch „Confidence Votes“ mit zig Leuten sind ein Indikator für die Machbarkeit.
Beachte, dass in den agilen Backlogs und bei Planungsevents nur mit den inhaltlichen Aspekten gearbeitet wird. Du musst aber auch die Machbarkeit für unterstützende Prozesse und die Administration des Projekts nachweisen, also Argumente finden und dokumentieren, dass Product Owner, Scrum Master, Konfigurations-Manager usw. mit ihren Aufgaben nicht überlastet werden werden.
BP4: Define and monitor work packages
Die Arbeitspakete ergeben sich aus deinen Backlogs, aus deinen User Stories, Features, Epics oder was auch immer du in deiner Organisation verwendest. Ja, diese Backlog Items können als Arbeitspakete angesehen werden, weil sie mehr als Anforderungen sind, sie enthalten Analyse, Architektur, Bau, Test usw. und sie werden geschätzt und für die Verwaltung der Arbeit verwendet. Die Größe dieser Items sollte natürlich so sein, dass mit ihnen halbwegs brauchbar der Fortschritt gemessen werden kann und Abweichungen erkannt werden können. Nicht nur wegen Automotive SPICE, sondern vor allem für dein wertvolles Entwicklungsvorhaben.
Das rein agile Denken springt für SPICE hier jedoch etwas zu kurz, es gibt auch einige Arbeitspakete, die nicht der Funktionsentwicklung dienen und die du zusätzlich in Backlogs aufnehmen solltest. Beispiele hierzu sind Arbeiten der Qualitätssicherung, des Konfigurations- oder Änderungsmanagements, Kundenworkshops usw. Wenn du es schaffst, hier möglichst alles einzubeziehen, bist du schon gut für Level 2 alles Prozesse gerüstet.
Achte darauf, dass die Abhängigkeiten der Tickets dokumentiert sind (z.B. Links in deinem Tool) und dass du auch Backlog Items für Nicht-Entwicklungstätigkeiten erstellst (für agile Rollen usw.) – verwende hierzu vielleicht ein anderes Backlog oder schaffe die Möglichkeit dies aus dem Entwicklungs-Backlog herauszufiltern.
Für das neue „monitor“ in im PAM 4.0 musst du zeigen können, wann dies passiert, zeige hier also Beispiele, wie Backlog Items in Refinement-Meetings angepasst wurden.
BP5: Define and monitor project estimates and resources
Im Gegensatz zu agilen Schätzungen geht es hier um mehr als um die Schätzungen im Backlog, es geht auch um Kosten, Qualitätszahlen und Risiken. Hier musst Du Nachweise außerhalb der agilen Mechanik liefern können. Hinsichtlich der Schätzungen in Backlogs musst du im Assessment darlegen können, wie du auch hier sicher sein kannst, dass du deine Ziele erreichen kannst und dass du Abweichungen erkennst. Du musst erklären, wie all das ohne den klassischen Ansatz von „Ressourcenschätzungen“ funktioniert. Im agilen sind die Ressourcen fest und die Planung wird über das Jonglieren mit den Inhalten umgesetzt. Durch die Pull-Planung ist das genauer, aber oft über einen kürzeren Zeithorizont als bei klassischen Projekten. Hier solltest du dir zurechtlegen, wie du das im Assessment argumentieren kannst und auch anhand historischer Daten und Beispiele nachweisen kannst.
Die Guidelines erwarten dass die „Arbeitspakete“ nicht größer sind, als der „Kontrollzyklus“ aber das ist bei Scrum oder skaliertem Scrum ohnehin gegeben.
Du kannst relative Schätzungen (z.B. in Punkten) verwenden, wenn Du brauchbare Zahlen über die Velocities der Teams hast. Die Schätzmethoden (z.B. Planning Poker) solltest Du nachweisen können, da die Guidelines Schätzungen von einzelnen Helden ablehnen.
Die BP legt Wert auf den Einfluss der Risiken in die Schätzungen, hier können dokumentierte Risiken in Zusammenhang mit Expertenschätzungen und das Bestreben nach Konsistenz (z.B. durch Planning Poker) verwendet werden.
Wie bei den beiden vorhergehenden Base Practices musst du auch hier die Arbeit von agilen Rollen und unterstützenden Tätigkeiten irgendwie darstellen, z.B. im erwähnten separaten Backlog und andere Dinge, wie z.B. Budget, Qualitätszahlen usw. auch mit einbeziehen.
BP6: Define and monitor required skills, knowledge, and experience
Der Nachweis läuft hier üblicherweise über eine Liste von im Projekt erforderlichen Qualifikationen und den Abgleich mit den dokumentierten Qualifikationen der Projektmitglieder. Für agile Rollen kannst du hier entsprechende Zertifizierungen zu Rate ziehen, echte agile Teams haben theoretisch eine Skill-Matrix, in der sie für das Team definieren, welche Qualifikationen erforderlich sind, wer sie hat und wer in welchem Thema dazulernen möchte. Das ist ein wichtiges Werkzeug um die T-shaped Skill Sets zu entwickeln. Ich schreibe „theoretisch“, denn in der Praxis ist es meistens vom Betriebsrat nicht gestattet, Qualifikationen der beteiligten Menschen irgendwie öffentlich darzustellen. Ob agil oder nicht, das ist ein Thema, das du mit dem Betriebsrat und dem Sponsor des Assessments klären musst, um hier keine Überraschung zu erleben.
Was auf jeden Fall gut ist, wenn Du nachweisen kannst, dass irgendwo Probleme mit der Qualifikation identifiziert wurden (z.B. in Retros) und dann entsprechende Weiterbildungsmaßnahmen eingeleitet wurden.
BP7: Define and monitor project interfaces and agreed commitments
Die Schnittstellen deines Teams oder Team of Teams in das Umfeld sind zum einen generisch im entsprechenden Framework beschrieben, eine Referenz hierauf kannst Du also heranziehen. Der Rest ist klassische Dokumentationsarbeit: Notiere in deinem Wiki welche anderen Teams, Abteilungen oder Organisationen (Kunden/Lieferanten) mit deinem Team of Teams interagieren. Notiere auch zu welchen Thema die jeweilige Schnittstelle ist, wann es Regelmeetings gibt und wer die Ansprechpartnerin ist.
Für alle Schnittstellen sollte es eine Vereinbarung geben. Intern reicht zumeist ein Wiki-Eintrag oder ein Besprechungsprotokoll. Für die Zusammenarbeit mit Entwicklungspartnerinnen erwarten die Guidelines jedoch unterschriebene Vereinbarungen.
Da auch hier „monitor“ steht, musst du auch hier zeigen, wann das geprüft wird und wie nachgesteuert wird. Auch hier sind Retrospektiven die primäre Plattform. Hier solltest du auch einen Eskalationsmechanismus nachweisen und Beispiele haben, wie dieser benutzt wurde.
BP8: Define and monitor project schedule
Die Definition erfolgt, indem parallel zu Backlogs Meilensteinpläne mitgeführt werden und so einige Sprints vorausgeplant wird (in SAFe passiert das im PI-Planning). Für die Entwicklungstätigkeiten ist das einfach, agile Ansätze sind ja darauf spezialisiert, in kurzen Takten zu prüfen und anzupassen. Hier kannst Du Reviews und Retros auf Team-Ebene und auf Team-of-Team-Ebene anführen. Burn-up- oder Burn-down-Charts sind gängige Werkzeuge für das Monitoring. Deine Dokumentation sollte es erlauben, hier im Assessment nachvollziehbare Beispiele zu liefern, wie Abweichungen erkannt wurden und darauf reagiert wurde.
Kümmere dich auch hier, wie in den vorigen Base Practices, um die Tätigkeiten, die normalerweise nicht im den agilen Backlogs stehen (unterstützende Prozesse, agile Rollen).
BP9: Ensure consistency
Während es in der BP8 um die Planabweichungen geht, geht es hier um die Konistenz zwischen den Zielen und der Umsetzung und um die Konsistenz der eigenen Planung mit Planungen außerhalb des Projekts (Kunden, Lieferanten, andere Abteilungen). Auch hier sind die verschiedenen Retro-Events die Plattform. Für den Nachweis, dass explizit die Konsistenz mitgeprüft wird, ist es nützlich, z.B. entsprechende Agenden und Protokolle für die Retros zu haben. Eine detaillierte Agenda für eine Retro ist natürlich nicht super agil, eine grobe Agenda im Sinne einer Checkliste („diese Aspekte wollen wir jedesmal im Kopf behalten“) wäre hier eine Lösung. Im Assessment solltest Du Beispiele zeigen können, wie Inkonsistenzen gefunden und behoben wurden.
BP10: Review and report progress of the project
Der Fortschritt sollte ohnehin in jedem Review oder in jeder Demo auf Team-of-Teams-Ebene gemessen und dokumentiert werden. Ein explizites Reporting für das Management ist bei agilen Ansätzen nicht vorgesehen. Ziel ist, alles in den bestehend Events und mit den bestehend Daten darstellen zu können. Vielleicht kannst Du mit Deinen Werkzeugen ein Dashboard mit den wichtigsten Metriken bauen. Wenn dann das Management immer mit den Reviews ist (oder z.B. in jedem zweiten Sprint Review) und du das mit Einladungen und Protokollen dokumentiert hast, deckt das diese BP schon gut ab. Gefundene Probleme können mit SUP.9 behandelt werden.
Hinweise zu Level 2
Das Management der Arbeitsprodukte musst du ohnehin im Griff haben, ob agil oder klassisch. Ich lege daher den Fokus hier auf GP2.1. Im Rahmen von MAN.3 geht es hier um das Projektmanagement des Projektmanagements, also wie du die Arbeiten zum Projektmanagement planst, überwachst und korrigierst. Wenn Du also bei BP4 und BP5 schon immer die Tätigkeiten der Product Owner und Scrum Master und ähnlicher Rollen mit aufgenommen hast, bist du fein raus und kannst hier nachweisen, wie du die Ausführung von MAN.3 planst und überwachst. Das klingt zunächst einfacher als gedacht, denn die “Management-Aufgaben” im agilen Umfeld sind so schwer zu definieren und zu schätzen wie die eines klassischen Projektleiters. Was im Assessment meist gut funktioniert, ist zu sagen, dass die Zeit der entsprechenden Rolle zu so und so viel Prozenten hier und dort hingeht, damit zeigst du, dass du dich mit dem Thema auseinandergesetzt hast. Dann noch ein Nachweis dazu, dass diese Annahmen insofern gut waren, dass es nie zu Verzögerungen oder Überlastungen geführt hat, dann sollte das als Argumentation passen. Eines noch: Was mit der Version 4.0 neu gekommen ist, dass alle Prozesse bei GP2.1.1 eine Strategie benötigen. Notiere dir also in deinem Wiki, wie du die Tätigkeiten von MAN.3 angehen willst.