Im Rahmen der folgenden Bachelor-Thesis wird analysiert, was die Einfluss- und Erfolgsfaktoren der Team Capability beziehungsweise der Zusammenarbeit sind. Es werden hierzu existierende Methoden betrachtet, mit denen über Key Performance Indikatoren (KPI) sichtbar gemacht wird, wie schnell und gut sich ein Team entwickelt und wo sich Verbesserungspotentiale verbergen.
Gut funktionierende Teams sind in der Softwareentwicklung ein wichtiger Erfolgsfaktor. In den vergangenen 20 Jahren hat die Verbreitung von Agile dabei auch zu signifikanten Veränderungen in der Teamarbeit geführt. Die Team-Capability ist hierbei ein Aspekt, der die Schnittstelle von sozialen und technischen Faktoren darstellt – Peopleware als dritte Betrachtungsdimension für Softwareentwicklungsteams. Hierbei stellt das Agile-Team lediglich nur einen Faktor in der Betrachtung des Ziel-, Handlungs- und Verantwortungskomplexes dar. Zwar wird die Arbeitsgeschwindigkeit von vielen Faktoren innerhalb und außerhalb des Agile- Teams beeinflusst, doch muss der übergeordnete Nutzen im Hinblick auf die Qualität und das Endergebnis im Fokus der Betrachtung bleiben.
Inhaltsverzeichnis
Abbildungsverzeichnis
Abstract
1. Entwicklung der Thematik
1.1 Thematischer Rahmen
2. Agile-Teams
2.1 The Scrum-Team
2.2 Team-Ökosystem
2.2.1 Scrum Master
2.2.2 Product Owner
2.2.3 Development-Team
2.2.4 Work Iteration Flow
2.2.5 Information Flow
2.2.6 Articulation Flow
3. Einflussfaktoren
3.1 Peopleware
3.1.1 The Human Resource
3.1.2 The Office Environment
3.1.3 The Right People
3.1.4 The Productive Team
3.2 Team Interaction
3.2.1 Multitasking
3.2.2 Swarming
4. Erfolgsfaktoren
4.1 Capability
4.1.1 Capability Development
4.2 Continuous Improvement
4.2.1 Flow
4.2.1.1 Readiness
4.2.1.2 Sustainable Pace
4.2.1.3 Story-Format
4.2.2 Collaboration
4.2.3 Responsiveness
4.3 Business Value
4.4 Risk Management
4.4.1 Impediments Resolvement
5. Measures
5.1 Success & Factors
5.1.1 Team Measures
5.1.1.1 Quantität
5.1.1.2 Reife
5.1.1.3 Zufriedenheit
5.1.1.4 Abgestimmtheit
5.1.1.5 Qualität
5.2 Acceleration
Anhang
Literaturverzeichnis
Abbildungsverzeichnis: Quellen
Eidesstaatliche Erklärung
Quellenhinweis: alle aufgeführten Quellen im Haupttext dieser Ausarbeitung sind in Kurzform dargestellt. Für detaillierte Informationen wird an dieser Stelle auf das Literaturverzeichnis unter VII verwiesen.
Abbildungsverzeichnis
Abb. 1: Rugby-Analogie
Abb. 2: Team-Comparison
Abb. 3: Team-Ökosystem
Abb. 4: Die Player
Abb. 5: Customer & Product Owner
Abb. 6: Development Team & Customer
Abb. 7: Product Owner & Development-Team
Abb. 8: Work Iteration Flow
Abb. 9: Information Flow
Abb. 10: Articulation Flow
Abb. 11: Peopleware
Abb. 12: Team & Group Development Model
Abb. 13: Weinberg Table
Abb. 14: Swarming
Abb. 15: Capability & Competence
Abb. 16: Business & People
Abb. 17: Beispiel Impediment Backlog
Abb. 18: Kennzahlen-Hierarchie
Abb. 19: GQM
Abb. 20: Sample Burndown Chart
Abb. 21: Work Capacity vs. Velocity
Abb. 22: Sprint Burndown
Abb. 23: Anteil erfolgreicher Sprints
Abb. 24: Focus Factor
Abb. 25: Accuracy of estimation, Quelle: Hyperproductive Metrics
Abb. 26: Accuracy of forecast
Abb. 27: Happiness Metric
Abb. 28: Net Promoter Score
Abb. 29: Total Business Value Earned
Abb. 30: End-to-End
Abb. 31: Fehleranzahl
Abb. 32: Fehlergewichtigkeit
Abstract
Gut funktionierende Teams sind in der Softwareentwicklung ein wichtiger Erfolgsfaktor. In den vergangenen 20 Jahren hat die Verbreitung von Agile dabei auch zu signifikanten Veränderungen in der Teamarbeit geführt. Die Team-Capability ist hierbei ein Aspekt, der die Schnittstelle von sozialen und technischen Faktoren darstellt – Peopleware als dritte Betrachtungsdimension für Softwareentwicklungsteams.
Hierbei stellt das Agile-Team lediglich nur einen Faktor in der Betrachtung des Ziel-, Handlungs- und Verantwortungskomplexes dar. Zwar wird die Arbeitsgeschwindigkeit von vielen Faktoren innerhalb und außerhalb des Agile-Teams beeinflusst, doch muss der übergeordnete Nutzen im Hinblick auf die Qualität und das Endergebnis im Fokus der Betrachtung bleiben.
Im Rahmen der folgenden Bachelor-Thesis wird analysiert, was die Einfluss- und Erfolgsfaktoren der Team Capability[1] bzw. der Zusammenarbeit sind. Es werden hierzu existierende Methodiken betrachtet, mit denen über Key Performance Indikatoren (KPI) sichtbar gemacht wird, wie schnell und gut sich ein Team entwickelt und wo sich Verbesserungspotentiale verbergen.
1. Entwicklung der Thematik
1.1 Thematischer Rahmen
Die nachfolgende Ausarbeitung sieht eine pyramidale Struktur[2] vor und teilt sich in vier Hauptkapitel auf. Nachfolgend sollen diese Kapitel in einem Bottom-up-Ansatz kurz vorgestellt werden: Im einführenden Kapitel Agile-Teams (2) geht es spezifisch um das Scrum-Team[3] und ein Verständnis dafür, welche Charakteristiken, Rollen und Verbindungen dieses Team in sich birgt und zu seiner näheren Umwelt hat. Im Kapitel zu Einflussfaktoren (3) werden die grundlegenden Faktoren betrachtet, die ein Scrum-Team beeinflussen, d. h. vor allem die Einteilung in innere und äußere Faktoren.
Abbildung in dieser Leseprobe nicht enthalten
Der Abschnitt Erfolgsfaktoren (4) behandelt besondere Einflussfaktoren und das Verhältnis von Teamfähigkeit mit Blick auf die Mehrwerte, die aus einer verbesserten Team-Capability resultieren. Das Kapitel Measures (5) beschäftigt sich abschließend damit, welche Methodiken existieren, um die identifizierten Einflussfaktoren zu messen und ggf. zu steuern. Das Fazit "Acceleration" schließt den argumentativen Leitfaden dieser Bachelor-Thesis ab.
2. Agile-Teams
Das Herzstück von agilen Vorgehensmodellen bildet das Agile-Manifest; es würdigt übergeordnet das Kollektiv, bestehend aus einer Anzahl von befähigten Individuen, die gemeinsam das Agile-Team[4] bilden, es gilt: „Individuals and interactions over processes and tools“. [5] Im Folgenden soll einleitend, anhand des Rahmenwerkes Scrum, eine besondere Art von Agile-Teams betrachtet werden. Diese Auswahl begründet sich einerseits in der großen Verbreitung von Scrum als Defacto-Standard und in der besonderen Würdigung des Menschen und seiner Interaktionen innerhalb dieses Rahmenwerkes.
2.1 The Scrum-Team
In jedem guten Teamsport steht eine funktionierende Mannschaft im Fokus: „Einzeln stark, gemeinsam unschlagbar!“[6] Diese Weisheit lässt sich auch auf alle Teamdisziplinen außerhalb des Sports ausweiten, im Fall dieser Ausarbeitung auch auf die agile Softwareentwicklung. Hier steht das Ziel, gute Software zu entwickeln im Mittepunkt, und auf dem Weg dorthin[7] sollen auch ideale Bedingungen geschaffen werden, die einem Verbund begabter Individuen gemeinsam zu den angestrebten Leistungen verhelfen. Die parallele Semantik der sportlichen Disziplin und des Frameworks Scrum ist hierbei recht naheliegend, denn ursprünglich hat diese Bezeichnung ihre Wurzeln[8] im Rugby.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1 : Rugby-Analogie
Die Metapher „Scrum“ (dt.: Gedränge) entstammt der Idee von Ikujirō Nonaka und Hirotaka Takeuchi[9] und versteht sich als Analogie für erfolgreiche Produktentwicklungsteams.[10] Dabei arbeiten Scrum-Teams als in der Regel kleine, selbstorganisierte[11] Gruppen und werden lediglich richtungsweisend von außen angeführt. Die Taktik zum Erreichen des gemeinsamen Ziels wird in der Folge dann selbständig bestimmt. Das Rahmenwerk Scrum enthält zur Umsetzung effektiv fünf Aktivitäten, drei Artefakte und drei Rollen. Mit Referenz zum vorherigen Projekt[12] ging es hauptsächlich um eine äußere Betrachtung von Scrum als Defacto-Standard des übergeordneten Vorgehensmodells Agile. Im Folgenden wird nun vor dem Hintergrund der Fragestellung dem Team und den beteiligten Rollen innerhalb des Team-Ökosystems[13] besondere Beachtung geschenkt. Darum ist zunächst zu fragen, was ein Scrum-Team ausmacht. Mit Bezug zur originalen Harvard Business Review[14], die maßgeblich die Entwicklung von Scrum beeinflusst hat, haben die beteiligten Professoren Hirotaka Takeuchi und Ikujiro Nonaka gut funktionierenden Teams die Charakteristika Transzendenz, Autonomität und Cross-Funktionalität zugesprochen. Transzendenz[15] wird in diesem Zusammenhang gemeinhin als Fähigkeit bezeichnet, über die eigenen Grenzen hinauszugehen und übliche Handlungs- und Verhaltensmuster aufzubrechen. Dieses selbstgesetzte Ziel erlaubt es dem Scrum-Team aus einem gewöhnlichen Zustand der Zusammenarbeit heraus, ein außergewöhnliches Momentum[16] zu schaffen. Die Auslegung dieser Definition folgt dem Ziel größtmögliche Effektivität und Effizienz als Team zu schaffen und sie zu optimieren, getrieben durch den Teamgeist. Autonomität beweist das Team durch seine Freiheit und Fähigkeit zur Selbstorganisation. Insbesondere kann kollektiv darüber entschieden werden, was getan wird und wie die eigene Arbeit verrichtet werden soll. Wo bisher noch ein einziger Projektleiter das Team geführt hat, wird nun die Gleichstellung der Teammitglieder gefördert. Die führende Rolle kann unterstützend und richtungsweisend in Form eines sogenannten Servant Leaders besetzt[17] werden (siehe Abb. 2). Das Team verfügt durch Cross-Funktionalität über alle notwendigen Fähigkeiten, die zur erfolgreichen Entwicklung des Produkt-Inkrements[18] notwendig sind, von der Planung bis zur Auslieferung. Der Gedanke der Cross-Funktionalität zeichnet sich besonders dadurch aus, dass die entsprechenden Mitglieder sich in ihrer individuellen Expertise gegenseitig im Sinne von Synergie-Effekten bekräftigen. „When all the team members are located in one large room, someone’s information becomes yours, without even trying. You then start thinking in terms of what’s best or second best for the group at large and not only where you stand.” [19]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2 : Team-Comparison
Besonders für große Organisationen stellt die Zusammenstellung solcher Teams eine Herausforderung dar, vor allem aufgrund der regelmäßig geringen Bereitschaft zur Änderung bestehender Strukturen (Change) und dem fehlenden Bewusstsein für eine gemeinsame Zielsetzung.[20] Ohne engagierte Teammitglieder entfallen die Vorteile, die etwa durch diversifizierte Meinungen oder ein gemeinsam gesetztes, vorgegebenes Ziel entstehen. Diesen Konflikten (Change-Aspekte & Zielsetzung, Diversifizierte Meinungen) und weiteren Aspekten rund um die Prozess-Verbesserung bei der Teamarbeit widmet sich das Forschungsgebiet der Human Performance Technology (HPT)[21]. Der Fokus liegt hier auf der Lieferung eines kontinuierlichen Stroms aus Mehrwerten für den Kunden[22] bei gleichzeitiger Optimierung von Kollaboration und der Performance des Product Owners, dem Development-Team sowie dem Customer. Im folgenden Schritt sollen zunächst die Abgrenzung des Team-Ökosystems sowie die Player und deren Beziehungen untereinander als Grundlage für die Einfluss- und Erfolgsfaktoren dargestellt und erläutert werden.
2.2 Team-Ökosystem
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3 : Team-Ökosystem
Jedes Element im vergrößerten Umfeld des Ökosystems übt disruptiven Druck auf die Performance des Scrum-Teams, auf die Player[23] und in der Interaktion mit diesen aus. Das Team-Ökosystem beinhaltet neben dem Scrum-Team den Customer sowie das Management. Weitere Einflussgrößen im vergrößerten Umfeld des Ökosystems sind die zugrundliegende Strategie und der Markt. Das Scrum-Team wird zur Reduzierung von Komplexität im Entwicklungsprozess durch drei Rollen vertreten: Development-Team (drei bis neun Personen), Product Owner und Scrum Master. Den Regeln von Scrum zufolge[24] ist jedes Teammitglied eindeutig[25] einer Rolle im Scrum-Team zugeordnet.
Wie in Abb. 3 dargestellt, ist der Product Owner die Schnittstelle zwischen dem Development-Team und den Personen hinter der Strategie, also z. B. dem Produkt-Management. Zur kontinuierlichen Verfeinerung des Product Backlogs entnimmt der Product Owner die nötigen Informationen aus einer Reihe von Quellen, etwa den Strategien zu Produkt und Geschäftszielen oder zur Architektur und greift allgemein auf die Daten des Customers zu. Das Development-Team interagiert ebenfalls mit dem Management, nicht zuletzt dient dieser Austausch dem Team als wertvolle Quelle zu Standards, Best Practices und weiteren Informationsressourcen. Der Customer wiederum hat seine eigene Handlungsumgebung, da er sich ebenfalls in einem Unternehmen mit Managementstruktur, Strategie und einer Außenwelt, dem Markt, in dem sein Produkt angesiedelt ist, befindet. Wie in jedem Ökosystem ist besondere Vorsicht auch in dem Fall geboten, dass das System als geschlossen (Abb. 3) betrachtet wird.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4 : Die Player
Ein geschlossenes System steht in keinerlei Wechselwirkung mit seiner Umgebung, weshalb eine derartige Betrachtung in diesem konkreten Fall eher als idealistisch und unrealistisch angesehen werden müsste. Tatsächlich findet seitens des gesamten Teams ein Austausch mit und zu seiner weiteren Umwelt statt, noch weit über die Grenzen des Unternehmens[26] hinaus. Allen drei Playern liegen Beziehungen zu den anderen Playern nahe, die im Folgenden näher betrachtet werden sollen. Zum abschließenden Teil dieses Kapitels werden dann die Flow-Dimensionen definiert, um die Grundlagen für die Betrachtung der Einflussfaktoren auf die Team-Capability zu schaffen.
2.2.1 Scrum Master
Der Scrum Master[27] bildet das Herzstück von Scrum. In dieser Rolle übt das berufene Teammitglied nicht die Funktion eines typischen Managers aus, sondern mehr die Funktion eines Förderers[28] für das Team. Innerhalb der Darstellung des Team-Ökosystems wird der Scrum Master nicht als Player dargestellt, weil die Symbolik seiner Rolle sich konsequent auf das Team bezieht und er ebenfalls im Rahmen einer Doppelbesetzung als Teil des Teams fungieren kann. Zu den Aufgaben des Scrum Masters gehört die Koordination und Förderung zur Durchführung aller Ceremonies, darunter des Daily Scrum[29]. Während des Daily Scrums unterstützt der Scrum Master das Team, indem Impediments[30] sowie sonstige Barrieren identifiziert und beseitigt werden, um eine potentielle Verlangsamung oder Ablenkung einzustellen. Darüber hinaus nutzt der Scrum Master die Retrospektive,[31] um Continuous Improvement zu fördern, sorgt für die kontinuierliche Durchführung der Sprint Plannings und ist der Moderator bei den Sprint Reviews.[32]
Zu den zentralen Aufgaben eines Scrum Masters zählen die folgenden:[33]
- Hilfe bei der Entwicklung von Praktiken zur Unterstützung von Agilen Prinzipien.
- Tritt gegenüber dem Team als Trainer für Agile und der Nutzung von Scrum auf.
- Entfernt Impediments, die das Team und dessen Mitglieder daran hindern, effektiv Software-Inkremente zu liefern.
- Schirmt das Team weitgehend von Bürokratie ab und anderen Aktivitäten, die keinen Mehrwert bei der Softwareentwicklung darstellen.
- Beherrscht die nötige Engineering-Expertise sowie Prozesse, die das Team bei der Entwicklung auslieferbarer Software unterstützen.
- Stellt sicher, dass das Team den direkten Kontakt zum Customer erhält.
Der Scrum Master kann exklusiv oder im Rahmen einer Doppelbesetzung als Teil des Teams in die Entwicklung involviert sein. Dieser Umstand kann jedoch nicht selten zu Problemen führen, wenn sowohl Impediments als auch Tasks gleichzeitig umgesetzt werden sollen. Der Scrum Master sollte jedoch niemals parallel die Rolle des Product Owners ausfüllen.
2.2.2 Product Owner
Der Product Owner hält eine einzigartige Rolles innerhalb des Ökosystems, denn er interagiert über die Rollen des Systems hinaus auch mit den meisten Stakeholdern[34]. Dem Product Owner stellt sich die Aufgabe, das Produkt ‚ganzheitlich‘ zu betrachten, darüber hinaus spezifisch das Business-Problem des Customers zu erkennen und systematisch eine Lösung zu erarbeiten. Zur Identifikation und Realisierung eines Product Owners arbeitet der Scrum Master gemeinsam mit dem Customer und dem Management zusammen und bildet den Product Owner in Folge zu seinen Tätigkeiten und Pflichten aus. Ein Product Owner muss sich in die Lage versetzt sehen, die eigene Arbeit durch Scrum im Hinblick auf die Schaffung von Mehrwerten auszurichten. Wenn dieses Vorhaben missglückt, wird der Scrum Master zur Verantwortung gezogen.[35] Der Product Owner verantwortet das „Was” über den Aufbau eines sinnvollen Product Backlogs[36]. Das Verhältnis zum Customer ist beratender Natur und schlägt sich im Kontakt durch den Einfluss von Wünschen und Notwendigkeiten auch in den Entscheidungen nieder, wie die Ordnung innerhalb der Backlog Items ausfällt.
Die Zusammenarbeit mit dem Customer stellt sicher, dass die Anstrengungen des Scrum-Teams mit den Bedürfnissen des Customers harmonieren.[37]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 5 : Customer & Product Owner
Der Customer liefert den zugrundeliegenden Businesskontext, der Product Owner nutzt diese Information zur Entwicklung des Product Backlogs mit möglichen Product Backlog Items oder Product Features.
Das übergeordnete Ziel, das „Warum“, wird durch die Beschreibung des begehrten Ergebnisses vom Customer über den Businesskontext definiert. In der Konsequenz wird der Product Owner das „Was” durch entsprechende Beratung und Verfeinerung des Product Backlogs liefern.
Jede Rolle in Scrum hat einen Bezug zum Entwicklungsprozess der Software, jedoch verbleibt der handwerkliche Anteil einzig dem Development-Team[38]. Der Product Owner hingegen nimmt die Rolle eines Teammanagers in Anlehnung an die Sportart Rugby ein. Es obliegt der Verantwortung[39] des Product Owners, wertvolle Informationen mit allen für die Teilbereiche im Entwicklungsprozess Verantwortlichen zu teilen, unabhängig davon, ob diese Tech- Support-, Trainings-, Sales-, Deployment-, Database- oder Cloud-spezifischer Natur sind. Anschließend kann das Team darauf entsprechend reagieren, wenn beispielsweise auf Grundlage des gewonnenen Wissens bestehende Aufgaben automatisiert werden können oder durch bestehende Anwendungen Workarounds entstehen.
In der Folge wird sich auf diese Weise das grundlegende Niveau an vermitteltem Wissen bezüglich des Produktes verbessern, mit Auswirkungen zu Gunsten aller Teilnehmer.
2.2.3 Development-Team
Je nach Definition handelt es sich hierbei um diejenigen Personen, die tatsächlich an der Arbeit mit Product Backlog Items während eines Sprints involviert sind. Im Kontext der Softwareentwicklung ist diese Gruppierung als das Development-Team[40] bekannt. Das Team entspricht, verglichen mit dem Teamsport, einer Mannschaft aus Spielern, und ist verantwortlich für das „Wie“. Es steht also in der direkten Verantwortung für den Entwicklungsprozess. Zu den Aufgaben der Entwicklung zählen des Weiteren alle strukturierten Interaktionen zwischenmenschlicher Art (Ceremonies), um Product Backlog Items bestmöglich umzusetzen.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 6 : Development Team & Customer
Das Development-Team stellt dem Customer vollständige Stories[41] und das Sprint Review als Plattform zur Demonstration des erbrachten Outputs zur Verfügung. Durch das Umsetzen von Stories nimmt der Customer diese Arbeit ab und äußert sein Feedback. Die Sprint Review legt die Basis für eine weitere kollaborative Arbeitsbeziehung. Wenn der Customer an einer Sprint Review nicht teilnimmt (oder nicht eingeladen sein sollte), findet der genannte Austausch nicht statt. Dieser Aspekt stellt einen kritischen Punkt in der Beziehung zwischen Customer und Dienstleister dar, weil das Team auf diese Weise vollständige Stories abliefert, die nicht hinreichend mit dem Customer kommuniziert werden konnten. Wenn kein Feedback gegeben wird, läuft das Scrum-Team um den Dienstleister Gefahr, ein Produkt abzuliefern, das gegebenenfalls nicht den Anforderungen entspricht.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 7 : Product Owner & Development-Team
Die Collaboration[42] zwischen dem Development-Team und dem Customer schließt den Kreislauf ab, beendet das gemeinsame Geschäft und legt den Grundstein für eine mögliche zukünftige Zusammenarbeit. Die Collaboration zwischen dem Product Owner und dem Development-Team wird in Scrum durch drei spezifische Events formalisiert: Sprint Planning[43], Daily Scrum und Sprint Retrospective.[44] Durch die Art und den Umfang der Events ist Collaboration in einem großen Maße unter den teilnehmenden Rollen vorgesehen. Wenn der Product Owner und das Development-Team den Regeln von Scrum folgen, wird als Ergebnis Continuous Improvement gefördert. In der Folge kann das Team sukzessive nachvollziehen, woran es arbeitet und reflektiert periodisch die eigene Arbeit. Die am häufigsten auftretende Kluft in dieser Beziehung entsteht dann, wenn der Product Owner nicht auf täglicher Basis mit dem Team arbeitet.
Im nächsten Schritt werden die Flow-Typen im Team-Ökosystem beschrieben. Man kann diese als Perspektiven auf die Austauschmechanismen von Backlog-Items, Projektinformationen sowie den Zielen im Team- und Businesskontext definieren.
2.2.4 Work Iteration Flow
Im Work Iteration Flow wird der Fluss der Product Backlog Items[45] beschrieben. Dies ist insofern interessant, als man auf diese Weise genauer nachvollziehen kann, wie die einzelnen Rollen miteinander interagieren. Abbildung in dieser Leseprobe nicht enthalten
Abb. 8 : Work Iteration Flow
Der Flow geht vom Product Owner und der Ordnung der Product Backlog Items aus, gefolgt vom Forecast[46] des Development Teams zur Umsetzung der Product Backlog Items. Der Flow endet im wichtigsten Abschnitt, der Abnahme unter Berücksichtigung von Acceptance Kriterien[47] seitens des Customers. Der Product Owner erzeugt aus allen vorhandenen Items des Product Backlogs[48] eine priorisierte Liste mit Anforderungen, die innerhalb der kommenden Iteration umgesetzt werden muss. Das Scrum-Team zeichnet hierbei dafür verantwortlich, zunächst die Stories mit höchster Priorität top-down zu bearbeiten, bis die vollständige Kapazität, gemessen an vergangener Velocity[49], erreicht wird. Am Ende jeder Iteration begegnet der Customer dem Ergebnis mit einer potentiellen Abnahme während der Sprint Review.[50]
2.2.5 Information Flow
Der Information Flow ist neben dem Work Iteration Flow ein synchroner Strom aus Informationen, der sich den Weg durch das Ökosystem bahnt. In diesem konkreten Fall handelt es sich bei den Informationen um den Bewegungsfluss der verfügbaren Daten zur Umsetzung der Arbeit. Die Bereitstellung von Ceremonies fördert von einer Iteration zur nächsten die Initiierung von Kommunikation und Collaboration zwischen Customer, Product Owner und dem restlichen Scrum-Team. Der Scrum Master nimmt hier die Verantwortung dafür wahr, dass die Events tatsächlich stattfinden und adressiert ebenfalls Impediments sowie weitere Hindernisse, um den weiteren Ablauf zu optimieren. Die Arbeit des Scrum Masters dient zur Förderung des Continuous Improvement, also der kontinuierlichen Verbesserung des zugrundeliegenden Prozesses. Wird es möglich, einen kontinuierlichen Wertschöpfungsstrom zwischen dem Customer und dem Dienstleister aufzubauen, wird ein geschlossener Regelkreis errichtet. Die Ceremonies in Scrum lenken den Information Flow innerhalb des Ökosystems. Besonders die Sprint Review eröffnet hierbei die Möglichkeit des Customer zum Feedback gegenüber dem Scrum-Team.
Der Product Owner kann dann in der Folge das gewonnene Feedback durch das Product Backlog Refinement[51] wirksam machen.[52]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 9 : Information Flow
Wenn eine gute Qualität des Informationsflusses herrscht, wird der Product Owner zunehmend in die Lage versetzt, das Product Backlog kontinuierlich entlang des Customer-Feedbacks zu pflegen. Ein Team kann sich dazu entscheiden, in qualitativer Sicht am Product Backlog zu arbeiten, indem eine Reihe von Anpassungen durchgeführt wird, etwa die Bestimmung eines kumulativen Flusses (cumulative flow) oder die Länge von Planning Meetings.
2.2.6 Articulation Flow
Der Articulation Flow beschreibt den Bewegungsfluss von Ideen und der Expertise von einer Rolle zur anderen. Der Customer ist etwa verantwortlich für die Artikulation des gewünschten Ergebnisses (gemessen am Business Value). Der Product Owner hingegen verfasst, gemessen an den Anforderungen des Customers, die „Story“ (inklusive Lösungsparametern), die sich aus dem Business Value ableitet. Das Development Team ist zuständig für den Ausdruck des Codes (bzw. Designs), was hinsichtlich der Anforderungen der Story zu einem zufriedenstellenden Ergebnis führen soll.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 10 : Articulation Flow
Damit ein Produkt erstellt werden kann, das sich durch Wert auszeichnet, muss der Zyklus der Articulation aufrechterhalten bleiben. Stagniert der Articulation Flow, führt dies auch bei der Produktivität zu einer Stagnation.[53]
Im nächsten Abschnitt wird gesondert betrachtet, welche einzelnen Einflussfaktoren innerhalb und außerhalb des Team-Ökosystems auf das Team einwirken.
Abbildung in dieser Leseprobe nicht enthalten
3. Einflussfaktoren
Basierend auf den Erkenntnissen zur Identität und Rolle des Agile-Teams innerhalb des Team-Ökosystems, ist es von Interesse zu erfahren, welche einflussnehmenden Faktoren auf das Scrum-Team wirken. Hierzu werden nachfolgend sowohl weiche[54] als auch harte[55] Faktoren betrachtet. Ausgehend von einer Gruppe befähigter Teammitglieder stellt jede Person zunächst eine individuelle Persönlichkeit innerhalb eines Systems dar. An dieser Stelle taucht in der Theorie der Begriff „Peopleware“ auf:
3.1 Peopleware
Als „Peopleware“ wird gemeinhin die soziale Komponente bezeichnet, die neben der Hardware und der Software noch den Menschen (siehe Abb. 11) im Prozess der Softwareentwicklung berücksichtigt. Der Begriff[56] stammt aus dem im Jahr 1987 von Tom DeMarco[57] veröffentlichten Buch „Vienna waits for you!“ und umfasst folgende Bereiche[58]: der arbeitende Menschen in seinen unterschiedlichen sozialen Rollen als Individuum, Gruppenmitglied, Vorgesetzter und/oder Untergebener und des Weiteren die Arbeitsfeldbedingungen, die Unternehmenskultur und -philosophie.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 11 : Peopleware
Bei der näheren Betrachtung von Peopleware wird die Verbesserung der nachfolgenden vier soziologischen Inhalte[59] angestrebt, nämlich:
- Mitarbeiterführung im Sinne von Menschenführung
- Angemessene Gestaltung der Büroumgebung
- Auswahl geeigneter Mitarbeiter
- Förderung der Teambildung
Peopleware betrachtet den Mensch in seinen unterschiedlichen Rollen, in seinen Arbeitsfeldbedingungen und unter Berücksichtigung einer übergeordneten Unternehmenskultur. In der Gesamtheit sind alle genannten Aspekte in der Betrachtung untrennbar, da sie in gegenseitiger Wechselwirkung stehen: Mitarbeiter sind die Grundlage für eine Unternehmenskultur und bestimmen im gleichen Maße auch die Arbeitsfeldbedingungen. Arbeitsfeldbedingungen wiederum beeinflussen die Unternehmenskultur und die Mitarbeiter im Unternehmen. Jeder Mitarbeiter wird in der Konsequenz beeinflusst und übt auch Einfluss in seinem Sein und Handeln auf seine Umgebung aus.
3.1.1 The Human Resource
Der erste Aspekt bei der Betrachtung von Peopleware ist das Grundverständnis für die menschliche Ressource. Dieser wird in Agile neu definiert, weil durch den menschzentrierten Ansatz von und für den Menschen entwickelt wird. Während die erste und zweite Epoche des Computerzeitalters noch von Hardware und Software sowie der Optimierung dieser Aspekte geprägt war, wurde die dritte Epoche durch Jerry Weinbergs „The Psychology of Programming“ im Jahre 1971[60] eingeläutet. Die Anstrengung, die menschliche Komponente in einer von Ingenieuren und Computer-Spezialisten dominierten Domäne herauszustellen, war lange Zeit eine eher gewagte Angelegenheit; wer dies tat, konnte mit nur wenig Anerkennung rechnen, denn zu dieser Zeit lagen die Schwerpunkte noch weit fernab des User Interfaces.
Peopleware is really the third frontier of the computer revolution. First came the hardware crisis. At one time we thought our problems were really due to hardware. If only we had faster and more powerful computers, we thought, with more memory and better peripherals, then we could build better systems; we could solve our problems.[61]
Es verdichtete sich die Annahme, dass der wahre Grund für das Scheitern von Projekten der Mensch sei, denn neben fehlerhaften Anforderungen begründet sich das Scheitern laut der nachfolgenden Auswertung einer Studie in unterschiedlichen soziologischen Aspekten:
We observe that about 15 percent of all projects studied came to naught: They were canceled or aborted or „postponed” or they delivered products that were never used. For bigger projects, the odds are even worse. Fully 25 percent of projects that lasted 25 work-years or more failed to complete. In the early surveys, we discarded these failed data points and analyzed the others. Since 1979, though, we ’ ve been contacting whoever is left of the project staff to find out what went wrong. For the overwhelming majority of the bankrupt projects we studied, there was not a single technological issue to explain the failure. [62]
Als Gründe für das Scheitern von Projekten können hinsichtlich der menschlichen Komponente folgende Faktoren[63] genannt werden: Generelle Kommunikationsprobleme, Probleme beim Staffing, Differenzen mit dem Vorgesetzten oder Klienten, ein Mangel an Motivation, hohe Fluktuation, es gilt: „The major problems of our work are not so much technological as sociological in nature.” [64] Um der beschriebenen Problematik Ausdruck zu verleihen, soll im Folgenden der besondere Unterschied bei der Führung von Menschen im Vergleich der Areale von Entwicklung und Produktion gezogen werden. Besonders für den Wandel zu einem mehr agilen Ansatz sollen hier die Unterschiede und Vorteile deutlich werden. Entwicklung unterscheidet sich inhärent von der Produktion; es ist naheliegend, dass ein verantwortlicher Manager in der Art und dem Ursprung seines Handelns sowie in der Führung seiner Mitarbeiter zunehmend durch ein wirtschaftliches Denken gesteuert wird, welches sich näher an einer Produktionsumgebung bewegt. Im Vergleich zur Entwicklung handelt es sich bei der Produktion um einen Prozess aus sequenziell festgelegten Schritten.
Entwicklung hingegen hat zunehmend individuelle und empirische Tendenzen. „ Most of us managers are prone to one particular failing: a tendency to manage people as though they were modular components.” [65] Agile Thinking berücksichtigt im besonderen Maße die Führung der Mitarbeiter und jedes einzelnen Individuums[66], indem das Management dieser denkenden Individuen effektiv gefördert wird. Der agile Ansatz berücksichtigt im Beispiel Scrum z. B. eine etablierte Fehlerkultur[67], die sich aus der Erkenntnis ergibt, dass Projekte nicht vorab und vollständig geplant werden können bzw. sollten. Ein früher Fehler vermag entscheidende Lerneffekte zu fördern, während ein zu spät erkannter Fehler das Scheitern eines Projektes zur Folge haben kann. Die Entwicklung hin zu einer agilen Projektumgebung erfolgt weg von einem „industrial paradigm“, das sich mehr auf die Praktiken der Produktion[68] stützt, hin zu einem Ansatz, der Freiraum für Individualität und wahren Mehrwert bietet. Diese Tatsache spiegelt sich sowohl kurzfristig in der Zusammenarbeit in einem Team, als auch langfristig im Produkterfolg wider:
Yet the way we assess people´s value to a new project is often based on their steady-state characteristics: how much code they can write or how much documentation they can produce. We pay far too little attention to how well each of them fits into the effort as a whole.[69]
Dieser Umstand führt die Argumentation hin zur Frage von Produktivität im Verhältnis zur Qualität und danach, was den entscheidenden Mehrwert in Summe ausmacht. So wurde in der Vergangenheit die Meinung vertreten, dass Menschen unter Druck gesetzt werden müssten, um effektiv mehr Stunden in Arbeit zu erbringen. „ Someone who can help a project to jell is worth two people who just do work.” [70] Produktivität wird gemeinhin definiert als „benefit divided by cost. „ The benefit is observed dollar savings and revenue from the work performed, and cost is the total cost, including replacement of any workers up by the effort.” [71] Die Erkenntnisse aus einem agileren Ansatz stellen das Verhältnis von Qualität zu Quantität her, indem die Unterschiede zwischen Entwicklung und Produktion deutlich werden: „ People under time pressure don ’ t work better – they just work faster.” [72] Um tatsächlich schneller zu arbeiten, muss schließlich der Schwerpunkt in der Gewichtung verlagert werden: Bei gegebener Gewichtung der Dimensionen Zeit, Umfang, Qualität und Ressource misst Agile der Qualität mehr Bedeutung zu, wobei alle anderen Aspekte (ausgenommen Umfang) konstant verbleiben. „ Quality, far beyond that required by the end user, is a means to higher productivity.” [73] Bei der generellen Betrachtung im Hinblick auf das Agile-Projektmanagement muss besonders das veränderte Menschenbild bei Scrum berücksichtigt werden. Folgende Aspekte[74] zeichnen sich hierbei als essentiell aus:
- Eine leistungswillige, business- und sinnorientierte Sichtweise, die herausfordernde und kooperierende Individuen berücksichtigt,[75]
- eine leistungsorientierte Betrachtung, bei der Teamleistung vor Einzelleistung steht, und Talente gesucht, gefördert sowie gehalten werden müssen,[76]
- die Geschwindigkeit im Hinblick auf kürzere Entwicklungszyklen, schnelleres Feedback und den unmittelbaren Bedarf an neuen Mitarbeitern,[77]
- der veränderten Zuständigkeiten neuer Rollen, anstatt Positionen – Führungskräfte und der Scrum Master gelten als „Befähiger“ nicht als Befehlshaber unter Einbeziehung des Teams bei Entscheidungen.[78]
Es muss festgehalten werden, dass Agile den Blick auf die Ressource Mensch verändert, indem die Sicht nicht mehr objektiv auf das Individuum, sondern subjektiv vom Menschen ausgeht. Im nächsten Abschnitt soll der Einfluss der Arbeitsumgebung[79] kurz dargestellt werden, indem die angemessene Gestaltung der Arbeits- bzw. Büroumgebung als zweiter Aspekt der Peopleware betrachtet wird.
3.1.2 The Office Environment
Die Arbeitsfeldbedingungen des Teams und des einzelnen Individuums werden im besonderen Maße durch die physische Arbeitsumgebung und deren Beschaffenheit beeinflusst. „ We shape our buildings; thereafter they shape us” [80] Besonders im Kontext der Team Capability ist der Einfluss[81] der „Workplace Quality“ gegenüber der Produktqualität, wie nachfolgend gezeigt, von Interesse. Ein ideales Arbeitsumfeld kann im Folgenden z. B. charakterisiert werden durch die folgenden Fragestellungen[82]:
- Welche Art von Umgebung unterstützt den Arbeiter dahingehend, um sie möglichst glücklich und produktiv zu stimmen?
- Welche Art von Arbeit würde diesen Arbeitern ein gutes Selbstwertgefühl und auch im Hinblick auf ihre Arbeit ermöglichen?
Das intellektuelle Team-Mitglied benötigt zur Entwicklung seiner Leistungsfähigkeit eine Umgebung, die eine vollständige Konzentration sowie kreative Entfaltung ermöglicht.[83] Um dieser Anforderung gerecht zu werden, ermöglicht eine agile Arbeitsumgebung den Mitarbeitern die allgemeine Wahl darüber, wie, wo und wann sie ihre täglichen Aufgaben bewältigen. „ It provides an environment where activities can be performed to maximize efficiency.” [84] Folgende Aspekte können sich bei der Berücksichtigung der Arbeitsumgebung als nützlich erweisen[85]:
- Raum und Services für die Mitarbeiter
- Entscheidung über den Arbeitsplatz für einzelne Personen, die Menge an Raum und dem damit verbundenen Kostenaufwand
- Art der Nutzung der Räumlichkeiten
- Anzahl an Stunden/Tag, die alleine/im Team gearbeitet wird
- Einfluss von Lärm und sonstigen Einwirkungen auf die Effektivität der Mitarbeiter
3.1.3 The Right People
Die Wahl der richtigen Teammitglieder innerhalb eines produktiven Teams wird in diesem Abschnitt beschrieben. Genau wie in der traditionellen Entwicklung spielt die Kompetenz des einzelnen Individuums zwar eine wichtige Rolle für das Ganze, doch gibt es eine ganze Reihe von Faktoren, die die Produktivität des Einzelnen hierbei beeinflussen, vor allem soziale und psychologische Faktoren. Zwei besondere Aspekte sind hierbei die Motivation und die Reward Structure[86]: Eine reife und talentierte Persönlichkeit wird sich nicht im Team eines agilen Projektes integrieren, wenn ihre Anstrengungen nicht in einem gewissen Maße honoriert werden. Sie wird häufiger dazu in der Lage sein, zu wählen, wo und ggf. wie sie arbeiten möchte. Die Herausforderung liegt für das Unternehmen darin, eine Umgebung (The Office Enviroment) zu schaffen, die Talente anlockt und langfristig an sich binden kann – umgekehrt reflektiert eine ausgeprägte Struktur aus Anreizen das Verhalten der Talente nach außen. Zur Motivation und Stiftung von Anreizen talentierter Teammitglieder eignen sich die folgenden drei Überlegungen[87]:
- Ist die Unternehmens-Mission klar erkennbar? Wurde diese Vision allen Teammitgliedern ausreichend kommuniziert? Mitarbeiter wollen wissen, wohin sich das Unternehmen langfristig zu entwickeln plant und wie ihre Projekte dieser Vision folgen.
- Wie geht es dem Unternehmen, vor allem in finanzieller Hinsicht? Das Wohlergehen eines Unternehmens kann sich auf die Motivation in zweierlei Hinsicht auswirken: Wenn das Unternehmen wächst, lässt sich dieser positive Umstand den Mitarbeitern hervorragend als Argument für das eigene Unternehmen kommunizieren. Es bietet seinen Angestellten schließlich Stabilität, Wachstumspotentiale, Gehaltserhöhungen und potentielle Anteile. Neigt sich die Waage in die andere Richtung, sollte die Wichtigkeit dieses einen Projektes hervorgehoben werden, schließlich hängt unter Umständen das Schicksal des Unternehmens daran. Der Reiz besteht hier darin, dass alle unbedingt an wichtigen Themen arbeiten wollen.
- Eine Agile-Umgebung hebt den Wert eines Mitarbeiters hinter seinem Job-Titel hervor (The Human Resource). Mitarbeiter treffen Managemententscheidungen und zeichnen sich verantwortlich zur pro-aktiven Kommunikation. Talentierte Individuen heißen eine solche Umgebung willkommen.[88]
3.1.4 The Productive Team
Nach der Beschreibung der menschlichen Rolle im agilen Entwicklungsprozess und des Einflusses der Arbeitsumgebung auf die Produktivität und die Wahl von geeigneten Mitarbeitern soll dieser mit Blick auf Peopleware finale Abschnitt die Förderung der Teambildung als letzten besonderen Aspekt beschreiben, denn es gilt „ the concept of the successfully bonded team and things to do to help such teams happen”. [89]
Abbildung in dieser Leseprobe nicht enthalten
Abb. 12 : Team & Group Development Model
[...]
[1] Team Capabiltity beschreibt die generelle Teamfähigkeit bzw. Teamtauglichkeit.
[2] Vgl. Minto (2005), S.17.
[3] Zur einheitlichen Benennung von Fachbegriffen wird regelmäßig die englische Bezeichnung für den weiteren Verlauf dieser Ausarbeitung Verwendung finden, soweit der englische Begriff nicht bereits weitgehend ins Deutsche entlehnt wurde. Um den Rang des Agile-Konzepts auch im deutschsprachigen Raum zu unterstreichen, wird „Agile“ in der Regel in der substantivierten Form als Eigenname und bei Bedarf adjektivisch gebraucht.
[4] Das Agile-Team basiert auf den Grundsätzen des Vorgehensmodells Agile; zur Erläuterung wird an dieser und anderen Stellen auf die Quelle im Praxisprojekt „Accelerators für Agile Softwareentwicklung“ verwiesen.
[5] Vgl. AgileManifesto.org (2001).
[6] Vgl. Diverse (1999), S. 56.
[7] Vgl. Praxisprojekt „Accelerators für Agile Softwareentwicklung“, S. 2.
[8] Vgl. Nonaka (1986).
[9] Hirotaka Takeuchi gilt zusammen mit Ikujirō Nonaka als bedeutender Wissenschaftler des Wissensmanagements.
[10] Im Kontext wird hier stets von Produkten und nicht von Software gesprochen, vgl. Schwaber (2013), S. 7.
[11] Vgl. Verheyen (2011), S. 63 ff.
[12] Vgl. Accelerators für Agile Softwareentwicklung, Abschnitt 2.1.2 .
[13] Die Umwelt des Scrum-Teams, beispielsweise einem Unternehmen.
[14] Vgl. Nonaka (1986).
[15] In der Philosophie geht das Konzept als (theologisches) Überschreiten der Grenzen von Erfahrung und Bewusstsein weiter, vgl. Duden.de (o.J.) (Transzendenz).
[16] Vgl. Bildungssprachlich: [richtiger, geeigneter] Augenblick, Zeitpunkt, vgl. Duden.de (o.J.) (Momentum).
[17] Eine Doppelbesetzung ist situativ möglich, vgl. Abschnitt: 2.2.1.
[18] Ein Teil potentiell auslieferbarer Software, z. B. ein Teil-Release, vgl. Schwaber (2013), S. 4 f.
[19] Scruminc.com (o.J.), (Scrum-Team).
[20] VersionOne (2015), S. 10.
[21] Vgl. Winter (2015), S. 18.
[22] Kunde im Sinne von Geschäftskunde und Konsument, zur Vereinheitlichung wird hier der englische Begriff verwendet.
[23] Player sind übergeordnete Teilnehmer des Ökosystem: Customer, Product Owner, Development-Team.
[24] Vgl. Schwaber (2013), S. 25.
[25] Es kann hierbei allerdings zu Doppelbesetzungen von Person zu Rollen kommen, siehe Abschnitt 3.2.1.
[26] Vgl. Winter (2015), S. 168.
[27] Vgl. Schwaber (2013), S. 5 f.
[28] Servant-leadership, vgl. Praxisprojekt „Accelerators für Agile Softwareentwicklung“, S. 10.
[29] Kurzes, tägliches Status-Meeting des Teams, vgl. Schwaber (2013), S.15.
[30] Jegliche Form von Hindernissen, die das Team effektiv von der Arbeit abhalten oder bremsen, vgl. Abschnitt 4.4.1. „Impediments Resolvement“.
[31] Ein Teil des Feedback-Zyklus in Scrum: Hier wird im Gegensatz zur Review darüber reflektiert, wie die Zusammenarbeit ausgefallen ist, d. h. was gut oder schlecht lief. Bei der Review geht es um die Inhalte.
[32] Vgl. Cohn (2010), S. 117 ff.
[33] Vgl. Smith (2009), S. 82.
[34] Anspruchsgruppen, hier im Umfeld des Scrum-Teams.
[35] Vgl. Schwaber (2013), S. 7.
[36] Das Product Backlog umfasst die Gesamtheit aller für das Produkt definierten Anforderungen und stellt die Arbeitsgrundlage in Form von Product Backlog Items für das Development-Team dar, vgl. Schwaber (2013), S. 5.
[37] Vgl. Winter (2015), S. 104.
[38] Vgl. Schwaber (2013), S. 4 - 7.
[39] Vgl. Cohn (2006), S. 26.
[40] In anderen Kontexten ist auch die einfache Bezeichnung "Team" geläufig.
[41] Im Vergleich zu Use Cases wird bei User Stories eine Beschreibung der Funktionalität aus der Sicht des Users oder Customers eines Systems beschrieben, vgl. Cohn (2004), S. 4.
[42] Interaktion der beteiligten Player und Rollen innerhalb des Teams.
[43] Vgl. Praxisprojekt „Accelerators für Agile Softwareentwicklung“, Abschnitt 2.1.2.
[44] Vgl. ebd., Abschnitt 2.1.2.
[45] Mit Bezug zum Praxisprojekt „Accelerators für Agile Softwareentwicklung“ ist die Menge an Anforderungen im Product Backlog gemeint, die der Product Owner an das Produkt zur Umsetzung für das Development-Team definiert.
[46] Definiert hier das Engagement des Teams zur Umsetzung an ein gesetztes Ziel.
[47] Eine Menge von Anforderungen, die der Customer als Voraussetzung zur Abnahme des Produktes definiert.
[48] Vgl. Schwaber (2013), S. 12 f
[49] Eine Kennzahl über das Verhältnis von erbrachten User Stories zur Anzahl der Sprints, siehe Abschnitt 5.1.1.1.
[50] Vgl. Winter (2015), S. 154.
[51] Kontinuierliche Verbesserung des Product Backlogs, vgl. Accelerators für Agile-Softwareentwicklung, Abschnitt: 2.1.2.
[52] Vgl. Winter (2015), S. 155.
[53] Vgl. Winter (2015), S. 156.
[54] Psychologische und soziale Einflüsse.
[55] Risikomanagement und das Verhältnis von Capability zu Business Value.
[56] Erste Nennungen dieses Begriffes datieren auf das Jahr 1971.
[57] Vgl. DeMarco (2013).
[58] Wallmüller (2001), S. 188 ff.
[59] Vgl. DeMarco (2013), Part I - IV.
[60] Vgl. Weinberg (1971).
[61] Constantine (1995), S. XXI.
[62] DeMarco (2013), S. 3.
[63] Vgl. ebd., S. 4.
[64] Ebd., S. 4.
[65] Vgl. ebd., S. 1.
[66] Vgl. ebd., S. 9 f.
[67] Vgl. ebd., S. 8.
[68] Vgl. ebd., S. 8 f.
[69] Ebd., S. 10.
[70] Ebd., S. 11.
[71] Ebd., S. 17.
[72] Ebd., S. 17.
[73] Ebd., S. 21.
[74] Vgl. Scrumjobs.com (2011).
[75] Constantine (1995), S. 42–46.
[76] Ebd., S. 75–78.
[77] Vgl. Accelerators für Agile Softwareentwicklung, S. 20 ff.
[78] Vgl. ebd., Abschnitt 2.1.2.
[79] Constantine (1995), S. 23–26.
[80] Winston Churchill, http://www.goodreads.com/author/quotes/2834066.Winston_Churchill.
[81] Vgl. DeMarco (2013), S. 52 f.
[82] Ebd., S. 79.
[83] Die Arbeitsumgebung ist im besonderen Maße auch Gegenstand des Impediments Resolvement.
[84] Officeprinciples.com (o.J.); blog.bouygues-es.co.uk/ (2011).
[85] Vgl. DeMarco (2013), S. 35 f.
[86] Anreize, etwa in Form von Prämien.
[87] Vgl. Moreira (2013), S. 68 ff.
[88] Vgl. Smith (2009), S. 84 f.
[89] DeMarco (2013), S. 131.
- Quote paper
- Alex Pawlowski (Author), 2016, Einflussfaktoren für Team Capability Acceleration in Agilen Teams, Munich, GRIN Verlag, https://www.grin.com/document/370924
-
-
-
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X.