Wie kann im Scaled Agile Framework (SAFe) an Projekten ... XING-Thema.pdf · Wie kann im Scaled Agile Framework (SAFe) an Projekten gearbeitet werden? 17.07.2013, 11:27 - zuletzt

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-framework-unter-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 ************************************************************************

•


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.sigs-datacom.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.

•


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 ************************************************************************

•


@ 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 ************************************************************************

•


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/program-backlog http://scaledagileframework.com/release-planning http://scaledagileframework.com/program-psi-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 ************************************************************************

•


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....

Documents

Wie kann im Scaled Agile Framework (SAFe) an Projekten ... XING-Thema.pdf · Wie kann im Scaled Agile Framework (SAFe) an Projekten gearbeitet werden? 17.07.2013, 11:27 - zuletzt