AGILE IM MEHRSPIELERMODUS:

ERFAHRUNGSBERICHT

ZU AGILEN METHODEN IM

MEHRTEAM-MODUS

der in Scrum die Rolle des entscheidungs-befugten Produktmanagers einnimmt.

Soviel zu Scrum wie es allgemein gelehrtund in Abwandlungen auch häufig schongelebt wird. Es gibt aber kaum ein Unter -nehmen, das nur aus einem Entwick lungs -team und immer verfügbaren POs besteht.Häufig gibt es ein ganzes Produkt-Portfolio, viele Teams und eine MengeLeute, die mitreden wollen, wenn es um dasProdukt geht. Wie skaliert man agileMethoden und Frameworks wie z. B.Scrum in einem solchen Umfeld?

Mit Strukturen brechenNach Conway’s Law (vgl. ([Wik]) sindOrganisationen dazu verdammt, Produktezu entwerfen, die ihren inneren Strukturenaus Abteilungen und Teams folgen. Wenn

Sie haben Ihre Entwicklungsteams bereits auf Scrum umgestellt, die Zusammenarbeit zwi-schen den Teams läuft aber noch nicht reibungslos? Sie sehen sich gewachsenen Strukturenund Prozessen ausgesetzt? Ihr Produkt wird immer komplexer und weniger beherrschbar?Wie skaliert man Scrum und agile Methoden für viele Teams? In dem Artikel werdenStrategien gezeigt, um gemeinsam mit den Kunden nach agilen Konzepten zu entwickeln.

m e h r z u m t h e m a :http://scaledagileframework.comhttp://tfsblog.de

26 27

Um den Kunden nicht mit zu häufigenZwischenlieferungen zu überfordern, istman allerdings dazu übergegangen, lediglichalle zwei bis drei Sprints eine Version fürKundenfeedback, sprich ein Release, bereit-zustellen. Stattdessen prüfen interne Testerdie Sprint-Ergebnisse kontinuierlich bereitswährend der Sprints auf ihre funktionaleKorrektheit, um die Qualität lange vor demRelease sicherzustellen. Dabei sind sowohlEntwickler mit automatisierten Tests alsauch Tester mit manuellen oder teilautoma-tisierten Akzeptanztests in der Pflicht.

Erkenntnisse und Feedback zu den Pro -duktinkrementen – sowohl aus dem inter-nen Sprint als auch vom Kunden oder Beta-Testern – wandern zurück in das ProductBacklog (dt. Produktrückstand). Dieserwird vom Product Owner (PO) gepflegt,

Am Anfang steht der Kunde: Der hatErwartungen, Ansprüche und ständig neueIdeen um einen Bedarf zu decken. Das istder Grundstein für ein erfolgreiches Projektaber auch der Beginn eines meist langenWeges. Wo genau der Weg hinführt istmeist ungewiss und nur vage bekannt. Insolch einem Projekt lassen sich heute keineEntscheidungen treffen, deren endgültigeAuswirkungen erst in drei Jahren bekanntwerden.

Zudem treten Missverständnisse zwi-schen Kunden und dem Zulieferer auf.Wenn erst nach drei Jahren in ersten Testsmit dem Kunden auffällt, dass eineAnforderung falsch interpretiert und dannumgesetzt wurde, kann das teuer werden.Um dem Risiko einer Fehlentscheidung undverpassten Erwartungshaltung zu begeg-nen, setzen viele Unternehmen gerade inneuen Projekten auf kürzere Zeitscheiben,in denen eine vorzeigbare Teillösung derSoftware entsteht und dem Kunden gezeigtwird. Idealerweise ist diese Teillösung einauslieferbares Produktinkrement, alsobereits produktiv einsetzbar – das mussaber nicht sein. Schließlich kommt es dar-auf an, das Feedback des Kunden zum der-zeitigen Stand und zur Richtung derUmsetzung zu bekommen. Nur dadurchwird erkennbar, ob weitere Ideen umzuset-zen oder scheinbar bekannte Anfor -derungen umzudefinieren sind. Zudemkönnen eigene Designentscheidungen veri-fiziert und überdacht werden. DieseZeitscheiben werden bei Scrum als Sprintbezeichnet und greifen die Prinzipien deskontinuierlichen Lieferns und Reviews auf.So verwenden Kunden in Projekten bei-spielsweise Sprints von drei Wochen Länge.Abbildung 1 zeigt dieses Vorgehen imModell.

schwerpunk t

Sven Hubert

(sven.hubert@aitgmbh.de)

ist Bereichsleiter und Software Process Consultant

im AIT TeamSystemPro Team und MVP für VS

ALM. Er hilft Teams bei der Verbesserung der

Softwareentwicklung und berät bei der Einführung

und Anpassung des VS Team Foundation Server.

der au tor

Abb. 1: Agiler Produktzyklus.

2/2013

das Produkt schon vorhanden ist und eineneue Struktur aufgebaut wird – dieOrganisation beispielsweise wächst –, istdies ebenfalls ein Thema.

Abbildung 2 zeigt exemplarisch dieOrga nisationsstruktur eines modernenUnternehmens, wobei das Beispiel auf dieSoftwareentwicklung reduziert wurde. Hierwurde zwar auf oberer Ebene nicht einfachin Linien wie Entwicklung und Testgedacht, sondern zunächst in die grobeProduktstruktur unterteilt, doch manifes -tiert der Aufbau das Silo-Denken derBereiche für Applikationen, Plattform undKundenlösungen. Die Kultur denkt hierar-chisch: Mitarbeiter sind Ressourcen undwerden als solche minutiös in Projekt -plänen getaktet. Ein Mitarbeiter ist heutein diesem und morgen in einem anderenTeam eingebunden – meist reagiert er aufaufgetretene Probleme und Engpässe, stattvorausschauend und geplant zu agieren.Eigentlich rein technische Entscheidungenwerden in den oberen Hierarchieebenengetroffen und nach „unten“ kommuniziert.Die Teams fühlen sich nicht wirklich ver-antwortlich, halten Informationen zurückund reagieren häufig mit Schuld zu -weisungen auf Probleme, die Termin -verschiebungen verursachen. Und obwohleinige Teams bereits Scrum praktizieren,mag das Ganze nicht so recht in Fahrt kom-men. Neben den genannten kulturellenGründen liegt das aber auch an den verwo-benen Strukturen des Produkts. Teamshaben untereinander viele Abhängigkeitenund der Koordinationsaufwand, um einpaar Dutzend Teams zu verwalten, istimmens. Es entsteht eine Projektleitungs -abteilung, die nur noch mit dieserKoordination beschäftig ist, technisch abernicht mithalten kann.

Zugegeben, das obige Szenario fasst vie-le schlechte Erfahrungen verschiedenster

Kunden zusammen, ist aber dennoch nach-vollziehbar und leider realistisch. ImFolgenden sollen Wege zur Verbesserungaufgezeigt werden.

Portfolio nach ZwiebelprinzipEine wesentliche Verbesserung lässt sicherreichen, indem unausgesprochene Ver -ant wortlichkeiten und Entscheidungs -kompe tenz klar definiert und kommuni-ziert werden. Unser Ansatz folgt demModell einer Zwiebel, wie in Abbildung 3dargestellt, wobei jede Schicht eine andereVerantwortungs-, Zeit- und Inhaltsebenedarstellt.

Die Strategie wird von der Unterneh -mensführung festgelegt. Hierbei entstehenIdeen und Visionen zu Produkten, in dieinvestiert wird. Die Strategie ist über einenlängeren Zeitraum – in der Software häufigüber zehn Jahre – ausgelegt.

Das Portfolio ist die Konkretisierung derStrategie in „Überschriften“ auf dergedachten Produktpackung. Hierbei gilt eszu definieren, welche zugesicherten, ver-kaufsfähigen Eigenschaften ein bestimmtesProdukt haben soll. Häufig wird auf dieserEbene bereits in Produktgenerationen oderauch Haupt-Releases gedacht, die übereinen Zeitraum von zwei bis drei Jahrenentwickelt werden. Das Portfolio wirdmeist von einem Produktmanagement-Team (auch PO-Team) verwaltet.

Das Produkt wird in auslieferbarenTeilen geplant, die zeitlich den Release-Candidates (RC) zugeordnet werden. EinRC ist eine potenziell auslieferbare Versiondes Produkts und nicht als Testversion auf-zufassen. Die Verantwortung für dasProdukt liegt beim PO, der aber immernoch vom PO-Team unterstützt wird.

Auf Ebene des Release werden die auslie-ferbaren Produktteile weiter heruntergebrochen. Hierfür können beispielsweisedie in der agilen Welt beliebten User-Storyszum Einsatz kommen, wie dies auch inunserem Beispiel der Fall ist. Hier ist end-gültig der PO in der Verantwortung, Prio ri -täten und Inhalte festzulegen und ersterAnsprechpartner des Teams zu sein.

Bis jetzt liegt also die Verantwortung, dieStrategie des Managements mit den richti-gen Produkten und treffenden Produkt -eigenschaften umzusetzen, komplett beimProduktmanagement.

Auf der technischen Seite gibt es abernoch eine Entwicklungsleitung oder ein

schwerpunk t

Abb. 2: Beispielorganisationsstruktur.

Abb. 3: Hierarchie des Product Backlogs von der Strategie zur täglichen Arbeit.

Änderungen beschließen kann und wie die-se anderen Konsumenten mitgeteilt wer-den. Microsoft arbeitet hier beispielsweisenach dem Tell&Ask-Mode. In einem Re -lease-Team aus Architekten unterschied-licher Teams werden vor einem bestimmtenMeilenstein Änderungen an Schnittstellenlediglich angekündigt – der Tell-Mode. DieKonsumenten müssen darauf reagieren.Nach dem Meilenstein wird in den Ask-Mode gewechselt, wonach der Lieferantgeplante Änderungen im Release-Teamvorstellen muss. Nur wenn alle Kons u -menten einverstanden sind – also noch rea-gieren können –, kann die Änderung nocheingebaut werden. In anderen Fällen mussnach einem Kompromiss gesucht werden.

Zudem ist im SLA geklärt, wie Lie -ferungen aussehen müssen: Lieferungenenthalten Quellcode und Binärdateien, eineDokumentation der statischen und dyna-mischen Schnittstelle, Code-Beispiele fürdie Anwendung, ein Testprotokoll, Unit-Tests für den Konsumenten, mit denenpotenzielle Fehler vor der Meldung repro-duziert werden müssen usw.

Neben den modulorientierten Entwick -lungsteams gibt es (siehe oben) weitereTeams, die zum einen top-down die defi-nierte Produktstrategie auf die Straße brin-gen und die zum anderen bottom-up die

28 29

den Teams müssen aber minimiert werden,damit die Rechnung aufgeht. Ein Team istentweder von einem Modul eines anderenTeams abhängig oder das andere Teamkonsumiert ein Modul des eigenen Teams.Es besteht nie eine zirkuläre Abhängigkeitim Sinne der Modulabhängigkeiten zwi-schen zwei Teams. Das kann man in Abbil -dung 4 an den beiden Plattform-Teamserkennen. Das Team „Platform Cluster 1“ist Lieferant für „Plattform Cluster 2“.

Diese Entwicklungsteams sind multi-funktional aufgebaut. Neben Entwicklernund Testern gibt es – je nach Modul -verantwortung – spezifische Experten.Wird ein Oberflächenmodul gepflegt, gibtes einen Usability-Experten. Ist einTreibermodul in der Verantwortung desTeams, hat es einen Kernel-Experten. DieTeams sind dabei durchaus unterschiedlichgroß – von zwei bis zwölf Mitarbeitern.

Besonders wenn ein Team viele konsu-mierende Teams beliefert, ist es sinnvoll,Regeln für die Zusammenarbeit zu formu-lieren und schriftlich festzuhalten. EinigeUnternehmen haben intern eine ArtService-Level-Agreement (SLA) abge-schlossen. In diesem, vielleicht vier bissechs Seiten starken Dokument ist festge-halten, was eine Anfrage für eine Änderungan einem Modul enthalten muss, wer

Team von Architekten, die die Verant -wortung haben, die Software langfristigadaptierbar zu halten, damit die Produkt -eigenschaften auch in vertretbarem Auf -wand implementiert werden können.

Zudem müssen – je nach Produktgröße –Integrationsteams gebildet werden, die dieAbhängigkeiten und kritischen Pfade zwi-schen verschiedenen Teams im Auge behal-ten und übergreifende Prüfungen und Testsdurchführen können.

In den Sprints und damit der täglichenArbeit geht die Verantwortung zum Teamüber, das sich aus Entwicklern, Testern,Usability-Experten und Designern zusam -mensetzen kann. Das Team ist für diepünktliche und vollständige Lieferung dervon ihm zu Beginn eines Sprints zugesi-cherten User-Storys verantwortlich. DieVorgaben vom Produktmanagement kön-nen während der Sprint-Planung als „zugroß“ klassifiziert und geändert werden.Damit ist das Team in der Pflicht, nicht zubewältigende Aufgaben vorab zu meldenund nicht kurz vor Abgabe eine Termin -verschiebung einzugestehen. Doch wiestrukturiert man die Teams?

Structure follows FunctionUnter Berücksichtigung von Conway’s Lawmüssen Organisationsstrukturen den funk-tionalen Produktstrukturen folgen. DieProduktstrukturen müssen dazu bewusstdefiniert werden, um die Ziele derOrganisation – wie Wachstum, Flexibilitätund Langlebigkeit – zu erfüllen.

Ein großes Problem dabei sind Abhän -gig keiten der einzelnen Produktmodule.Abbildung 4 zeigt eine beispielhafte Ab -hängig keitsstruktur der Module von dreiApplikationen und einer gemeinsamenPlattform. Eine Auswahl von zwei Appli -kationen bildet das Produkt „Basic Suite“;das Produkt „Premium Suite“ ergänzt die-se mit der dritten Applikation.

Im vorliegenden Fall wurden fünf Teamsdefiniert: je ein Team für eine Applikationund zwei Plattform-Teams. Die Teamshaben die Verantwortung über bestimmteModule der Software. Das widerspricht aufden ersten Blick dem Feature-Driven-Development, hat aber den Vorteil, dassModule sauber gehalten werden. Gibt eskeinen dedizierten Verantwortlichen für einSoftwaremodul, wird es schnell verfallen,d. h. gegen Codekonventionen und Quali -tätsvorgaben verstoßen und nicht mehrwartbar sein. Die Abhängigkeiten zwischen

schwerpunk t

Abb. 4: Produkt- und Teamstruktur.

2/2013

Einhaltung von gemeinsamen Konven -tionen sicherstellen sowie teamübergreifen-de Prüfungen durchführen.

Top-down ist das Suite-Product-Management Team (PM) in der Pflicht, dieStrategie in Produktfunktionen und auslie-ferbare Teile zu übersetzen. Es besteht auseinem Director PM und den Produkt -managern. Wichtig ist nicht unbedingt dertechnische Einblick – der kann von Ex -perten erbracht werden, die in der Planungselektiv hinzugezogen werden –, sonderndie gemeinsame Priorisierung und Beant -wortung wichtiger Fragen wie z. B:

■ Welche Kundenwünsche werden be -rück sichtigt, welche Funktionen wer-den bewusst weggelassen?

■ Wohin entwickeln sich die Kunden unddamit der Markt?

■ Welche Funktionen müssen heuteberücksichtigt werden, die der Benutzermorgen benötigt und von denen er heu-te eventuell noch nichts weiß?

Das Suite-Integration-Team (Int) nimmteine technische und prüfende Rolle ein. Esinstalliert die Produkte regelmäßig in pro-duktionsähnlichen Umgebungen und führtproduktweite Tests durch. Das IntegrationTeam automatisiert zudem die auszufüh-renden Integrationstests und arbeitet anQuerschnittsthemen wie Build-Automa ti -sierung, Codeanalyse und den Entwick -lungs werkzeugen. Eine sinnvolle Ergän -zung der Verantwortlichkeit des Teams istdie Prüfung von Codekonventionen undArchitekturvorgaben, die von den Archi -tekten kommen.

Bei einem unserer Kunden wurde ein„Architecture Office“ innerhalb des Inte -

gration Teams etabliert, das nach einemfestgelegten Zeitplan Module auf Einhal -tung der Regeln und Konventionen testet.Werden Verstöße entdeckt, werden diebetreffenden Entwickler oder Teams einge-laden, um die Regel zu erklären bzw. überGründe für den Verstoß zu diskutieren. Dashilft langfristig dabei, das Qualitäts -verständnis der Entwicklungsteams auf dasgleiche Niveau zu bringen.

Im Suite-Release-Team (Rel) kommenausgewählte Vertreter sowie der jeweiligePO eines jeden Entwicklungsteams zusam-men. Diese sind verantwortlich dafür, dieunvermeidbaren Abhängigkeiten zwischenden Teams zu koordinieren und in einemüberschaubaren Rahmen zu halten. Zudemwerden technische Änderungen und Prob -leme besprochen (siehe Ask&Tell-Mode).

Die Vielzahl der Teams kann zu einergroßen Zahl an notwendigen Meetings füh-ren. Dem muss mit einer effizientenMeeting-Kultur und einem wohldurch-dachten Zeitplan begegnet werden. Das istjedoch nicht Gegenstand dieses Artikels

(mehr dazu finden Sie beispielsweise in„Effective Daily Meetings“ (vgl. [Dai]).

Der Puls der OrganisationSo viel zur Struktur. Lassen Sie uns einenBlick auf die Zeitdimension werfen. Nichtnur durch statische Abhängigkeiten zwi-schen Teams entstehen Koordinierungs -aufwände, zeitliche Abhängigkeiten müs-sen ebenfalls verwaltet werden. Auch hiergilt der Ansatz der Vermeidung.

Aufwände entstehen durch häufige undunregelmäßige Übergaben zwischen Teamssowie durch den Wechsel von Mitarbeiternzwischen Teams und die dadurch aufwän-digere Kapazitätsplanung. Beides sind kei-ne unmittelbar wertschöpfenden Aktivitä -ten. Es hat sich herauskristallisiert, dass dasZusammenspiel deutlich einfacher wird,wenn alle im gleichen Takt denken undhandeln – sozusagen im Puls derOrganisation. Auch diese „Herzschläge“lassen sich wieder auf die verschiedenenstrukturellen Ebenen beziehen.

Abbildung 5 zeigt den Produkt-Suite-Puls, der über mehrere Release-Kandidatenbis hin zum Release schlägt. Das Produktwird sukzessive um auslieferbare Teileerweitert, bis eine marktreife Version – dasRelease – entsteht. Die auslieferbaren Teilewerden von den Entwicklungsteams imTeam-Puls den Sprints geliefert. Wichtig ist,dass alle Teams ungeachtet vom Produkt indiesem Rhythmus arbeiten, um denAustausch von Mitarbeitern sowie Lie -ferun gen zwischen den Teams zu vereinfa-chen. Ansonsten würde ein Mitarbeiterunter Umständen mitten in einem Sprintdas Team wechseln müssen.

Das Modell ist aber flexibel genug, umden Teams einen gewissen Freiheitsgrad zulassen. So kann es je nach Kontext desTeams sinnvoll sein, den Sprint auf die

schwerpunk t

Abb. 5: Der Produktpuls.

Abb. 6: Der Teampuls.

30 31

Hälfte des regulären Sprint-Zeitraumes zuverkürzen. So können gerade bei neu be -gonnen oder unklaren Projekten schnellerErgebnisse betrachtet und adaptiert wer-den. Abbildung 6 zeigt den gleich getakte-ten Team-Puls und wie Team „App 2“ inSprint 1.1 und Sprint 1.2 arbeitet. Zugleichbringen die Release-Kandidaten die Er -gebnisse der Teams über das Integration-Team wieder zu einem kompletten Produkt

zusammen. So kann sich eine Routine her-ausbilden und damit eine kontinuierlicheEffizienzverbesserung erreicht werden.

Das soll aber nicht bedeuten, dass dieInte gration der gesamten Produkt-Suite nurzum Zeitpunkt der Erstellung des Release-Kandidaten erfolgt. Die Entwicklungs -teams integrieren regelmäßig – mindestenswöchentlich – ihre Teilergebnisse in dieIntegrationsumgebung des Gesamt pro -

dukts. Dort prüft und testet das Inte -gration-Team, um frühzeitig Feedback andie Teams geben und Probleme identifizie-ren und beheben zu können.

Wenn man noch weiter in den Sprintabtaucht, wird die Gleichtaktung etwas auf-geweicht. Abbildung 7 zeigt schematisch dieZusammenarbeit eines Applika tionsteams„App 1“ und zuliefernden Plattformteams„Platform 1“. Nehmen wir einmal an, dassdie Applikation eine Anforderung an diePlattform stellt und bereits im Release-Teamabgesegnet wurde. In der Sprint-Planungvon „Platform 1“ muss diese Anfrage be -rück sichtigt und eingeplant werden. Dazu istein Vertreter von „App 1“ abgestellt, der derSprint-Planung beiwohnt. Daher finden diePlanungs-Meetings der Plattform auch einbis drei Tage vor den Applikationen statt.Somit startet der Sprint für die Platt -formteams auch wenige Tage vor derApplikation. Entsprechend verschieben sichauch das Sprint-Ende und damit die Abgabenach vorn.

schwerpunk t

Abb. 7: Der Übergaberhythmus.

Abb. 8: Das Scaled Agile Framework (©2012 Leffingwell, LLC).

2/2013

Da eine Interface-Änderung notwendigwird, bleibt dem Applikationsteam amEnde des eigenen Sprints damit noch genü-gend Zeit für die finale Integration derPlattformänderung (Final Handover).Damit das reibungslos von statten geht,werden vorher individuelle Zwischen -übergaben (Intermediate Handover) ver-einbart. Die Planung der Lieferungen bleibtaber den Teams überlassen. Auf einer höhe-ren Ebene wird wieder in auslieferbarenTeilen und idealen Sprints gedacht. Dasreduziert den Planungsaufwand in komple-xen Systemen aus verschiedenen Teams undProduktteilen deutlich.

Im Takt der Sprints finden entsprechendBacklog-, Grooming- und Retrospektiven-Meetings der Teams statt. Häufig sind auchdiese zeitlich so eingeplant, dass Vertreteraus konsumierenden Teams in die Meetingsder Zulieferer eingeladen werden können,ohne dass diese das eigene Meeting verpas-sen. Auf Ebene der Release-Kandidatenerfolgen diese Meetings im Release-Team.

Die formelle BasisBei unserer Unterstützung von Kunden,derartige Strukturen und Prozesse zu eta-blieren, lehnen wir uns an das Scaled AgileFramework an, das Teile der oben gezeig-ten Konzepte abstrahiert und so eine for-male Basis bietet. Es muss jedoch in derPraxis an die Bedingungen und vor alleman die etablierte Begriffswelt eines Unter -

nehmens angepasst werden, um zum Erfolgzu führen.

Das Framework in Abbildung 8 beziehtsich dabei rein auf Softwareentwicklungen.Eine zusätzliche Herausforderung in unse-ren Projekten bilden häufig Unternehmen,in denen die Software nur eine untergeord-nete Rolle spielt und in denen auchHardwareentwicklungen zum Produkt bei-tragen. Hier wird oft argumentiert, dass dieHardwareentwicklung nicht nach Scrumläuft. Ungeachtet dessen, dass Scrumdurchaus auch für die Hardwareent -wicklung sinnvoll eingesetzt werden kann,ist das auch nicht wichtig. Im vorgestelltenModell ist es unwesentlich, nach welchemVorgehen die Teams innerhalb der Taktearbeiten. Es ist sogar denkbar, dass fürbestimmte Teams der Release-Kandidat dieZeitscheibe für Lieferungen darstellt, anderen Ende integriert werden muss. Jedochbirgt das die Gefahr, dass nicht passende

Lieferungen und unbedachte Probleme zuspät entdeckt werden. Das ist natürlichnicht im Sinne des Erfinders.

FazitDas vorgestellte Modell zur Skalierungeiner agilen Vorgehensweise in großenOrga nisationen konzentriert sich imWesentlichen darauf, den gestiegenenKoordinationsaufwand zu verringern. Daswird zum einen über eine der Funktion fol-genden Organisationsstruktur erreicht.Zum anderen liegt der Schwerpunkt aufdem gemeinsamen Rhythmus der Teamsund deren Lieferungen. Die Gleichtaktungverlangt aber auch ausreichende Freiheits -grade, um Lieferungen zwischen Teamseffizient zu gestalten. Als Basis dient dasScaled Agile Framework. Die Einführungeines solchen Vorgehens verlangt derOrganisation allerdings einiges ab undstellt den schwierigeren Teil dar. ■

schwerpunk t

Literatur & Links

[Dai] Daily Coaching Blog, Skip Angel, Effective Daily Meetings, siehe:

igvisible.com/2011/07/effective-daily-meetings/

[Guc12] S. Guckenheimer, N. Loje, Visual Studio Team Foundation Server 2012: Adopting Agile

Software Practices, From Backlog to Continuous Feedback, Microsoft Windows Development

2012

[Sca] Scaled Agile Framework, Leffingwell, LLC, siehe: scaledagileframework.com

[Wik] Wikipedia, Convey’s Law, siehe: en.wikipedia.org/wiki/Conway's_law