Wie kann im Scaled Agile Framework (SAFe) an Projekten ...

korn.ch

Wie kann im Scaled Agile Framework (SAFe) an Projekten ...

Wie kann im Scaled Agile Framework (SAFe) an Projekten

gearbeitet werden?

17.07.2013, 11:27 - zuletzt bearbeitet am 17.07.2013, 14:54Von Hans-Peter Korn

Das SAFe http://scaledagileframework.com/ versteht sich im Gegensatz zu einem

Projektmanagement-Framework als agiles Framework zur kontinuierlichen Lieferung

produktiv nutzbarer Lösungen in (internen) „Releases“ im Rahmen der Neu- und

Weiterentwicklung und der Wartung von Produkten längs ihrer gesamten Lebenszeit. SAFe

nennt daher bewusst keinerlei auf „Projekte“ bezogene Rollen oder Artefakte.

Dean Leffingwell spricht sich in seinem Buch "Agile Software Requirements: Lean

Requirements for Teams Programs and the Enterprise. Addison Wesley, 2010" auf den

Seiten 441 bis 441 ja auch explizit gegen "Projekte" aus.

SAFe geht davon aus, dass es eher stabil zusammengesetzte Teams in Form längerfristig

existierender Einheiten gibt, die (Teil)Features (und allenfalls Komponenten) innerhalb eines

"Agile Release Trains" so bearbeiten, dass dieser Zug in regelmässigen Abständen PSIs als

(interne) Releases liefert.

Wie aber funktioniert das in so einem - typischen - Fall (anzutreffen etwa bei ERP-

Anbietern, aber auch bei Herstellern von Steuerungssystemen (HW plus embedded

SW))?

Basis der - kundenspezifischen - Produkte (oft auch Gross-Serien-Produkte) ist eine

kundenneutrale "Plattform".

Kundenspezifische Produkte sind Kombinationen einzelner - angepasster - Module /

Komponenten dieser Plattform, ergänzt um kundenspezifische Lösungen.

Verbreitet sind heute diese Vorgehensweisen:

Es gibt ein oder mehrere Teams, die sich nur um die Plattform kümmern.

Kundenspezifische Produkte werden in Projekten (gelegentlich mehrere Hundert parallel)

mit je einem oder mehreren - nur dafür temporär zusammengestellten - Projektteams

entwickelt. Nach der Auslieferung werden diese Teams aufgelöst und kehren wieder in ihre

"Stammteams" zurück. Das können auch die Teams der Plattformentwicklung sein. Die -

weitaus weniger Ressourcen erfordernde - weitere Betreuung dieser ausgelieferten Produkte

erfolgt entweder in mehrere Produkte betreuenden "Wartungsteams" oder in den

Plattformteams.

Wenn ich SAFe richtig verstehe, dann kann die Plattformentwicklung (und deren Teams) als

ein oder mehrere "Agile Release Trains" organisiert werden.

Was aber mit den temporären (bis zu 3 Jahren arbeitenden) unzähligen "Kundenprojekt-

Teams", welche eventuell sogar Elemente mehrere ART nutzen?

Ist jedes Kundenprojekt ein - temporärer - ART? Also ev. hunderte ARTs?

(Die Zusammenfassung mehrerer Kundenprojekte in einen ART wäre recht künstlich, weil

der Releasetakt pro Kundenprojekt ja i.a. unterschiedlich ist.)

Eine andere Vorgehensweise ist:

Es gibt ein oder mehrere Feature- und Component-Teams, die sich um die Plattform

kümmern. Kundenspezifische Produkte werden als temporäre (auch mehrere Jahre

dauernde) Projekte abgewickelt derart, dass die Projektleiter die jeweiligen Plattform-

Teams mit der kundenspezifischen Anpassung ihrer Plattform-Elemente und mit der


Realisierung kundenspezifischer Lösungen beauftragen. Ein spezifisches Team kümmert

sich dann um die kundenspezifische Integration dieser von diversen Teams realisierten

Kundenlösungen. Die weitere Betreuung der ausgelieferten Produkte erfolgt dann in den

Plattformteams, die von den kundenprodukt-spezifischen Integrationsteams oder von

speziellen "Trage-Teams" angesteuert werden.

Gemäss SAFe könnten dann die Plattform-Teams (ev. hunderte bis tausende über die ganze

Welt verteilte Entwickler, organisiert in mehreren ARTs), auch die kundenspezifischen

Lösungen entwickeln. Die "Integrationsteams" könnten dann so etwas in der Art von

"Deployment Operation Teams"http://scaledagileframework.com/devops/ sein, jedoch nicht

pro ART sondern ART-übergordnet (wenn Kundenprojekte Plattform-Elemente mehrere

ARTs nutzen).

Die - ev. mehrere hundert - Kunden-PL wären dann auf der Ebene des Programm

Managements angesiedelt. Dort würde dann auch die kundenprojekt-spezifische

"Beauftragung" der einzelnen Teams via deren POs erfolgen.

Nachteil hier: Die Arbeit an spezifischen Kundenprojekten wird "fragmentiert",

Schnittstellen zwischen den zum Kundenprojekt beitragenden Teams müssen dann vom PL

und vom Integrationsteam gemanagt werden.

All das würde beim Vorgehen auf Basis temporärer (hunderter) Kundenprojektteams von

diesen Teams selber (teamintern) gemanagt werden. Die Arbeit auf Basis temporärer

Kundenprojektteams entspricht jedoch nicht dem "produktorientierten" Organisationsprinzip

des SAFe.

SAFe führt also in Fällen ART-übergreifender Kundenprojekte zu einem erheblichen

Planungs- und Koordinations-Overhead.

Wie also kann mittels SAFe das Vorgehen bei grossen Kundenprojekten auf Basis einer umfassenden

kundenneutralen Plattform gestaltet werden - ohne dass es zu einem erheblichen Planungs- und

Koordinations-Overhead führt?


Kommentar von Hans-Peter Kornam 17.07.2013, 12:22

((Antwort von Felix Rüssel in https://www.xing.com/net/pri610d2ex/saf/das-scaled-agile-frameworkunter-der-lupe-733554/wie-kann-tr...))

Nur ganz kurz, stichwortartig ein paar Gedanken dazu:

- Grundsätzlich lassen sich Abhängigkeiten nie ganz vermeiden, dieses Problem ist unabhängig von

der Methode. Je besser Abhängigkeiten reduziert werden können (ggf. auch durch Doppelung --> u-

curve optimization), desto einfacher haben es die ARTs bei der Planung

- Langlaufende Projekte können häufig als ARTs implementiert werden

- Kleinere / kurze Projekte können als Epics in einem ART modelliert werden

- Gibt es Kundenprojekte und ist die interne Produkterstellung in ARTs strukturiert, dann sind die

Kundenprojekte Stakeholder für die ARTs. Für die Entwicklung sollte dies gut funktionieren. Natürlich

kann es vorkommen, dass ein Projekt etwas anfordert und nicht erhält. Bei einem funktionierenden

Entscheidungsrahmen hinsichtlich Wirtschaftlichkeit, ist dies die richtige Entscheidung und ggf. ist das

Projekt einzustellen (Kosten hierfür wurden ja richtig berücksichtig ;-)).

- In den meisten Fällen werden die positiven Effekte von Plattformstrategien überbewertet.

- Projekte, die mit unterschiedlichsten ARTs zu tun haben (sehr cross orga sind), benötigen imho


immer eine eigene Projekt-Organisation (ungleich ART). Deshalb greift die ganze Diskussion rund um

"was mache ich mit den Projektleitern wenn ich Scrum/SAFe/tralala einsetze?" im Allgemeinen zu kurz.

Habe ich Projekte, dann brauche ich Projektleiter (++). Wie diese arbeitet kann nicht generell geklärt

werden. Optimierung der Transaktionskosten in Hinblick auf vorherrschende Organisationsmodelle ist

attraktiv.

- viele Unternehmen haben zu viele Projekte - viele davon inaktiv/halbtot bzw. ohne Projektcharakter.

Es gibt keine Governance bzgl. Projektstart und Projekt-Exit ("wie töte ich Projekt 328?")

- Projekte sind grundsätzlich eine teure Organisationsform, da temporär und quer zur

Aufbauorganisation und ggf quer zu einer (weiteren) Ablauforganisation z.B. nach SAFe (statt Matrix

dann eben ein dreidimensionales Bezugssystem?!) - dies ist zu berücksichtigen

- Einbindung Kunden-PL in interne Organisation ist stark vom Vertragswerk abhängig. Hier kann

beliebiges Konfliktpotential verborgen sein.

- Herausforderung ist der Betrieb der erstellten Lösungen. Ist dies noch ein Projekt? Eher nein - aber

durch ein Projekt ggf. zu finanzieren (Posten Budget in Kalkulation). Die Betriebsorganisation ist so zu

strukturieren, dass auch die relevanten Herausforderungen attraktive Antworten gegeben werden.

Keine generelle Aussage möglich. Was sagen die Verträge?

o ************************************************************************


Kommentar von Hans-Peter Kornam 17.07.2013, 12:32

Mit dieser Aussage:

""Projekte, die mit unterschiedlichsten ARTs zu tun haben (sehr cross orga sind), benötigen imho

immer eine eigene Projekt-Organisation (ungleich ART)""

wird bestätigt, dass SAFe keine passende Organisationsform für - auch mehrere Jahre dauernde -

projektmässige Arbeiten für kundenspezifische Lösungen auf Basis von kundenneutralen Elementen

einer umfassenden Plattform (bereitgestellt von mehreren ARTs des SAFe) ist.

Nun kenne ich aber - insbesondere grosse - Unternehmen, die den grössten Teil ihrer

Personalressourcen für hunderte Kundenprojekte einsetzen und dafür vergelchsweise wenig

Ressourcen für die kundenneutrale Plattform investieren.

Die Idee, ""Langlaufende Projekte können häufig als ARTs implementiert werden"" ist dann auch keine

Lösung, da dann an vielen ARTs nur jeweils ein Team arbeitet (was nicht der Sinn eines ART ist) und

zudem im SAFe keine Vorgehensweise zur Koordinierung hunderter solcher "Projekt-ARTs" existiert,

siehe in http://www.sigsdatacom.de/fileadmin/user_upload/zeitschriften/os/2013/04/janning_OS_04_13_sze6.pdf

den

Abschnitt "Grenzen grosser Organisationen"

o ************************************************************************


Kommentar von Rainer Grauam 17.07.2013, 14:41

Hallo Hans-Peter

deine Frage ist nicht eindeutig? Was ist für dich ein Projekt? Ein Business-Projekt? ein IT-Projekt?

Dean's Konzept basiert auf der Grundlage, dass ein (Release Train) Team mit allem, was dazu gehört

an Personen, über Investment Themes finanziert wird.


Ein Investment Theme kann z.B. über das Budget eines Business Projekts finanziert werden. Die

Finanzierung kann auch über das Stellen von Personen geschehen.

Beispiel:

- Business Projekt A bearbeitet Thema X und bekommt das Budget B1 dazu

- Business Projekt B bearbeitet Thema Y und bekommt das Budget B2 dazu

- Business Projekt C bearbeitet Thema Z und bekommt das Budget B3 dazu

Release Train T1 arbeitet an den Themen Y und Z und wird (nach einer Entscheidung aus dem

Management) mit 40% von B2 und 20% aus B3 finanziert

Release Train T2 arbeitet an den Themen X, Y und Z und wird (nach einer Entscheidung aus dem

Management) mit 100% aus B1, 60% von B2 und 80% aus B3 finanziert.

Release Train 1 könnte zum Beispiel in einer Bank den Zahlungsverkehr als IT-Fokus haben und

Release Train 2 das Wealth Management. Thema Z wären etwa shared services.

Also eine ganz übliche Matrix Organisation und übliche Budgetierung. Leider finde ich noch keine

rollierende Budgetierung oder einen Beyond Budgeting Ansatz im SAFe. Vielleicht kommt das ja noch.

SAFe ist ja im Grunde eine Sammlung von good practices, die auch ohne sie über SAFe in einen

expliziten Zusammenhang zu setzen, existieren und genutzt werden.

Für mich wäre ein Kundenprojekt (deine Terminologie) ein Business Projekt (meine Terminologie). Im

Outsourcing Mode würde halt der Kunden eine Prozentsatz zum Thema XYZ an den Outsourcing

Provider verschieben.

Gibt dir das einen Anhaltspunkt, wie SAFe damit umgeht?

Gruss Rainer

o ************************************************************************


Kommentar von Felix Rüsselam 17.07.2013, 15:05

Ich glaube wir kommen mit der theoretischen Diskussion nicht weiter sondern sollten an einem

konkreten Beispiel diskutieren und dann wieder generalisieren.

Häufig wird es auf Zulieferer-/Abnehmerbeziehungen herauslaufen. Warum sollten sich sonst

"Projekte" weitergehend abstimmen müssen, wenn doch klar (1) generische Plattform und (2)

projektspezifische Lösung getrennt werden könnte. Falls nicht - warum?

"Hunderte Projekte" - das kann doch alles sein. Ist damit ein Kernteam von 1-2 Personen gemein, die

auf Zulieferungen angewiesen sind? Was sind "projektmässige Arbeiten"? Dedizierte

Projektmitarbeiter oder Mitarbeiter-Pooling und hoher Spezialisierungsgrad? Sind es überhaupt

Projekte und wie funktioniert es heute (Initiierung, Durchführung, Abschluss, Controlling,

Wirtschagftlichkeitsbetrachtung, PMO, Governance, Guidance)?

Falls aktuell eine echte Projektorganisation existiert - ist dies erfolgreich? Warum ändern, wenn es

funktioniert? Falls nicht - was sind die Herausforderungen? Macht eine Umstellung Sinn?

Ist die Plattform wirklich Plattform? Ist die Entscheidung pro Plattform wirtschaftlich sinnvoll? Was

wären Alternativen?

Um was für ein Unternehmen handelt es sich? Welche Freiheitsgrade bzgl strategischer Ausrichtung

existieren (z.B. stark limitiert bei den internen IT Dienstleistern der meisten Konzerne). Welche

Rahmenbedingungen?


Produktorientiertes Unternehmen? Marktorientiertes Unternehmen? Unternehmen mit starkem

Engineering-Fokus?

o ************************************************************************

Brigitte Pfeifer-Schmöller findet das interessant.


Kommentar von Hans-Peter Kornam 17.07.2013, 15:15

Nein, das gibt mir leider keinen Anhaltspunkt.

Also, in anderen Worten:

Ein grosser global tätiger Anbieter kundenspezifischer Lösungen entwicklelt diese unter Nutzung einer

umfassenden kundenneutralen Plattform.

Diese Plattform kann fortlaufend auf Basis von SAFe in mehreren ART (abgeleitet aus Investment-

Themen) weiterentwicklelt werden.

Die kundenspezifischen Lösungen werden in bis zu mehreren hundert parallelen (keine Phantasie

sondern ein konkreter Fall) Projekten, die bis zu drei Jahre dauern und jeweils von einem bis

mehreren "Kundenprojekt-Teams" entwicklelt. Diese kundenspezifische Produkte sind Kombinationen

einzelner - angepasster - Module / Komponenten der Plattform, ergänzt um kundenspezifische

Lösungen.

Das ist die Situation.

Um das zu organisieren, habe ich im meinem Start-Posting zwei möglche Vorgehensweise

aufgezeigt.

Im ersten Fall kann die umfangreiche Plattform basierend auf SAFe in mereren ARTs entwicklelt und

aktuell gehalten werden.

Die mehreren hundert Kundenprojekte würden sich ihrer bedienen, funktionieren jedoch nicht auf

Basis von SAFe sondern sind übliche - temporäre - Projekte mit temporären Projektteams.

Also: SAFe allein genügt nicht - es braucht weiterhin zusätzlich eine Projekt-Organisaiton für die

Kundenprojekte.

Im zweiten Fall wird alles auf Basis SAFe erledigt, die Arbeiten für Kundenprojekte werden vom

jeweiligen PL (das sind deren mehrere hundert) auf die Teams der Plattform-ARTs aufgeteilt. Nachteil

hier: Die Arbeit an spezifischen Kundenprojekten wird "fragmentiert", Schnittstellen zwischen den zum

Kundenprojekt beitragenden Teams müssen dann vom PL und von einem "Integrationsteam" pro

Kundenprojekt gemanagt werden.

SAFe führt also in Fällen ART-übergreifender Kundenprojekte zu einem erheblichen Planungs- und

Koordinations-Overhead.

Wie also kann im Scaled Agile Framework an solchen Projekten gearbeitet werden?

Oder klappt das nicht - und die erste Variante ist die optimalere?

o ************************************************************************



Kommentar von Hans-Peter Kornam 17.07.2013, 15:44 - zuletzt bearbeitet am 18.07.2013, 1:43

@ Felix:

> Ich glaube wir kommen mit der theoretischen Diskussion nicht weiter

Das ist kein theoretischer Fall sondern die - anonymisierte - Beschreibung einer Situation in sehr

grossen Unternehmen

> Warum sollten sich sonst "Projekte" weitergehend abstimmen müssen, wenn doch klar (1)

generische Plattform und (2) projektspezifische Lösung getrennt werden könnte.

Das wird in diesem Fall getrennt. Und dann - so verstehe ich dich - erfolgt die Plattformentwicklung

aus Basis SAFe und die Kundenprojekt laufen unabhängig von SAFe wie bisher als Projekte.

> "Hunderte Projekte" - das kann doch alles sein.... etc

Ist aber - bei einem Unternehmen - so. Es sind weltweit zwischen 5 und 10-tausend (!!!) Entwickler

damit beschäftigt. Immer in eher grossen als kleinen Projektteams. Durchlaufzeit bis zu drei Jahre.

> Falls aktuell eine echte Projektorganisation existiert - ist dies erfolgreich?

Ja - es gibt aber noch zu viele Beiträge (d.h. Schnittstellen) von den "Plattformleuten" an die

Kundenprojektteams. Und die Kundenprojekt-Teams sind eher nach systemkomponenten als nach

"features" strukturiert.

> Warum ändern, wenn es funktioniert? Falls nicht - was sind die Herausforderungen? Macht eine

Umstellung Sinn?

Die Idee (bzw. Hoffnung) ist, durch eine noch stärkere Abkopplung von der Plattformarbeit und durch

eine bessere "crossfunktionalität" in den Kundenprojekt-Teams die Schnittstellen zwischen den

Teams und zur Plattform stark zu reduzieren und damit die Kosten zu senken.

Diese Idee würde bedeuten, die autonomen - temporären - Kundenprojektteams zu stärken und nicht

die Arbeit in quer zu den temporären Projekten liegenden ARTs, welche sowohl die Plattform pflegen

als auch für diverse Projekte arbeiten (wie es SAFe - nach meinem Verständnis - fordert).

> Um was für ein Unternehmen handelt es sich?

Darf ich nicht sagen... es sind zwei ...

> Welche Freiheitsgrade bzgl strategischer Ausrichtung existieren (z.B. stark limitiert bei den internen

IT Dienstleistern der meisten Konzerne).

Grosse Freiheit. IT ist Kernelement der Produkte in beiden Fällen.

> Produktorientiertes Unternehmen? Marktorientiertes Unternehmen?

Beides.

> Unternehmen mit starkem Engineering-Fokus?

Ja weil beim einen IT Kernelement der Produkte ist. Beim anderen Untenehmen im ERP-Bereich eher

weniger.

o ************************************************************************



Kommentar von Felix Rüsselam 17.07.2013, 17:46

Ich sehe hier die grundlegende Schwierigkeit ein Projektorganisation mit einer Organisation für

Produktentwicklung zu verheiraten. Hierzu gibt es keine einfache Lösung sondern da muss viel

ausprobiert werden.

Ich verstehe nicht, was mit "Beiträge" aus den Projekten zu den Plattform-Leuten (Produkt?) gemeint

ist. Ein Produkt hat per Definition eine gewisse Charakteristik, für die Planung der Weiterentwicklung

ist ein Produktmanagement zuständig. Hierzu wird der Bedarf analysiert und entsprechend geplant.

Werden die Bedarfe aus den Projekten bei der Produktentwicklung nicht genügend berücksichtigt,

dann haben wir ein Problem bei der Abstimmung Produktmanagement / Projektmanagement.

Allerdings: Wenn eine Sache für ein Projekt wichtig ist, dann muss es nicht auch für das Produkt

wichtig sein. Die Frage ist demnach auch, wer die Attraktivität aus Unternehmenssicht bewertet und

ob alle Faktoren berücksichtigt werden (z.B. Transaktionskosten, Komplexitätssteigerung in der

unternehmensinternen Abläufen, innere Qualität der Produkte/Dienste, ...).

Eine interessante Case Study dazu, wie Demand Management in einem mittelgroßen Kontext für

SAFe funktionieren kann gibt es hier:

http://www.agilenotanarchy.com/2013/02/scaled-agile-framework-applied-25.html

Das muss mich sich ein wenig größer denken und ggf. hat man ein paar Ideen mehr.

An der grundsätzlichen Problematik von Abstimmung zw. Projekt/Produkt ändert dies nichts. Häufig

versteckt sich dahinter ja auch ein mangelhaftes strategische Alignment. Ein Unternehmen kann eben

nicht produktorientiert (Betrachtung Produkt ohne Rücksicht auf Marktumfeld) und marktorientiert

(Fokus auf Markt) und produktionsorientiert (Fokus auf interne Leistungserbringung) sein.

o ************************************************************************


Kommentar von Hans-Peter Kornam 18.07.2013, 1:48 - zuletzt bearbeitet am 18.07.2013, 1:49

Ja, das ist die zentrale Frage:

> Ich sehe hier die grundlegende Schwierigkeit ein Projektorganisation mit einer Organisation für

Produktentwicklung zu verheiraten.

Und eine Erkenntnis aus dieser Diskussion hier ist für mich, dass Dean Leffingwells Kritik an

"Projekten" in seinem Buch "Agile Software Requirements: Lean Requirements for Teams Programs

and the Enterprise. Addison Wesley, 2010" auf den Seiten 441 bis 441 und auch anderer Leute, die

"Agilität" und "Projekte" als Widerspruch sehen tiefer diskutiert werden muss.

Es scheint also ein gutes Vorgehen zu sein, die Entwicklung der kundenneutralen "Produktbasis" (=

"Plattform") auf Basis von SAFe zu gestalten.

Die Entwicklung der diese Basis bzw. Plattform nutzenden kundenspezifischen Produkte jedoch sollte

im Rahmen von Projekten erfolgen - und nicht auf Basis von SAFe.

Essentiell ist, dass die Weiterentwicklung der Produktbasis (= "Plattform) die aktuellen Anforderungen

der Kundenprojekte kennt und berücksichtigt.


(((Deine Frage: "Ich verstehe nicht, was mit "Beiträge" aus den Projekten zu den Plattform-Leuten

(Produkt?) gemeint ist." ist verursacht durch einen Schreibfehler den ich so korrigiert habe: "es gibt

aber noch zu viele Beiträge (d.h. Schnittstellen) von den "Plattformleuten" an die

Kundenprojektteams.")))

o ************************************************************************


Kommentar von Wolfram Mülleram 26.07.2013, 15:06 - zuletzt bearbeitet am 26.07.2013, 15:10

vorab - ich bin gerade in der gleichen Situation. Uns (VISTEM/Speed4Projects) hat ein Unternehmen

beauftragt ein Konzept zu entwickeln (und dann wohl auch umsetzen zu helfen) - 350 Großprojekte

(Laufzeit 1-3 Jahre), unzählige kleine Changes und 4000 Entwickler (weltweit verteilt) und klar

Plattformbasiert in Kombination mit Kundenprojekten ...

du hast die Frage gestellt a) entweder Projekt/Plattform-Organisation oder b) Feature/Komponenten

Orientiert?

ich denke es gibt zwei Aspekte, die die Frage beantworten. #1 die Skalierbarkeit ist eine Funktion der

Anzahl der notwendigen Kommunikationskanäle/Abstimmungen - die Kommunikationsaufwand steigt

irgendwas zwischen Quadratisch und Exponentiell --> ich würde immer die wählen mit der geringeren

Anzahl --- deutet auf a) Projekt/Plattform

#2 habe ich Demand mit dem gleichen Charakteristik oder sind es zwei ... hier haben wir Projekte und

Produkte also zwei unterschiedliche Charakteristiken - wenn man das mit einem Steuerungssystem

versucht zu erschlagen ist das suboptimal --- deutet wieder auf a) Projekt/Plattform hin

ABER richtig gut fühlt sich a) auch nicht an - oder?

Daher würde ich gerne nach eine dritte noch elegantere Lösung suchen wollen. Beim letzten Kunden

(nur 350 Entwickler) haben wir eine Kombination aus CCPM und Ultimate Scrum eingeführt - sehr

schöne Regeleigenschaften, wenige Kommunikation - sehr effizient. Allerdings sehr projektorientiert

und wenig Plattform/Produkt - aber in Ansätzen drin.

c) ich würde daher noch eine Stufe weiter gehen und Letzt endlich nicht Projekt/Safe sondern

vollintegriert Projekt und Produkt - beide Steuerungen sind nämlich _einfach_ zu kombinieren. Und

zwar an der Stelle der operativen Priorität von Stories :-)

Hier nur eine gröbste Skizze:

* Portfolio/Demandmanagement ähnlich wie bei Safe ganz oben. Der Demandfunnel wird über aber

über Throughput Accounting Ideen gesteuert (nicht ROI). Zum Terminieren kommt entweder eine DBR

(für Projekt) oder eine sDBR (für die Kleinaufträge) zum Zuge. Damit werden auch Trade-Offs

transparent und das Board kann die strategischen Prioritäten setzen

* auf der untersten Eben ähnlich wie bei Safe finden sich die Teams, die Teilprojekte erzeugen. Hier

kommt im Gegenzug zu Safe kein reinrassiges Scrum zum Zuge sondern wie schon beschrieben

Reliable/Ultimate Scrum. Reliable Scrum um Epics sicher zu einem Termin liefern zu können – damit

diese in Projekten funktionieren und Ultimate Scrum um eben einfacher Kleinaufträge und Stories aus

Epics mischen zu können und klar um schneller Durchlaufzeiten zu erreichen und einen klaren Fokus

des Teams auf Fluss zu ermöglichen.

* der Clou ist die Mittelschicht. Die Mittelschicht in der vorgeschlagenen Idee dient dazu die „operative

Priorität“ der Stories in den Backlogs zu erzeugen – so dass jedes Team genau weiß in welcher

Reihenfolge es die Stories ziehen muss um die im Portfoliomanagement genannten Termine erreichen


zu können. Hier gibt es zwei bewährte Methoden a) Critical Chain Buffer Management – ergibt eine

rot-gelb-grün Ampel und b) die sDBR-Ampel über die Restlaufzeit bis zum Due-Date – auch wieder

rot-gelb-grün mit allen Feinabstufungen. Das heißt man kann beides mischen.Wenn die Teams sich

"einigermaßen" an die Ampel halten - immer mit Sachverstand - dann werden die Termine insgesamt

gehalten.

Das ist nicht Safe + Projektorganisation sondern es ein vollintegrierter Ansatz Projekt- +

Produktionsteuerung der neuesten Generation. Natürlich kombiniert mit den ganzen positiven

Aspekten der agilen Methoden.

Das wäre dann ein "fsPAFe" = "full scale Project and Agile Framework" ;-)

o ************************************************************************


Kommentar von Hans-Peter Kornam 29.07.2013, 12:18

@ Wolfram:

Deine Aussage: "auf der untersten Eben ähnlich wie bei Safe finden sich die Teams, die Teilprojekte

erzeugen." verstehe ich so, dass es keinen "Teams für Kundenprojekte mit Nutzung der

Plattformelemente" und getrennt davon "Teams zur Bereitstellung der kundenprojektneutralen

Plattformelemente" gibt sondern nur "Teams, welche kundenprojektneutralen Plattformelemente

bereitstellen und gleichzeitig auch diese Elemente für diverse Kundenprojekte anpassen".

Und die "Beauftragung" dieser Teams erfolgt durch die "Mittelschicht" (= Programm Management).

Und dort - und nicht auf der ebene der Teams - geht es auch um die einzelnen Kundenprojekte.

Das ist IMHO genau das, wie SAFe mit Kundenprojekten umgeht.

Ob das auf Programmebene mit Critical Chain Buffer Management oder sDBR-Ampel und auf

Teamebene mit Reliable/Ultimate Scrum gesteuert wird, ist in diesem Zusammenhang ein

Nebenaspekt.

Die primäre Frage ist, ob es Teams für Kundenprojekte einerseits und Teams zur Bereitstellung der

kundenprojektneutralen Plattformelemente gibt oder nur Teams, welche kundenprojektneutralen

Plattformelemente bereitstellen und gleichzeitig auch diese Elemente für diverse Kundenprojekte

anpassen.

o ************************************************************************


Kommentar von Wolfram Mülleram 29.07.2013, 21:00 - zuletzt bearbeitet am 29.07.2013, 22:11

a) das "Teilprojekte auf der unteren Ebene" war nicht eindeutig - hätte besser "Epics/Stories auf der

unteren Ebene" heißen sollen ... in der Tat sind die Teams hier frei definiert --- es können reine

Plattformteams, reine Produktteams oder (was in der Praxis doch oft vorkommt) gemsichte Teams

oder auch Querschnittteams

b) die Mittelschicht ist "nur" die Projekt oder eben auch "Produktionssteuerung" ... der Fokus liegt hier

auf der Steuerung - also Abbildung von Abhängigkeiten und Puffern - Ermittlung der Projektampel und


damit operativer Status

> Die primäre Frage ist, ob es Teams für Kundenprojekte einerseits und Teams zur Bereitstellung der

kundenprojektneutralen Plattformelemente gibt oder nur Teams, welche kundenprojektneutralen

Plattformelemente bereitstellen und gleichzeitig auch diese Elemente für diverse Kundenprojekte

anpassen.

Weder noch - es gibt alle nur erdenklich sinnvollen Kombinationen aus Produktteams (Plattform),

Projektteams und auch mixes oder Querschnittteams

Das geht weit über SAFe hinaus - denn - auch wenn wir gerne Organisationen bauen ... der

systemische Unterschied ist nicht die Aufbauorganisation sondern die Systemcharakteristiken und die

zugehörigen Steuerungen (eher Regelungen).

Aus System-Denker-Sicht sind die Systemcharakteristika das interessante und die richtige Regelung

die Hauptsache ;-) ... die Aufbauorganisation richtet sich dann im Nachgang aus.

Das was ich hier skizziert habe ist ein Regelungssystem, das mit beiden Aufgabencharakteristika

umgehen kann - zum einen Projekte und zum anderen Produkte ...

Hier auch die erste Skizze ( http://speed4projects.net/know-how/forschung/project-agile-framework/ ) -

die wird zwar auch noch nicht alles erklären - aber in den nächsten Tagen wird hier Stück für Stück

Erklärungstexte entstehen ...

o ************************************************************************


Kommentar von Hans-Peter Kornam 30.07.2013, 10:03

Ich verstehe das obige und http://speed4projects.net/know-how/forschung/project-agile-framework/ so:

Wie die Teams "geschnitten" sind hängt ab von den "Systemcharakteristika" der zu realisierenden

Aufgaben und kann eine der sehr vielen Kombinationen von Kundenprojekt- und Plattformteams

sein.

Diese werden in http://speed4projects.net/know-how/forschung/project-agile-framework/ auf der

mittleren Ebene der Multiprojekt-Steuerung mit Stories "versorgt" (dh. es werden ihnen Stories in einer

mittels Critical Chain Buffer Management oder DBR optimierten Reihenfolge zum Ziehen angeboten).

Im Unterschied zum SAFe ist dieses Vorgehen also von - per definitionem stets zeitlich begrenzten -

Projekten bestimmt und nicht von der zeitlich nicht limitierten Lieferung von Produktinkrementen.

Und es kennt auch nicht die für SAFe essentiellen "Agile Release Trains

(ART)" http://scaledagileframework.com/agile-release-train mit diesen dafür entscheidenden

Elementen: http://scaledagileframework.com/programbacklog

http://scaledagileframework.com/release-planning http://scaledagileframework.com/programpsi-objectives

http://scaledagileframework.com/rte/

Das http://speed4projects.net/know-how/forschung/project-agile-framework/ ist für mich im Gegensatz

zum SAFe ein Modell zur koordinierten Abwicklung etlicher - konkurrierender - zeitlich

begrenzter Projekte und Kundenaufträge wobei die Koordination der Teams nicht primär

selbstorganisiert innerhalb eines ART mittels synchronisierter Sprints und PSI-Plannings (= Release

Planning Event) erfolgt sondern via ein alle Projekte und Kundenaufträge umfassendes

und auf Critical Chain Buffer Management oder DBR beruhendem Regelungssystem, das jedes

einzelne Team mit Arbeit versorgt.

o ************************************************************************

Wolfram Müller findet das interessant.



Kommentar von Wolfram Mülleram 30.07.2013, 10:20

genau :-) vielleicht noch zwei Ideen ergänzend ...

... in großen Unternehmen spricht auch nichts dagen (und hab ich oft gesehen) - Teile des

Unternehmens/Bereiche/Teams komplett autark zu fahren (u.a. nach SAFe). Dann nimmt man die aus

den Kapazitäten raus. Das sind dann Inseln - kann sehr viel Sinn machen (gerade bei

Innovationsthemen)

... auch in meinem Vorschlag/Modell ist die Selbstorganisation vorhanden. Nicht ganz so stark - aber

sie ist da. Es gibt nämlich einen Seiteneffekt - wenn man kein Team überlastet sind die meisten

Teams nicht ganz ausgelastet. Diese Freiräume dürfen/sollen natürlich von den Teams genutzt

werden. Des weiteren haben die kundenprojektorientierten Teams auch immer einen prägenden

Einfluß auf den Demand - das gleiche gilt für die Plattformteams. Die Teams sind damit Teil der

Arbeitsversorgung und operativ weitgehend selbst organisiert.

... was aber zentral gemacht wird ist a) die Lastkontrolle (strategische Priorisierung) und b) das

operative Prioritätssignal über Fortschritt/Fortschritt Pufferverbrauch - denn das kein kein Team für

sich alleine tun - hier braucht man eine holistische umfassende Sicht.

ich bin mal echt gespannt wie sich unsere Themen hier weiter entwickeln. Ich denke wir werden beide

von unseren Erfahrungen berichten :-)

o ************************************************************************


Kommentar von Hans-Peter Kornam 30.07.2013, 12:30

Ich kann mir gut vorstellen, dass das "full scale Project and Agile Framework" recht gut zu - auch

grossen - grossen Technologie-Konzernen passt, die nach wie vor vom "Scientific Management"

geprägt sind.

Nämlich in diesem aktuellen Sinn:

In den 1970ern, als sich durch Automatisierung und den Folgen aus dem Wandel vom Verkäufer- zum

Käufermarkt die Anforderungen an Produktionsprozesse einerseits radikal veränderten, andererseits

aber die Möglichkeiten des Outsourcing und die Möglichkeit schlecht ausgebildete und

bezahlte Gastarbeiter einzusetzen, das Sterben der nun schon traditionellen Strukturen hinaus

zögerten, kam er, in seinen Ideen meist nur mangelhaft rezipiert, als abzulösendes Gegenmodell unter

dem wie ein Schimpfwort verwendeten Begriff Taylorismus wieder ins Gespräch.

Erreichten die Versuche, Arbeitsorganisationen neu zu denken und

durch Arbeitsstrukturierung tradierte, „tayloristische“, Formen zu beseitigen in den frühen 1990ern

einen Höhepunkt, so zeigt sich zu Beginn des 21. Jahrhunderts, dass die Prinzipien des Scientific

Management die aus Calvinistischer Tradition stammende Shareholder-Value-Ideologie zusammen

mit der Prinzipal-Agent-Theorie gut unterstützen. So kehren Taylors Ideen auf breiter Front in viele

Unternehmen – unter vielfältigen neuen Bezeichnungen – und Werkhallen zurück.

Aus Sicht des 21. Jahrhunderts können der Konzeption des Scientific Management mindestens

folgende anhaltende Impulse entnommen werden:

1. Zur Sicherung der Wettbewerbsfähigkeit ist es notwendig, kontinuierlich an der Senkung der

Stückkosten zu arbeiten.

2. Unternehmensleitung und Mitarbeiter bilden eine Interessengemeinschaft.

3. Das Verbessern von Arbeitsverfahren gehört zu den Kernaufgaben des Managements.


4. Das mittlere Management bildet das Rückgrat eines funktionierenden Unternehmens.

5. Arbeiter und Management sind auf kooperative Zusammenarbeit angewiesen.

(Zitiert aushttp://de.wikipedia.org/wiki/Scientific_Management#Neuzeitliche_Entwicklung_und_Kritik)

Demnach wäre alles rund um das stark von sich selbst organisierenden Teams geprägte "agile"

Vorgehen als "Nachbeben" der in den 1990er-Jahren heiss diskutierten

"Versuche, Arbeitsorganisationen neu zu denken und durch Arbeitsstrukturierung tradierte,

„tayloristische“, Formen zu beseitigen" zu verstehen ... und dein "full scale Project and Agile

Framework" könnte als Versuch gedeutet werden, sich wieder auf einige "Prinzipien des Scientific

Management die aus Calvinistischer Tradition stammende Shareholder-Value-Ideologie zusammen

mit der Prinzipal-Agent-Theorie gut unterstützen" zu besinnen....

Weitere Magazine dieses Users
Ähnliche Magazine