Ausgangssituation
In der Welt von Kanban sprechen David Anderson – der Erfinder dieser Methode – und Klaus Leopold –Trainer und Pionier der ersten Stunde´– immer wieder von `Upstream´.
Dazu führt Leopold immer wieder aus, wie Arbeit auf der passenden Ebene von den passenden Personen im passenden Detail erledigt bzw. entschieden werden soll. Zur klaren Darstellung hat er drei Betrachtungsebenen definiert.
Quelle: Klaus Leopold, Leanability
Je höhere Ebenen in Verwendung sind, desto eher besteht die Chance einer gesamthaften Durchdringung und das Potential für die grösstmöglichen Effekte.
Wobei die Kraft dieser Ebenen nicht nur in diesen selbst, sondern v.a. in deren Verknüpfung besteht. So werden Vorhaben, welche auf der obersten – der strategischen – Ebene adressiert werden, in der untersten im Detail geplant, umgesetzt und deren Fortschritt beobachtet.
Letztendlich soll das zu erzeugende Ergebnis durch den gewünschten Effekt beim Einsatz die Ziele auf der obersten Ebene unterstützen. Die mittlere Gliederungsstufe dient der Koordination größerer Vorhaben zwecks gesamthafter Steuerung.
Das bedeutet wiederum, wie de facto JEDE lokale Entwicklung für eine große Wirkungsentfaltung die Verbindung über die Ebenen hinweg erforderlich macht.
Die klassische Welt kennt schon seit jeher eine ebenso dreistufige Gliederung. Die Ebenen werden je nach Höhe der hierarchischen Zuordnung geringer ausgedehnt dargestellt, um die Realität der zugehörenden Ressourcenanzahl samt einem typischen herkömmlichen Organigramm widerzuspiegeln.
Bei den Frameworks des Agiles Business Consortiums existieren sowohl für den Projekt- als auch für den Teil des Programmes und deren immanenten Anleitungen für den Business Analysten vorgelagerte Prozesse vor der Umsetzung der Vorhaben per se.
Quelle: www.agilebusiness.org
Ströme
Immer wieder erlebe ich mehr oder weniger heftigen Widerspruch der No-Design-Up-Front-Vertreter wegen deren Sicht auf von anderen als dem Entwicklungsteam vorgegebenen Leitlinien ohne zu hinterfragen, ob das auch solche sind.
Andere wiederum sind nur mit der Umsetzung beauftragt und werden auch erst ab diesem Zeitpunkt eingesetzt. Fehlende Informationen (`Wohin soll die Reise gehen?`, `Was soll de facto erreicht werden?` oder `Wozu soll das Ergebnis nutzen´) und/oder mangelhafte Arbeitsvereinbarungen münden in durchaus qualitativer Entwicklung gepaart mit der (partiellen) Nichtnutzung der erzeugten Produkte.
Die dritte zu beobachtende Bewegung dreht sich um die Abklärung neuer Anfragen, die mangels anderer Organisation bzw. Ressourcenknappheit (welche wiederum auf Ersteres zurück zu führen ist), auf die beteiligten Personen aktueller Umsetzungen für diese Evaluierungen abzielt – sprich Ressourcen abzieht. Dies erfolgt noch dazu oft mit dem Ziel, die neuen Anforderung bis ins Detail untersuchen zu wollen.
Detailbetrachtung AgilePM® / AgilePgM® / AgileBA®
Startend mit dem Fokus auf das Projekt identifizieren wir hier drei Phasen (`Pre-Project´, `Feasibility´ und `Foundations´) vor der Umsetzung im `Evolutionary Development´.
AgilePM®
Quelle: www.agilebusiness.org
Bei `Pre-Project´ werden primär Ideen auf deren Passung zu den übergeordneten Unternehmenszielen geprüft. Ideen dürfen und sollen von jedem Teil des Unternehmens kommen. Wichtig ist aber, nicht einfach darauf los zu marschieren, sondern diese Passung zum Unternehmen zu beleuchten. Damit ist auch die Grundlage der Mittel- und Ressourcenvergabe geklärt (gar nicht – jetzt – später – adaptiert Umfang).
Der Zweck von `Feasibility´ besteht darin, sowohl die technische Umsetzung als auch den möglich zu erzielenden käufmännischen Nutzen kurz zu hinterfragen.
In `Foundations´ werden dann grundlegende Vereinbarungen zur Lösungs-architektur, detaillierte Anforderungen (noch immer auf einer höheren richtungsweisenden Ebene), Umgebungen für Tests und Entwicklung sowie die Organisation der Teams mit passender Kommunikation samt einer Roadmap getroffen.
Genau betrachtet sind damit die Phasen `Pre-Project´ und `Feasibility´ Verbindungs-elemente zu übergeordneten Ebenen mit zumindest einer Verknüpfung zur obersten strategischen Stufe. `Foundations´ stellt durch die Arbeitsweisen auch eine prozess-qualitäts-orientierte Verbindung zu zumindest einer der oberen Ebenen her und dient gleichzeitig der Vorbereitung zur Entwicklung.
Betrachten wir als Nächstes den Ansatz des Business-Analysten auf Basis der bisherigen Ausführungen.
AgileBA®
Quelle: www.agilebusiness.org
Der Business-Analyst sollte zur optimalen Wirkung auf allen Ebenen agieren. Unterstützt er auf der Stufe des Unternehmens bei der gesamthaften strategischen Entwicklung und damit auch der Identifikation erforderlicher Maßnahmen zur Erreichung der gewünschten Position, agiert er auf den anderen Ebenen eher operativer mit einem eher länger- oder kurzfristigeren Betrachtungshorizont.
Wenngleich es oftmals nicht die gleiche Person sein wird, welche über alle Ebenen hinweg tätig ist und die Rollen besonders bei den oberen Ebenen oftmals anders benannt sind, sind die Aufgaben und die Übergabe bzw. der Austausch essentiell für die Qualität und die Passung der erzeugten Ergebnisse.
Sehen wir uns nun genauer das agile Programmanagement an.
AgilePgM®
Quelle: www.agilebusiness.org
Wir entdecken hier die gleiche Vorgangsweise wie bei AgilePM® auf der nächsten höheren koordinativen Ebene. Auch hier agiert der agile Businessanalyst (unter dem Namen Program Change Architect).
Zusammenfassung
Durch all diese Detailbetrachtungen ist klar zu erkennen, wie die VOR-Phasen vor der Projekt- und Programmebene oder Flight Level 1 & 2 de facto Aufgleisungstätigkeiten der Klärung, Priorisierung, Ressourcenzuweisung und Abwägung quer über die Ebenen sind. Möglicherweise ist im Gegensatz zur Projekt- die Vorphase 2 der Programmebene schon großteils auf dieser angesiedelt – aber das ist nur eine Feinheit.
Viel wichtiger ist die Bedeutung dieser Phasen für die Integration in ein großes Ganzes. Wo eben nicht jede Idee umgesetzt, aber jede Idee geprüft und sorgsam evaluiert wird. Wo jede Idee geschätzt wird und das Team in einem integrierten und ggf. in einem adaptierten jedoch abgesprochenen Rahmen selbstorganisiert zur Umsetzung schreiten kann. Eine Umsetzung, wo sich jeder kreativ auf die Erstellung konzentrieren und auf eine grobe Richtung zur Orientierung zurück greifen kann. Somit kann sich jeder auf den Arbeitsteil konzentrieren, wo volle Entfaltung Produkte zum Fliegen bringen.
Quercheck
Bisher haben wir immer nur die Zeit vor der Erstellung einem genaueren Blick unterzogen. Nach dem Projekt existiert auch noch eine Nachphase zur Feststellung der tatsächlichen Wirkung nach einer ersten Benutzungszeit. Die Rückintegration und ein Auslöser für eine Rückbetrachtung zum Lernen für künftige Vorhaben. Da ein agiles Programm schon während der üblicherweise längeren Laufzeit diese Wirkung beoachten und auch noch in dieser durch den Start weiterer Justierungsmassnahmen während der Laufzeit direkt beeinflussen kann, existiert dort im Zuge des Abschlusses die direkte Rückintegration samt Lernepotential ohne weitere Nachphase.
Rückblick
Durch die einfachen Anleitungen mitsamt vieler klarer empfohlener Fragestellungen, Workshops, Anleitungen zur Anforderungserhebung sowie Schätzungen und erforderlicher Rollen pro Phase, sind die Tätigkeiten vorab auf einfachste und produktivste Weise erfüllbar. Kommunikation, Abgleich und Integration sind gewährleistet.
Unnötige Arbeiten und v.a. Ursachen von Verschwendungsarten aus Lean-Sicht werden grundlegend vermieden. Bei entsprechender Organisation eines Spezialisten-Pools von Business Analysten mit dem großen Bild im Hinterkopf sind auch die Herausforderungen aus dem dritten Strom – der gleichzeitigen Behandlung zusätzlicher neuer Anfragen – auf effizienteste Art zu lösen und dabei den Fortschritt der laufenden Entwicklungen zu unterstützen. Wobei hier außerdem durch die qualitativ hochwertige Vorbereitung die Grundlage für etwaige weitere Umsetzungen auf optimale Art und Weise eröffnet wird.
Wie und mit welchen Mitteln der Business Analyst diese Ebenensprünge exakt vollzieht, entnehmen Sie bitte der Artikelreihe `Perlenschnur – I bis IV`!
Fazit
`Upstream ist absolut wichtig´. Dieser existiert genau wie bei Kanban in der Welt der Methoden des Agile Business Consortiums. Wie immer ist die Art und Weise des Umgang mit Abläufen durch die Anwender wesentlich und macht den Unterschied.
Über den Autor:
Dieter Strasser, MSc, CMC ist Inhaber und Geschäftsführer der Viable Projects GmbH
Wir bieten daher die Dienstleistung Facilitation zur Lösungsgewinnung an und bilden auch Ressourcen zur Erbringung der Dienstleistung aus. Partner mit „Facilitated by“-Status werden von uns mit Material und Coaching unterstützt. Ebenso wie von uns betreute Kunden.
Nähere Informationen über die Viable Projects GmbH
