{"id":4921,"date":"2018-01-18T09:09:13","date_gmt":"2018-01-18T07:09:13","guid":{"rendered":"https:\/\/www.weiterbildungsmarkt.net\/magazin\/?p=4921"},"modified":"2023-11-02T14:53:08","modified_gmt":"2023-11-02T12:53:08","slug":"upstream-von-agilepmagilebaagilepgm","status":"publish","type":"post","link":"https:\/\/www.weiterbildungsmarkt.net\/magazin\/upstream-von-agilepmagilebaagilepgm\/","title":{"rendered":"Upstream von AgilePM\u00ae\/AgileBA\u00ae\/AgilePgM\u00ae"},"content":{"rendered":"

Ausgangssituation<\/h2>\n

In der Welt von Kanban sprechen David Anderson \u2013 der Erfinder dieser Methode \u2013 und Klaus Leopold \u2013Trainer und Pionier der ersten Stunde\u00b4\u2013 immer wieder von `Upstream\u00b4.<\/p>\n

Dazu f\u00fchrt 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.<\/p>\n

\"Upstream1\"<\/p>\n

Quelle: Klaus Leopold, Leanability<\/em><\/p>\n

Je h\u00f6here Ebenen in Verwendung sind, desto eher besteht die Chance einer gesamthaften Durchdringung und das Potential f\u00fcr die gr\u00f6sstm\u00f6glichen Effekte.<\/p>\n

Wobei die Kraft dieser Ebenen nicht nur in diesen selbst, sondern v.a. in deren Verkn\u00fcpfung besteht. So werden Vorhaben, welche auf der obersten \u2013 der strategischen \u2013 Ebene adressiert werden, in der untersten im Detail geplant, umgesetzt und deren Fortschritt beobachtet.<\/p>\n

Letztendlich soll das zu erzeugende Ergebnis durch den gew\u00fcnschten Effekt beim Einsatz die Ziele auf der obersten Ebene unterst\u00fctzen. Die mittlere Gliederungsstufe dient der Koordination gr\u00f6\u00dferer Vorhaben zwecks gesamthafter Steuerung.<\/p>\n

Das bedeutet wiederum, wie de facto JEDE lokale Entwicklung f\u00fcr eine gro\u00dfe Wirkungsentfaltung die Verbindung \u00fcber die Ebenen hinweg erforderlich macht.<\/p>\n

Die klassische Welt kennt schon seit jeher eine ebenso dreistufige Gliederung. Die Ebenen werden je nach H\u00f6he der hierarchischen Zuordnung geringer ausgedehnt dargestellt, um die Realit\u00e4t der zugeh\u00f6renden Ressourcenanzahl samt einem typischen herk\u00f6mmlichen Organigramm widerzuspiegeln.<\/p>\n

\"Upstream2\"<\/p>\n

Bei den Frameworks des Agiles Business Consortiums existieren sowohl f\u00fcr den Projekt- als auch f\u00fcr den Teil des Programmes und deren immanenten Anleitungen f\u00fcr den Business Analysten vorgelagerte Prozesse vor der Umsetzung der Vorhaben per se.<\/p>\n

\"Upstream3\"<\/p>\n

Quelle: www.agilebusiness.org<\/em><\/p>\n

Str\u00f6me<\/h2>\n

Immer wieder erlebe ich mehr oder weniger heftigen Widerspruch der N<\/strong>o-D<\/strong>esign-U<\/strong>p-F<\/strong>ront-Vertreter wegen deren Sicht auf von anderen als dem Entwicklungsteam vorgegebenen Leitlinien ohne zu hinterfragen, ob das auch solche sind.<\/p>\n

Andere wiederum sind nur mit der Umsetzung \u00a0beauftragt 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\u00b4) und\/oder mangelhafte Arbeitsvereinbarungen m\u00fcnden in durchaus qualitativer Entwicklung gepaart mit der (partiellen) Nichtnutzung der erzeugten Produkte.<\/p>\n

Die dritte zu beobachtende Bewegung dreht sich um die Abkl\u00e4rung neuer Anfragen, die mangels anderer Organisation bzw. Ressourcenknappheit (welche wiederum auf Ersteres zur\u00fcck zu f\u00fchren ist), auf die beteiligten Personen aktueller Umsetzungen f\u00fcr diese Evaluierungen abzielt \u2013 sprich Ressourcen abzieht. Dies erfolgt noch dazu oft mit dem Ziel, die neuen Anforderung bis ins Detail untersuchen zu wollen.<\/p>\n

Detailbetrachtung AgilePM\u00ae<\/sup> \/ AgilePgM\u00ae<\/sup> \/ AgileBA\u00ae<\/sup><\/h2>\n

Startend mit dem Fokus auf das Projekt identifizieren wir hier drei Phasen (`Pre-Project\u00b4, `Feasibility\u00b4 und `Foundations\u00b4) vor der Umsetzung im `Evolutionary Development\u00b4.<\/p>\n

AgilePM\u00ae<\/sup><\/strong><\/p>\n

\"Upstream4\"<\/p>\n

Quelle: www.agilebusiness.org<\/em><\/p>\n

Bei `Pre-Project\u00b4 werden prim\u00e4r Ideen auf deren Passung zu den \u00fcbergeordneten Unternehmenszielen gepr\u00fcft. Ideen d\u00fcrfen 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\u00e4rt (gar nicht \u2013 jetzt \u2013 sp\u00e4ter \u2013 adaptiert Umfang).<\/p>\n

Der Zweck von `Feasibility\u00b4 besteht darin, sowohl die technische Umsetzung als auch den m\u00f6glich zu erzielenden k\u00e4ufm\u00e4nnischen Nutzen kurz zu hinterfragen.<\/p>\n

In `Foundations\u00b4 werden dann grundlegende Vereinbarungen zur L\u00f6sungs-architektur, detaillierte Anforderungen (noch immer auf einer h\u00f6heren richtungsweisenden Ebene), Umgebungen f\u00fcr Tests und Entwicklung sowie die Organisation der Teams mit passender Kommunikation samt einer Roadmap getroffen.<\/p>\n

Genau betrachtet sind damit die Phasen `Pre-Project\u00b4 und `Feasibility\u00b4 Verbindungs-elemente zu \u00fcbergeordneten Ebenen mit zumindest einer Verkn\u00fcpfung zur obersten strategischen Stufe. `Foundations\u00b4 stellt durch die Arbeitsweisen auch eine prozess-qualit\u00e4ts-orientierte Verbindung zu zumindest einer der oberen Ebenen her und dient gleichzeitig der Vorbereitung zur Entwicklung.<\/p>\n

Betrachten wir als N\u00e4chstes den Ansatz des Business-Analysten auf Basis der bisherigen Ausf\u00fchrungen.<\/p>\n

AgileBA\u00ae<\/sup><\/strong><\/p>\n

\"Upstream5\"<\/p>\n

Quelle: www.agilebusiness.org<\/em><\/p>\n

Der Business-Analyst sollte zur optimalen Wirkung auf allen Ebenen agieren. Unterst\u00fctzt er auf der Stufe des Unternehmens bei der gesamthaften strategischen Entwicklung und damit auch der Identifikation erforderlicher Ma\u00dfnahmen zur Erreichung der gew\u00fcnschten Position, agiert er auf den anderen Ebenen eher operativer mit einem eher l\u00e4nger- oder kurzfristigeren Betrachtungshorizont.<\/p>\n

Wenngleich es oftmals nicht die gleiche Person sein wird, welche \u00fcber alle Ebenen hinweg t\u00e4tig ist und die Rollen besonders bei den oberen Ebenen oftmals anders benannt sind, sind die Aufgaben und die \u00dcbergabe bzw. der Austausch essentiell f\u00fcr die Qualit\u00e4t und die Passung der erzeugten Ergebnisse.<\/p>\n

Sehen wir uns nun genauer das agile Programmanagement an.<\/p>\n

AgilePgM\u00ae<\/sup><\/strong><\/p>\n

\"Upstream6\"<\/p>\n

Quelle: www.agilebusiness.org<\/em><\/p>\n

Wir entdecken hier die gleiche Vorgangsweise wie bei AgilePM\u00ae<\/sup> auf der n\u00e4chsten h\u00f6heren koordinativen Ebene. Auch hier agiert der agile Businessanalyst (unter dem Namen Program Change Architect).<\/p>\n

Zusammenfassung<\/h2>\n

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\u00e4tigkeiten der Kl\u00e4rung, Priorisierung, Ressourcenzuweisung und Abw\u00e4gung quer \u00fcber die Ebenen sind. M\u00f6glicherweise ist im Gegensatz zur Projekt- die Vorphase 2 der Programmebene schon gro\u00dfteils auf dieser angesiedelt \u2013 aber das ist nur eine Feinheit.<\/p>\n

Viel wichtiger ist die Bedeutung dieser Phasen f\u00fcr die Integration in ein gro\u00dfes Ganzes. Wo eben nicht jede Idee umgesetzt, aber jede Idee gepr\u00fcft und sorgsam evaluiert wird. Wo jede Idee gesch\u00e4tzt 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\u00fcck greifen kann. Somit kann sich jeder auf den Arbeitsteil konzentrieren, wo volle Entfaltung Produkte zum Fliegen bringen.<\/p>\n

Quercheck<\/h2>\n

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\u00e4chlichen Wirkung nach einer ersten Benutzungszeit. Die R\u00fcckintegration und ein Ausl\u00f6ser f\u00fcr eine R\u00fcckbetrachtung zum Lernen f\u00fcr k\u00fcnftige Vorhaben. Da ein agiles Programm schon w\u00e4hrend der \u00fcblicherweise l\u00e4ngeren Laufzeit diese Wirkung beoachten und auch noch in dieser durch den Start weiterer Justierungsmassnahmen w\u00e4hrend der Laufzeit direkt beeinflussen kann, existiert dort im Zuge des Abschlusses die direkte R\u00fcckintegration samt Lernepotential ohne weitere Nachphase.<\/p>\n

R\u00fcckblick<\/h2>\n

Durch die einfachen Anleitungen mitsamt vieler klarer empfohlener Fragestellungen, Workshops, Anleitungen zur Anforderungserhebung sowie Sch\u00e4tzungen und erforderlicher Rollen pro Phase, sind die T\u00e4tigkeiten vorab auf einfachste und produktivste Weise erf\u00fcllbar. Kommunikation, Abgleich und Integration sind gew\u00e4hrleistet.<\/p>\n

Unn\u00f6tige 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\u00dfen Bild im Hinterkopf sind auch die Herausforderungen aus dem dritten Strom \u2013 der gleichzeitigen Behandlung zus\u00e4tzlicher neuer Anfragen \u2013 auf effizienteste Art zu l\u00f6sen und dabei den Fortschritt der laufenden Entwicklungen zu unterst\u00fctzen. Wobei hier au\u00dferdem durch die qualitativ hochwertige Vorbereitung die Grundlage f\u00fcr etwaige weitere Umsetzungen auf optimale<\/span> Art und Weise er\u00f6ffnet wird.<\/p>\n

Wie und mit welchen Mitteln der Business Analyst diese Ebenenspr\u00fcnge exakt vollzieht, entnehmen Sie bitte der Artikelreihe `Perlenschnur \u2013 I bis IV`!<\/p>\n

Fazit<\/h2>\n

`Upstream ist absolut wichtig\u00b4. 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\u00e4ufen durch die Anwender wesentlich und macht den Unterschied.<\/p>\n

\u00dcber den Autor:<\/h3>\n

\"Strasser\"Dieter Strasser, MSc, CMC<\/strong> ist Inhaber und Gesch\u00e4ftsf\u00fchrer der Viable Projects GmbH<\/p>\n

Wir bieten daher die Dienstleistung Facilitation zur L\u00f6sungsgewinnung an und bilden auch Ressourcen zur Erbringung der Dienstleistung aus. Partner mit \u201eFacilitated by\u201c-Status werden von uns mit Material und Coaching unterst\u00fctzt. Ebenso wie von uns betreute Kunden.<\/p>\n

N\u00e4here Informationen \u00fcber die Viable Projects GmbH<\/b><\/p>\n