Best of agile# - Sybit GmbH · 2018-01-17 · Das Geheimnis passionierter Teams Marc Löffler Das...

Agile Softwareentwicklung im Fokussybit-agile.de

Ausgabe 1609/2016

Best ofagile#

Foto

: Sop

hia

Laui

nger

, Syb

it G

mbH

Inhalt

Vorwort: Das Agile in Zeiten des UmbruchsJohannes Hartmannsgruber

„Ich weiß genau, was Du nicht meinst…”Gabriele Kottlorz

Agilität für Gesellschafter: 7 Schritte, um den Unternehmenswert nachhaltig zu steigernKarl Bredemeyer und Stefan Willuda

Das Geheimnis passionierter TeamsMarc Löffler

Das geht morgen auch noch!Architekturentscheide sinnvoll vertagen für mehr AgilitätUrs Enzler

Phase 0 – das Schmiermittelfür den Start komplexer IT-ProjekteGerd Bart

The very best of ScrumThomas van Aken

Seite 3

Seite 4

Seite 8

Seite 12

Seite 16

Seite 20

Seite 26

2 sybit agile Ausgabe 16

Das Agile in den Zeiten des UmbruchsWer die Entwicklungen auf dem Innovationsmarkt auch nur mit einem Auge beobachtet, hört immer öfter von Game Changern, disruptiven Technologien und revolu-tionären Umbrüchen. Ob nun die Automobilindustrie mit dem Elektroauto hadert, ob die Taxibranche Uber oder Lyft bekämpft oder ob ganze Berufszweige wie LKW-Fahrer durch selbststeuernde Fahrzeuge in Frage gestellt werden – die Änderungen sind grundlegend und es gibt nicht nur Gewinner. Außerdem dauert es nicht mehr Jahrzehnte, wie das bei der zurückliegen-den industriellen Revolution der Fall war, es sind nur wenige Jahre, die den Umbruch bringen.Und wir? Wir stellen die Agile Bodensee 2016 unter das Motto „best of #agile“. Natürlich haben wir nicht DIE Silver Bullet für die oben angesprochenen Situa-tionen (das wär was!). Aber ein paar kleine Bausteine, Beispiele und Good Practices können wir vielleicht durch die Artikel in diesem Heft beisteuern.

In jedem Projekt ist eine gute Kommunikation der wich-tigste Schlüssel zum Erfolg. Gabriele Kottlorz, die uns letztes Jahr mit ihrem Huhn Helga begeisterte, zeigt in ihrem Artikel „Ich weiß genau, was Du nicht meinst…” welche Aspekte hier wichtig sind und dass auch eine Kleiner-100%-Lösung eine gute Lösung sein kann.

Karl Bredemeyer und Stefan Willuda von borisglo-ger consulting stellen in Ihrem Artikel „Agilität für Gesellschafter: 7 Schritte, um den Unternehmenswert nachhaltig zu steigern.“ einen im agilen Kontext eher vernachlässigten Personenkreis in den Mittelpunkt. Der „Shareholder-Value“ ist in den letzten Jahren – zu Recht! - etwas in die Kritik geraten und die ausschließ-liche Konzentration auf diesen Wert ist langfristig sicher nicht gut für ein Unternehmen. Bredemeyer und Willuda zeigen in sieben Punkten den Zusammenhang zwischen Agilität und der nachhaltigen Steigerung des Unternehmenswerts.

Das Sybit Agile Magazin Urgestein Marc Löffler (schauen Sie sich ruhig mal unter sybit-agile.de die erste Aus-gabe an) widmet sich in seinem Artikel „Das Geheimnis passionierter Teams“ der Kernzelle agilen Geschehens, dem Team. Er erläutert uns sein PASSION Modell und erklärt, wie Leidenschaft entsteht. Spannend!

„Morgen, morgen, nur nicht heute, sagen alle faulen Leute“. Urs Enzler von bbv Software Services AG gehört anscheinend auch zu der im Sprichwort bezeichneten Personengruppe – und das mit gutem Grund. Sein Arti-kel „Das geht morgen auch noch!“ zeigt uns, dass Archi-tektur in agilen Projekten keine Big-Upfront-Aufgabe ist, sondern gerne auch mal hinausgeschoben werden kann. Die Architektur eines Systems muss sich an dem zu lösenden Problem orientieren und dieses Problem konkretisiert sich sehr oft eben erst im Laufe der Zeit. Enzler zeigt uns Muster, mit denen wir mit dieser Unsi-cherheit leben können.

Mein Kollege Gerd Bart greift schließlich zum Ölkänn-chen – und das schon ganz zu Anfang eines Projekts. In seinem Artikel „Phase 0 – das Schmiermittel für den Start komplexer IT-Projekte“ erläutert die einzelnen Phasen bei der Annäherung an ein neues Projekt. Und vor allem, an welchen Stellen das Ölkännchen ange-setzt werden kann, damit das Vorhaben geschmeidig an den Start geht.

Thomas van Aken ist mittlerweile ein alter Bekannter des Sybit Agile Magazin, der es aber immer schafft, neue Aspekte aufzuzeigen und deutlich zu machen. So auch in seinem neuesten Werk „The very best of Scrum“. Es tut manchmal Not, auf die Basics zurück- zugehen und zu hinterfragen, was man macht und wie man es macht. Sei es die gute alte Frage „Einfach, kom-pliziert, komplex oder chaotisch“, sei es der Weg vom „Wünsch-dir-was“ hin zum Value-Driven Scope und, und, und. Alles Dinge, die den Unterschied der agilen Vorgehensweise ausmachen.

Ich wünsche Ihnen eine unterhaltsame und auch auf-schlussreiche Zeit beim Lesen der Sybit Agile!

Johannes Hartmannsgruber

3sybit agile Ausgabe 16

„Ich weiß genau, was Du nicht meinst…”

Gabriele Kottlorz


„Ich weiß genau, was Du nicht meinst…”Schwierige Gespräche leicht(er) gemacht mit den Grundlagen

der gewaltfreien Kommunikation nach Marshall Rosenberg

Die Arbeitswelt verändert sich. Das Tempo erhöht sich,

genauso wie die Anforderungen an jeden Einzelnen. Füh-

rungsstrukturen werden aufgebrochen und öffnen Freiräume

für mehr Selbstverantwortung und individuelle Gestaltungs-

möglichkeiten. Hurra! Ein Segen für diejenigen, die sich mehr

entfalten und in Entscheidungen und Prozesse einbringen

wollen. Das einzige, was den Enthusiasmus stört, ist der

Vollpfosten, der im Team einfach immer anderer Meinung

ist! Dessen Argumente sind – natürlich – sachlich brüchig und

überhaupt will der ja nur einen auf dicke Hose machen, weil

er zu Hause nix zu melden hat …

Aber halt, wir sind doch gebildet, aufgeschlossen und gut

sozialisiert. Wir reden miteinander und räumen die Störun-

gen konstruktiv aus dem Weg, Reibung erzeugt ja nicht nur

Wärme, sondern auch fruchtbare Anregungen und erfri-

schende Perspektivwechsel. Klingt einfach, ist es aber nicht.

Schließlich spielen gerade in „schwierigen“ Situationen sehr

persönliche Befindlichkeiten eine Rolle - sonst wäre es ja

nicht schwierig.

Nicht nur im beruflichen Kontext sind wir sehr stark dar-

auf geprägt in allen Lebenslagen sachlich zu bleiben und

Gefühle aus dem Spiel zu lassen. Ich glaube, dass das schlicht

unmöglich ist und ermutige ganz bewusst zur „Unsachlich-

keit“, wenn es zwischen Menschen knirscht! Um dieser Art

der Auseinandersetzung einen sicheren Rahmen zu geben,

greife ich auf die vier Schritte der gewaltfreien Kommunika-

tion zurück, wie sie der amerikanische Psychologe Marshall

B. Rosenberg (1934 – 2015) in die Welt gebracht hat. Um die

Motivation eines Menschen zu verstehen und eine Verbin-

dung schaffen zu können hat er vier Schritte definiert, an

denen wir uns gut orientieren können:

Wertfreie Beobachtung (Was ist geschehen, was wurde

gesagt oder getan?)

Leichter gesagt als getan! Oft beginnt ein Gespräch mit

einem Vorwurf, einer Interpretation oder einer Diagnose.

Eine möglichst sachliche Beschreibung verhindert Abwehr-

reaktionen und ist eine gute Basis für weitere Annäherung.

Gefühle erkennen (wie fühle ich mich, was löst die

Situation aus?)

Je genauer wir uns in unserer eigenen Gefühlswelt ausken-

nen, desto klarer können wir mitteilen, was uns wirklich

wichtig ist. Über Gefühle sind Menschen verbunden – sofern

wir sie von Schuldzuweisungen trennen und eigenverant-

wortlich annehmen können.

Bedürfnisse benennen (Was ist mir wichtig? Was soll

sich erfüllen?)

Gefühle sind unser Kompass zu Bedürfnissen. Alles, was wir

tun, tun wir aufgrund von Bedürfnissen, die wir uns erfüllen

wollen. Konflikte entstehen dort, wo Bedürfnisse auf Kosten

anderer befriedigt werden. Ein Gespräch über Motivation und

Bedürfnis erzeugt oft gegenseitiges Verständnis. Über die

„richtige“ Strategie zur Erfüllung kann man hingegen stun-

denlang streiten.

Eine Bitte formulieren (Was wünsche ich mir? Wie soll

der nächste Schritt aussehen?)

Eine echte Bitte beinhaltet die Bereitschaft, auch ein „Nein“

zu akzeptieren! Im Gegensatz zu einer Forderung erhöht sie

aber die Bereitschaft zur Kooperation und Lösungsfindung.

Eine Bitte sollte sich auf die aktuelle Situation/Person bezie-

hen, konkret formuliert und im Idealfall sofort oder zeitnah

erfüllbar sein. Hilfreiche Frage zur Reflektion: Könnte ein

neutraler Beobachter erkennen, ob die Bitte erfüllt wird

oder nicht?

Diese beschriebenen Schritte sollen kein Storyboard sein,

an dem man sich minutiös entlang hangelt. Vielmehr die-

nen sie als Anregung, sich zunächst einmal ganz in Ruhe mit


sich selbst zu unterhalten. Gehen Sie doch gern mal ein paar

Situationen durch, in denen Sie sich unwohl gefühlt haben

und klopfen Sie die Erinnerung nach den oben genannten

Fragen ab. Was wäre vielleicht anders gelaufen, wenn Sie

hier und dort eine Kleinigkeit anders gemacht hätten? Bitte

vergessen Sie nicht die Empathie für sich selbst! Wir machen

alles so gut und richtig, wie es in dem Moment eben geht.

Niemand steht morgens auf und beschließt seinen Mitmen-

schen wieder mal so richtig auf die Nerven zu gehen. Wir

tun, was wir können, um unsere Bedürfnisse zu erfüllen und

unsere Ziele zu erreichen. Wenn wir uns trauen, die Ebenen

zu wechseln und uns ganz zwanglos neben der Sachfrage zu

bewegen, werden wir erstaunlich schnell zu guter Stimmung

und guten Lösungen zurück finden.

Und was machen wir nun mit dem nervigen Vollpfosten,

für den das anscheinend alles nicht gilt? Nehmen wir mal

an, wir haben mit den vier Schritten erste gute Erfahrun-

gen gemacht und fühlen uns einigermaßen sicher auf dem

Gefühlsparkett. Sind wir doch mal ganz verwegen und for-

dern ihn zum Tanzen auf! Auf geht´s zum Fragen-Foxtrott:

Was ist ihm denn wichtig? Wie fühlt er sich, wenn er von

seinem Problem erzählt? Was würde zu seiner Zufriedenheit

beitragen? Was müsste passieren, damit er weniger Beden-

ken hätte? Die Antworten werden nicht perfekt sein und

sicher tritt man sich hier und dort noch mal auf die Zehen.

Möglicherweise kommt aber Bewegung ins Gespräch. Und

Bewegung ist besser als Stillstand, denn sie führt immer in

die eine oder andere Richtung. Mit guten Fragen, Empathie

und den richtigen Schritten können Sie auf diese Art leichter

und eleganter durch schwierige Situationen tanzen.

Darf ich bitten?

Gabriele Kottlorz ist systemischer

Coach, Mediatorin und Inspirateurin.

Sie verfügt über mehr als 20 Jahre

Berufserfahrung in der Erwach-

senenbildung und schafft mit

Lebenserfahrung, Fachkompetenz

und Empathiefähigkeit den Raum für neue Sichtweisen. Sie

ist immer “hands on”, verliert nie den Kontakt zum echten

Leben und hat einen ausgesprochen scharfen Blick für das

was “trotzdem” geht.

Sie lädt ein zum “Schöner Streiten” und bestärkt als Trainerin

für gewaltfreie Kommunikation eine verbindende Gesprächs-

und Konfliktkultur in Unternehmen.

Als Coach befähigt sie Menschen zu spielerisch-kreativen

Perspektivwechseln und gedanklichen Grenzüberschreitun-

gen. Dabei setzt sie auch mal Pferde, Segelboote oder andere

ungewöhnliche Co-Coaches ein. Das Motto: “Nicht schnacken,

packen”.

Sie ist garantiert unperfekt und immer offen für neue Ideen.

Mit Plüschhenne “Helga” berichtet sie regelmäßig über

Haltung und Pflege des homo oeconomicus und wirft dabei

einen liebvoll-kritischen Blick auf die menschliche Natur.

Sie ist bei Kuntze consulting+coaching die „WildCard“

mit Hang zu unvernünftigen Autos und phantastischen

Veranstaltungskonzepten.


Ihre Karriere bei Sybit – eine runde Sache

Wir suchen Persönlichkeiten, keine Lebensläufe.

Wir brauchen Menschen mit dem Willen und der Fähigkeit, einen Beitrag zu unserem unternehmerischen Erfolg zu leisten. Wir schätzen Kollegen, die ziel-strebig sind, aber nicht linientreu, Menschen mit Eigenverantwortung, Lust auf Dynamik und Herausforderungen. Wir brauchen Teamplayer, die die Arbeit in interdisziplinären Projekten schätzen und kulturelle Vielfalt als Bereiche-rung ansehen. Nur so entstehen die besten Ideen.

sybit.de/karriere

Agilität für Gesellschafter: 7 Schritte, um den Unternehmens-wert nachhaltig zu steigern

Karl Bredemeyer und Stefan Willuda


Agilität für Gesellschafter: 7 Schritte, um den Unter-

nehmenswert nachhaltig zu steigern.

Agilität funktioniert in der Praxis nur dann, wenn es das

explizite Ziel ist, mit Agilität den Unternehmenswert lang-

fristig zu steigern. Gelingt es, die Shareholder für Agilität

zu gewinnen, so wird sie zum Asset des Unternehmens und

somit zur DNA und zum Teil der Unternehmenskultur.

Das bedeutet, es geht bei der Einführung von Rahmenwer-

ken wie Scrum, Kanban, etc. weder darum, Entwicklungs-

teams produktiver zu machen oder ein Board in ein Groß-

raumbüro zu stellen und bunte Zettel dran zu kleben. Noch

geht es darum, die Mitarbeiter zufriedener zu machen, auch

wenn das ein zulässiges Ergebnis agiler Unternehmensfüh-

rung ist.

Ein Unternehmen wird die agile Transition nur so schnell

mitlaufen können, wie ihre langsamste Liefereinheit. Das ist

kostspielig und erfordert Geduld – vor allem die Geduld und

das Buy-In der Gesellschafter. In dem Moment, in dem für

die Eigentümer eines Unternehmens der Zusammenhang

zwischen agilen Führungs- und Entwicklungsrahmenwerken

und der nachhaltigen Steigerung des Unternehmenswertes

klar geworden ist, hat Agilität eine echte Chance. Hierfür

müssen folgende sieben, aufeinander aufbauende, Faktoren

berücksichtigt werden:

1. Die Werte

Das Explizieren agiler Werte ist das Fundament für jede agile

Transition. Hierzu gehören nicht nur die Scrum-Werte, wie

Fokus (der wichtigste!), Mut, Commitment, Offenheit und Res-

pekt oder eine Verortung auf dem agilen Manifest, sondern

auch die Integration von Lean-Prinzipien (eliminate waste,

etc..) und die klare Ansage, dass es wertvoller ist, etwas zu

Ende zu bringen, als etwas Neues zu starten. Ganz wichtig:

kontinuierliche Verbesserung. Wer sagt, für Retrospektiven

gäbe es kein Geld und keine Zeit, kann sich auch hinstellen

und sagen: Für Verbesserung haben wir keine Zeit.

2. Finanzen

Agile Produktentwicklung wird von Wirtschaftsprüfungs-

gesellschaften mittlerweile als Asset gewertet, da sich aus

deren Vorhandensein schnelle Reaktionsfähigkeit sowie

hohe Produktqualität ableiten lassen. Oftmals leidet eben

diese Qualität unter der Last der klassischen Kostenrech-

nung und damit verbundenen Einsparungen oder lokalen

Effizienzgewinnen. Der nächste logische, aber mutige Schritt

geht weg von der Kostenrechnung, hin zur Durchsatzrech-

nung und bietet eine Vielzahl von Indikatoren für qualitative

Management-Entscheidungen.

3. Organisation

Wie bereits erwähnt, ist eine Organisation nur so schnell wie

ihre langsamste Liefereinheit – sowohl in der Transition, als

auch in der Entwicklung und Herstellung von Produkten, egal

ob Software oder Hardware. Auf der Ebene der Organisati-

onsentwicklung müssen daher folgende Themen adressiert

werden:

Theory of Constraints - jedes Investment außerhalb des

Flaschenhalses ist Geldverschwendung

Slack – Menschen ohne Puffer sind, genau wie Maschinen,

fehleranfällig und nicht in der Lage zu innovieren, haben

dafür jedoch das Potential, ein ganzes System

lahmzulegen

Conway’s Law – Organisationen, die Systeme entwerfen,

sind auf Entwürfe festgelegt, welche die Kommunikations-

strukturen dieser Entwürfe abbilden

Mastery, Autonomy and Purpose – warum wir tun, was wir

tun (Daniel Pink)

Agile HR: die Human Ressources, „Abteilung“ als Scrum-

Master der Firma

Organisationaler Reifegrad und Identität – wo verorte ich

mein Unternehmen und welche Schritte muss ich gehen

um den nächsten Reifegrad zu erreichen?

die Bedeutung von Kadenzen als Herzschlag eines

Unternehmens

Evaluierung verschiedener Skalierungsrahmenwerke

Je nach Reifegrad eines Unternehmens variieren Priorität

und Umfang der einzelnen Themengebiete. Es hat sich in

jedem Fall bewährt, im Management Bewusstsein für diese

Themen zu schaffen. Der Erfolg der tatsächlichen Umset-

zung hängt jedoch maßgeblich vom Engagement der Gesell-

schafter ab.

4. Methode und Skill

Das Erlernen agiler Skills und Methoden macht erst dann

Sinn, wenn das Fundament bereits gelegt wurde. Es ist das

Schicksal agiler Coaches und Berater, bei der Vermittlung des

agilen Skillsets zwar bei den Teams relativ schnell Erfolge zu

feiern, dann aber an der Unternehmenskultur und bestehen-

den Organisationsstrukturen zu scheitern. Andersherum hat

eine Transition viel größere Aussicht auf Erfolg, wenn Skills

und Methoden wie:

Scrum

Kanban

Visualisierung

Selbstorganisation durch Führung / Prinzip der

Freiwiligkeit

Servant Leadership

bereits auf fruchtbaren Boden fallen, der vorher von der

Organisation bestellt wurde.


5. Produktentwicklung

Um Produkte erfolgreich entwickeln zu können, bedarf es ein

paar grundsätzlicher Mindset-Änderungen:

Produktorganisation statt Projektorganisation – Projekte

haben ein Start- und ein Enddatum, aber ein Produkt ist nie

wirklich fertig, sondern wird in Iterationen weiterentwi-

ckelt. Gleichzeitig erlaubt der Produktgedanke unwillkür-

lich eine Nutzerzentrierung und stellt die Prozessorientie-

rung in den Hintergrund

Agile Portfolioplanung – nur zu oft werden Priorisierungs-

konflikte der Stakeholder auf dem Rücken der Entwick-

lungsteams ausgetragen. Agile Portfolioplanung bringt die

beteiligten Parteien an einen Tisch und ermöglicht es, team-

übergreifende Prioritäten regelmäßig herauszufordern, zu

bestätigen oder anzupassen

Minimum Viable Product – je früher ein Produkt bereits in

seiner Minimalkonfiguration vom Nutzer getestet und des-

sen Feedback eingeholt werden kann, desto größer ist die

Chance, dass am Ende ein, für den Kunden wertvolles und

nutzenbringendes Produkt herauskommt. Viele Unterneh-

men trauen sich nicht, mit einem „unfertigen“ Produkt vor

die Tür zu gehen, dabei ist das die einzige Chance zu über-

prüfen, ob man gerade überhaupt das Richtige baut.

Crossfunktionale Teams – Selbstorganisation und End-to-end-

Verantwortung in den Teams funktioniert nur, wenn diese

Teams in hohem Maße autark agieren können. Das bedeu-

tet auch, selbst auf die Produktionsumgebung zugreifen

zu können. Getreu dem Motto: You build it, you ship it,

you run it!

6. Architektur

Microservices - um autarke und cross-funktionale Teams

effektiv zu machen, muss diese Architektur die Kommu-

nikationsstrukturen autarker Teams abbilden können

(Conways Law).

7. Infrastruktur

Automatisierung, Automatisierung, Automatisierung – an die-

ser Stelle schließt sich der Kreis zur Engpasstheorie: manu-

elle Arbeit ist der Taktgeber und limitierender Faktor für die

Entwicklungsgeschwindigkeit. Entwicklungs- und Produkti-

onsumgebungen sollten in dem Maße automatisierbar sein,

dass die Teams nicht mehr von manuellen Deployments oder

Testläufen abhängig sind. Ist diese Voraussetzung einmal

gegeben, schließt sich wiederum der Kreis zu den explizit

zu machenden Werten: Verschwendung vermeiden. Jede

Minute, die ein qualifizierter Mitarbeiter mit vermeidbarer,

manueller Arbeit beschäftigt ist, ist Verschwendung. Ver-

schwendung seiner/ihrer wertvollen Zeit, in der entweder

wertgenerierende Arbeit erledigt oder einfach mal die Füße

hochgelegt werden könnten.

Im Ergebnis zahlen alle sieben Punkte auf ein Ziel ein: den

Wert des Unternehmens langfristig steigern. Hierbei ist es

wie bei einem Raumschiff: Sie werden es zum Fliegen brin-

gen, wenn nicht alle Knöpfe grün leuchten. Das volle Poten-

tial entfalten Sie nur, wenn Sie jedem dieser Hinweise die

gebührende Aufmerksamkeit schenken.

Stefan Willuda: Technokratisch

entwickelte Produkte führen nicht

zum Erfolg. Der Betriebswirt Stefan

Willuda weiß das nicht nur aus der

Theorie. Die Prinzipien des agilen

Manifests hat er in der Vergangenheit

oft selbst nicht gelebt, bis ihn die Erfahrung gelehrt hat: Pro-

duktivität und Zwischenmenschlichkeit lassen sich durchaus

miteinander verbinden. So banal diese Erkenntnis – immerhin

eines der „Erfolgsgeheimnisse“ von Scrum – auch klingen

mag: Stefan Willuda ist sich bewusst, dass die Praxis in vielen

Unternehmen völlig anders aussieht.

Karl Bredemeyer ist zweifellos

vom Unternehmergeist beseelt. Der

Betriebswirt hat bereits

Produktentwicklung in seinem eige-

nen Start-up gestalten können und

nutzt seit nun fast 4 Jahren genau

diese Expertise als Management Consultant und Agile Coach

bei borisgloger consulting. Seine Unterstützung beschränkt

sich aber nicht darauf, andere in den Aufgaben und Instru-

menten ihrer Rollen zu coachen. Er übernimmt selbst als Inte-

rims Manager und Interims Product Owner die Verantwortung

für die Organisations- bzw. die Produktentwicklung.


Agil Software zu produzieren liegt uns sehr am Herzen - unsere Erfahrungen weiter zu geben, bringt uns Freude. Wir bieten Scrum-Schulungen, Workshops zu den Themen Innovation, agile Architektur und Anforderungsmanagement sowie Coachings an. Weitere Informationen finden Sie unter

www.sybit-agile.de

Das Geheimnis passionierter Teams

Marc Löffler


Das Geheimnis passionierter Teams Sie kennen das vielleicht: Ihre Firma hat sich dafür ent-

schieden auf agile Methoden, wie z.B. Scrum zu setzen. Das

Management verspricht sich davon eine höhere Produktqua-

lität, eine bessere TTM (Time To Market) und endlich mal Pro-

jekte, die in Zeit und Budget abgeschlossen werden. Obwohl

man sich genau an den Scrum-Prozess gehalten hat, stellt

sich aber nach ein paar Monaten heraus, dass keines der

Versprechen eingetroffen ist. Der Scrum Master probiert ver-

zweifelt ein neues Tool nach dem anderen aus, aber keines

hat den gewünschten, langfristigen Effekt. Nach und nach

fällt das Team zurück in den ursprünglichen Prozess und

am Ende heißt es: Scrum funktioniert bei uns nicht. Und sie

haben recht. Nur weil ich mein totes Pferd mit einem schöne-

ren Sattel ausgestattet habe, wird es trotzdem nicht wieder

davon galoppieren. Um das zu verstehen, muss man ein paar

Schritte zurückgehen und sich fragen, wie Scrum entstanden

ist.

„Erfolg hat nie etwas mit dem implementierten Prozess zu

tun, aber immer mit den Menschen.“ – Marc Löffler

Scrum ist im Grunde nichts anderes, als eine Sammlung von

„Best Practises“, welche man zusammengeschnürt hat und

jetzt unter dem Namen „Scrum“ verkauft. Aber wo kommen

diese „Best Practises“ her? Immer wenn irgendwo ein Pro-

jekt extrem gut gelaufen ist, hat man sich angeschaut, wie

das Team dort gearbeitet hat und die Prozesse kopiert. Oder

man hat selbst in einem solchen Team gearbeitet und die

Prozesse entsprechend dokumentiert. Da das ja so prima

funktioniert hat, kopiert man diese Prozesse eins zu eins in

den neuen Kontext und hat natürlich die Erwartung, dass

es wieder so gut läuft. Dabei vergisst man allerdings eines:

Erfolg hat nie etwas mit dem implementierten Prozess zu

tun, aber immer mit den Menschen. Es ist so, als würde man

sich die Geige von David Garret organisieren und erwarten,

dass man jetzt genauso gut spielen kann. Muss ja schließlich

an der Geige liegen, dass er so gut spielen kann. Aber inte-

ressanterweise erwartet das hier niemand. Schon im Agilen

Manifest steht:

„Individuen und Interaktionen mehr als Prozesse

und Werkzeuge“ – Agile Manifesto

Leider wird das viel zu oft ignoriert. Es macht nie Sinn sich um

die Verbesserung der Prozesse zu kümmern, bevor man sich

mit dem Team auseinandergesetzt hat. In den Fällen, wo ein

Team außergewöhnlich gut war, hat man es immer mit einem

leidenschaftlichen Team zu tun. Ein passioniertes Team kann

alles erreichen, auch wenn die Bedingungen nicht optimal

sind. Es ist selbst dann in der Lage etwas Brauchbares zu

liefern, wenn der vorgegebene Prozess mehr als suboptimal

ist, während ein schlechtes Team auch dann nichts auf die

Straße bringt, wenn es den besten Prozess zur Verfügung

gestellt bekommt. Ein passioniertes Team ist also Grundvor-

aussetzung, wenn ich erfolgreich sein will. Was aber brauche

ich, um ein solch passioniertes Team zu bekommen?

Um ein passioniertes Team aufzubauen, bedarf es verschie-

dener Elemente. Je stärker diese Elemente ausgeprägt sind,

desto besser. Hier kommt das PASSION-Modell in Spiel. Das

Modell definiert die verschiedenen Elemente und deren mög-

liche Ausprägungen, welche die Basis für passionierte Teams

darstellt. Die folgenden Elemente sind Teil des Modells:

Passion (Leidenschaft)Idealerweise verbindet die Mitglieder eines Teams die Lei-

denschaft für das Thema, an dem sie arbeiten und die Tech-

nologie, welche sie entwickeln/einsetzen. Je mehr jemand

für ein Thema brennt, desto besser. Das PASSION-Modell

kennt die folgenden Abstufungen:

Stufe 1: Alles-egal- Einstellung – ob das Projekt Erfolg hat

oder nicht, ist völlig egal. Man sitzt einfach seine Zeit ab.

Stufe 2: Pflichtbewusst – man begeht seine Arbeit pflicht-

bewusst und macht genau das, was gefordert wird, mehr

aber nicht.

Stufe 3: Zielorientiert – man hat ein klares Ziel vor Augen,

welches man gemeinsam mit seinen Teammitgliedern

erreichen will.

Stufe 4: Pure Passion – man brennt für sein Thema/ Projekt

und gibt alles dafür, dass das Projekt ein Erfolg wird.

Adaptable (Anpassungsfähig)In der heutigen Zeit gehört Veränderung zum Alltag. Ein pas-

sioniertes Team ist in der Lage mit jeder Art von Verände-

rung klarzukommen und sich schnell der jeweiligen Situation

anzupassen und sogar einen Vorteil daraus zu gewinnen.

Das PASSION- Modell kennt die folgenden Abstufungen:

Stufe 1: Starr – Keine Anpassungsfähigkeit. Dinge werden

so gemacht wie immer und nicht anders.

Stufe 2: Langsam – Anpassungen sind möglich, aber nur

sehr langsam (oft in Großkonzernen anzutreffen)

Stufe 3: Offen für Veränderungen – Veränderungen sind

jederzeit möglich und werden entsprechend umgesetzt.

Stufe 4: Kontinuierliche Anpassung – Das Team passt sich

kontinuierlich an und startet täglich neue Experimente

und testet Ideen.


Strong Vision (Starke Vision)Solange ich als Teammitglied nicht weiß wohin es gehen soll,

kann ich auch keine sinnvollen Entscheidungen treffen, was

mich wiederum in meiner Selbstorganisation einschränkt

oder mich zu (falschen) Annahmen animiert. Ohne eine

starke, erstrebenswerte Vision kann keine echte Passion in

einem Team entstehen. Das PASSION-Modell kennt die fol-

genden Abstufungen:

Stufe 1: Keine Vision vorhanden – Es gibt schlicht keine

Vision

Stufe 2: Team kennt die Vision nicht – Es gibt eine oder

mehrere Visionen, die dem Team aber nicht bekannt sind.

Stufe 3: Schwache Vision – Die Vision ist dem Team

bekannt, allerdings ist diese nicht wirklich erstrebenswert

oder leidenschaftslos.

Stufe 4: Starke Vision – Das Team wird durch eine starke

Vision geleitet, mit der es sich eindeutig identifiziert.

Strength Oriented (Stärkenorientiert)Eine Studie von Cisco zu Beginn des Jahres 2016 fand heraus,

dass die Teammitglieder in ihren besten Teams vornehmlich

gemäß ihren Stärken eingesetzt wurden. Anstatt zu versu-

chen, die Schwächen abzustellen, macht es mehr Sinn auf

die Stärken der einzelnen Mitarbeiter zu setzen und diese

weiterzuentwickeln. Das PASSION-Modell kennt die folgen-

den Abstufungen:

Stufe 1: Fokus auf Schwächen – Es gibt einen starken

Fokus auf die Schwächen der einzelnen Teammitglieder.

Teammitglieder werden nicht gemäß ihren Stärken

eingesetzt.

Stufe 2: Neutral – Es gibt weder einen Fokus auf Stärken

als auch auf Schwächen. Mitarbeiter werden nach Verfüg-

barkeit den Teams zugeteilt.

Stufe 3: Stärkeorientiert – Mitarbeiter werden vornehmlich

gemäß ihrer Stärken eingesetzt. Die Verfügbarkeit ist nicht

mehr alleiniger Entscheidungsfaktor.

Stufe 4: Stärkeorientiertes Team – Bei der Zusammenstel-

lung des Teams wird explizit darauf geachtet, dass sich die

verschiedenen Stärken der Teammitglieder gegenseitig

ergänzen.

Independent (Unabhängig)Je unabhängiger ein Team von unternehmensweiten Pro-

zessen ist, desto besser. Nur wenn ein Team seinen Prozess,

zumindest in Teilen, selbstbestimmen kann, kann echte

Leidenschaft entstehen. Erfahrungsgemäß sind generelle,

unternehmensweite Prozesse eher hinderlich, als dass sie

einen Mehrwert schaffen. Nicht umsonst hat z.B. BMW für

seine Elektroautos eine eigene Firma gegründet, die unab-

hängig vom Gesamtunternehmen BMW agieren kann. Das

PASSION-Modell kennt die folgenden Abstufungen:

Stufe 1: Globaler Prozess – Das Team unterliegt den

Bestimmungen eines globalen Prozesses und hält diese

strikt ein.

Stufe 2: Adaptierter, globaler Prozess – Das Team hält sich

soweit es geht an den Prozess und liefert die notwendigen

Artefakte. Allerdings nicht immer genau in den vorgegebe-

nen Prozessschritten.

Stufe 3: Verantwortlich für eigenen Prozess – Das Team hat

einen eigenen Prozess, für den es verantwortlich ist.

Stufe 4: Unabhängig vom Rest des Unternehmens – Das

Team ist komplett unabhängig vom Rest des Unterneh-

mens, sowohl hierarchisch als auch auf Prozessebene.

Oneness (Einheit)Bei einem passionierten Team, lässt sich das einzelne Team-

mitglied von außen nicht mehr ausmachen. Das gesamte

Team tritt als Einheit auf. Kein „Blaming“ oder „Finger Poin-

ting“, alle Erfolge oder Misserfolge werden gemeinsam getra-

gen. Diese Einheit bleibt oft über die Arbeit hinaus bestehen.

Das PASSION-Modell kennt die folgenden Abstufungen:

Stufe 1: Einsamer Wolf – Jeder steht für sich und macht sein

Ding.

Stufe 2: Gruppe von Leuten – Es gibt ein Team, aber deren

Mitglieder fühlen sich diesem nicht wirklich zugehörig.

Stufe 3: Team – Jeder fühlt sich als Teil des Teams. Nach

außen tritt man aber nicht immer als Einheit auf.

Stufe 4: Einheit – Das Team ist eine in sich geschlossene

Einheit, die so auch immer nach außen auftritt.

Nimble (Flink)In der heutigen Welt kann man es sich nicht mehr erlauben

langsam sein. Man muss in der Lage sein, sich schnell in

neue Themen einzuarbeiten oder getroffene Entscheidun-

gen schnell über Bord zu werfen. Nur wer dazu in der Lage

ist, wird langfristig Erfolge feiern können. Für passionierte

Teams ist die „Flinkheit“ Teil der DNA. Das PASSION-Modell

kennt die folgenden Abstufungen:

Stufe 1: Keine Bewegung – Das Team ist nicht in der Lage

auf Neues zu reagieren. Es schottet sich nach außen ab.

Stufe 2: Langsam – Mitarbeiter des Teams sind einmal im

Jahr auf einer Fortbildung, lernen darüber hinaus aber

nichts Neues.

Stufe 3: Schnell – Das Team ist in der Lage, sich schnell in

neue Themen einzuarbeiten und stellt getroffene Ent-

scheidungen, wenn notwendig, in Frage.


Stufe 4: Flink – Das Team ist ständig dabei Neues zu lernen

und sogar zu schaffen. Sie beeinflussen den Fortschritt in

ihrem Fachgebiet maßgeblich und erfinden sich täglich

neu.

Anhand dieser Elemente und Abstufungen lässt sich das

eigene Team gut einschätzen. Zusätzlich werden Schwächen

offenbar, die es auszumerzen gilt, um den Weg zu einem pas-

sionierten Team frei zu machen. Erst wenn man sich um das

Thema „Individuen und Interaktionen gekümmert hat, macht

es Sinn, sich um das Thema Prozess zu kümmern. Selbstver-

ständlich kann ein solches Team auch von Scrum profitieren.

Nur macht es eben keinen Sinn darauf zu hoffen, dass Scrum

bestehende Probleme im Team lösen wird. Im Gegenteil,

meist werden sie dadurch erst recht schlimmer. Auch muss

ein Team dazu in der Lage sein, sich den Scrum-Prozess an

ihren eigenen Kontext anzupassen.

2017 erscheint mein Buch zu diesem Thema. Infos gibt es

auf http://marcloeffler.eu.

Marc Löffler arbeitet als selbständi-

ger Agile Coach. Bevor er mit agilen

Methoden in Berührung kam, hat er

als traditioneller Projektmanager

bei Firmen wie die Volkswagen AG

oder die Siemens AG gearbeitet.

Seine Leidenschaft ist es, Teams dabei zu helfen das agile

Wertesystem auf ihre Arbeit zu übertragen. Er liebt es neue

Einsichten zu generieren indem er Teams dabei hilft, Prob-

leme aus einem anderen Blickwinkel zu betrachten. Im Jahr

2014 erschien sein Buch „Retrospektiven in der Praxis“ beim

dpunkt.verlag.


Das geht morgen auch noch! Architekturentscheide sinnvoll vertagen für mehr Agilität

Urs Enzler


Das geht morgen auch noch! Architekturentscheide sinnvoll vertagen für mehr AgilitätSoftwarearchitektur ist die Summe von vielen schwierigen

Entscheidungen.

Je später wir entscheiden, desto mehr wissen wir über die

gestellte Aufgabe. So entscheiden wir einfacher und besser

und der Architekturentscheid von heute steht der Agilität

von morgen nicht im Weg.

Warum vertagen?Der «Cone of Uncertainty»[1] lehrt uns: Je länger wir an unse-

rer Software arbeiten, desto mehr wissen wir über das zu

lösende Problem und die möglichen Lösungsoptionen.

Mit mehr Wissen können wir besser entscheiden. Bei der

Softwarearchitektur wollen wir beispielsweise wissen, wel-

che Programmiersprache die richtige ist, welcher Architek-

turstil zu verwenden ist, wie die Software in Module zerlegt

werden kann, wie Skalierung ermöglicht wird usw.

Sich später festlegen zu können eröffnet uns die Möglich-

keit, vorgängig mit verschiedenen Lösungsvarianten zu

experimentieren.

Daher sollten wir Entscheidungen so spät wie möglich tref-

fen. Aber natürlich nicht zu spät.

Muster für das Vertagen von Architekturentscheiden[2]

Um Architekturentscheide so spät wie möglich fällen zu kön-

nen, gibt es eine Reihe von Vorgehensmustern.

Muster: Aufspaltung von Entscheiden

Wie persistieren wir die Daten in

unserem Softwaresystem?

Das ist eine typische Frage, die zu einem Architekturent-

scheid führt. Bevor jetzt aber das ganze Team «SQL Server»

schreit, weil es diese Technologie kennt, sollte überlegt wer-

den, ob sich dieser Beschluss aufspalten lässt. Beim Aufspal-

ten von Architekturentscheiden wird eine Entscheidung in

mehrere Teile aufgebrochen, welche zu unterschiedlichen

Zeitpunkten entschieden werden können.

Beim Persistieren können das zum Beispiel die folgenden

Teile sein:

Müssen wir persistieren (ja/nein)?

Welche Daten müssen persistiert werden

(Menge, Form, Konsistenz)?

Wie muss der Zugriff sein (Latenz, Durchsatz)?

Welche Technologie, welches Produkt, welcher

Service ist geeignet?

Muster: Vereinfachung

Wenn wir nicht entscheiden können, weil das Problem zu

komplex erscheint, kann eine Vereinfachung helfen. Das

bedeutet, wir vereinfachen das Problem so lange, bis wir

einen Entscheid fällen können. Die Betrachtung der ganzen

Komplexität des Problems schieben wir auf später (siehe

nachfolgendes Beispiel).

Das Risiko dieses Musters ist natürlich, dass wir eventuell für

das ganze Problem auch später keine Lösung finden. Even-

tuell hilft uns dieses Vorgehen aber, mehr Erfahrung mit

einem zwar einfachen aber lauffähigen System zu sammeln,

um anschliessend mit mehr Wissen die gesamte Komplexität

angehen zu können.

Muster: Abstraktion

Abstraktion ist der Klassiker unter den Mustern, um nicht

sofort entscheiden zu müssen. Wir definieren eine Schnitt-

stelle und tun so, als wäre das Problem hinter der Schnitt-

stelle für uns bereits gelöst worden.

Dies ermöglicht es uns zum Beispiel, das Muster «Verein-

fachung» hinter der Schnittstelle anzuwenden. Wenn das

Problem dann effektiv gelöst ist, muss der Quellcode vor der

Abstraktion nicht mehr angepasst werden.

Das Risiko dieses Musters ist, dass wir eine schlechte Abs-

traktion wählen, bei der Implementierungsdetails auf unsere

Seite durchschlagen («leaky abstraction»[3]).

Muster: Gewollte Unwissenheit

Bei diesem Muster geben wir zunächst vor, es gäbe das Pro-

blem gar nicht, für welches wir einen Entscheid brauchen.

Das löst natürlich unser Problem nicht, kann aber helfen, bei

der Umsetzung weiter zu kommen, da wir wichtigere Dinge

bereits implementieren können. So ist zum Beispiel die Per-

sistenz der Daten nicht erforderlich, um Feedback zur Busi-

ness-Logik einzuholen.

Das Risiko ist, dass uns dieser Entscheid unvorbereitet ein-

holen wird. Daher eignet sich dieses Muster nur, um schnel-

les Feedback zu ermöglichen, und sollte danach durch ein

anderes Muster abgelöst werden.

Muster: Entscheidungsdelegation

Wir erklären das Problem zum Problem von jemand anderem.

Und dieser Andere soll uns dann entsprechend aufrufen,

wenn er es gelöst hat. Dazu bieten wir eine Schnittstelle an,

über welche der Aufruf dann geschehen kann.

Dies bedeutet, dass wir uns zum jetzigen Zeitpunkt nicht

um dieses Problem kümmern wollen. Wir umgehen den Ent-

schluss und sind daher nicht mehr blockiert.


Das Risiko hier ist, dass die gewählte Schnittstelle nicht zum

Entscheid im Softwareteil passt, zu welchem wir delegiert

haben.

BeispieleBetrachten wir nochmals das Problem der Persistenz. In mei-

nem Projekt sind wir wie folgt vorgegangen:

1. Gewollte Unwissenheit: Wir speichern keine Daten, son-

dern halten alle in-memory. Dies erlaubt uns die Demons-

tration der Software an Stakeholder, ohne uns um das

Problem kümmern zu müssen.

2. Abstraktion: Wir führen eine Schnittstelle ein, über wel-

che wir Daten laden und speichern können. Wie dies

geschieht, ist im Moment egal, die Business-Logik ist

unabhängig davon.

3. Vereinfachung: Wir speichern die Daten JSON-serialisiert

ins Dateisystem. So überlebt unsere Software einen Neu-

start, ist aber natürlich nicht performant.

4. Entscheid: Wir entscheiden uns für eine Datenbanktech-

nologie, welche geeignet ist, um die Daten zu speichern.

Zu diesem Zeitpunkt wissen wir genau, welche Daten

wir speichern müssen und welche Latenz und welchen

Durchsatz wir ermöglichen müssen.

Als zweites Beispiel betrachten wir das User Interface. In

unserer Software steckt die grösste Komplexität in der Busi-

ness-Logik. Darum wollten wir dazu frühes Feedback, das UI

hatte eine tiefere Priorität. Wir sind deshalb folgendermaßen

vorgegangen:

1. Entscheidungsdelegation: Wir lassen das UI bewusst

beiseite und implementieren die Business-Logik hinter

einem API. So müssen wir keine Entscheidungen zur

UI-Logik treffen.

2. Entscheid: Mit dem Wissen über die benötigten Daten

und Abläufe, bauen wir das UI über das API.

FazitEntscheiden ist sehr wichtig, um eine passende Architektur

entstehen zu lassen. Jedoch sollten Entscheide zum richtigen

Zeitpunkt gefällt werden, mit maximalem Wissensstand über

das Problem und dessen möglichen Lösungsoptionen. Durch

die vorgestellten Muster können Architekturentscheide ver-

tagt werden, um möglichst viele Optionen lange offen zu hal-

ten und um schließlich die Beste zu wählen.

Quellen[ 1 ] Cone of Uncertainty, [Online]. Available: https://en.wikipedia.org/

wiki/Cone_of_Uncertainty.

[ 2 ] Clean Architecture Cheat Sheet, [Online]. Available: http://bbv.ch/

images/bbv/pdf/downloads/Clean_Architecture.pdf.

[ 3 ] Leaky Abstraction, [Online]. Available: https://en.wikipedia.org/

wiki/Leaky_abstraction.

Urs Enzler ist ein agil gesinnter

Softwareentwickler mit einer Vorliebe

für architektonische Herausforderun-

gen, Clean Code und Lernen als Team.

Er spricht gerne über diese Themen an

Konferenzen und Community-Anlässen.


www.sybit-agile.de/community/agile-breakfast

Agile BreakfastIn losen Abständen von rund zwei Monaten treffen sich agil Interessierte zum Erfahrungsaustausch. Beim „Agile Breakfast“ im Wasserturm Stromey-ersdorf in Konstanz hält nach einem kleinen Früh-stück ein Teilnehmer oder ein geladener Speaker einen Vortrag zu einem agilen Thema. Daran schließt sich eine Diskussion an.

Die Veranstaltung wird von Sybit gesponsert – die Teilnahme ist kostenlos.

Phase 0 – das Schmiermittelfür den Start komplexer IT-Projekte

Gerd Bart


Phase 0 – das Schmiermittel für den Start komplexer IT-Projekte

Sie kennen das. Sportliche Terminpläne, unklare Ziele,

heterogene Stakeholder, dubiose Prozesse und sie als Pro-

jektverantwortlicher benötigen schnelle Ergebnisse. Nicht

zu vernachlässigen: das Projekt ist als strategisches Projekt

deklariert.

Sage mir, wie dein Projekt beginnt und ich sage dir,

wie es enden wird.

Ein Zitat aus dem klassischen Projektmanagement, das noch

heute seine Gültigkeit hat. Lag damals die Bedeutung auf

dem Kickoff eines Projektes, so würde ich dies heute für eine

ganze Phase erweitern wollen. Eine Phase, die den Grund-

stein für das Projekt legt: die Phase 0.

Phase 0 ist ein Begriff aus der Raumfahrt oder aus der Phar-

mazie. Beide Branchen nutzen diese Zeit als Vorbereitung

auf das Projekt. In der Pharmazie werden erste, minimale

klinische Studien, die dem Test der pharmakokinetischen

Eigenschaften eines neuen Wirkstoffes beim Menschen die-

nen, vorgenommen. Also eine Phase, in der auf den Nutzer

zugeschnittene Abläufe und Prozesse analysiert und erprobt

werden. Eine Phase der Grundsteinlegung für das Projekt.

Eine Phase, die Ihnen als Projektleiter die Sicherheit gibt, die

wichtigen und richtigen Dinge zu tun und das Unwichtige

wegzulassen.

Die Phase 0 … ist eine Methodik, um mit erprobten Konzepten eine Anfor-

derungsanalyse und Konzeption zu gestalten.

ist eine klare und strukturierte Vorgehensweise, die auf

einzelnen Elementen aufbaut.

stellt den Nutzer dabei in den Mittelpunkt

(kundenzentriert).

ist ein Vorgehen, das klare Ergebnisse liefert und in einem

agilen Projektprozess (Scrum) mündet.

ist ein Prozess, der das gesamte Projektteam bei der Reali-

sierung des komplexen Vorhabens mit auf die Reise nimmt.

Vom Denkansatz gehen wir von zwei Räumen aus. Der

Grundidee folgend gehen wir von den Herausforderungen

(Problemraum) zur Lösung (Lösungsraum).

Der Problemraum

Der Problemraum beschäftigt sich mit dem IST-Zustand

einer Sache: Prozessen, IT-Systemen und vor allem mit den

Problemen, die der Nutzer bei der Anwendung der heutigen

Systeme und Abläufe hat. Es ist eine strukturierte Form der

Erhebung von Informationen, um zielgerichtet im Lösungs-

raum damit zu arbeiten.

Der Lösungsraum

Dieser Raum dient zur Modellierung, Gestaltung und Kon-

kretisierung der dann zu realisierenden Lösung, also dem

SOLL-Zustand und unterstützt vor allem beim Aufbau des

Backlogs. Als Grundlage dienen alle Informationen, die im

Problemraum identifiziert wurden.

Diese teilweise philosophische Betrachtung der Phase ist in

den einzelnen Zyklen wichtig (siehe Abb. 1).

Die Phase 0 erstreckt sich über vier Teilbereiche. Die wich-

tigsten Elemente sind hierbei stets die Prozesse, Daten, Nut-

zer (des Systems) und die Organisation des Unternehmens:

Abbildung 1: Methodischer Ansatz Phase 0

Herausforderung Lösung

Analysieren Modellieren KonkretisierenEntdecken

Problemraum Lösungsraum


§ E-BusinessCanvas§ Interviews§ Inventur§ Datenanalyse

§ Personas§ Use Cases§ UserJourneys§ Wettbewerbsanalyse§ Stammdaten§ Bewegungsdaten§ Schnittstellen§ SAPIntegration

§ DesignKonzept§ Informationsarchitektur§ StoryMapping§ Wireframes§ Ideation§ Prozesse§ Organisation

§ Prototypentwicklung§ Design§ StoryMapping

>> Backlog

Projektkoordination

Entdecken Analysieren Modellieren Konkretisieren

ImplementierungProjektinitialisierung

Entdecken

Das Unbekannte aufdecken. Vorhandene Nutzer, IT-Sys-

teme, Prozesse und Daten kennenlernen (Entdecken) und für

das Projekt inventarisieren.

Analysieren

Das Entdeckte näher beleuchten, in kleine Brocken aufbre-

chen und analysieren. Insbesondere liegt der Schwerpunkt

in der Analyse der Nutzer (Personas), dem Weg, den diese

durch das System / die Systeme zurücklegen (User Journeys

/ Szenarios) sowie die damit verbunden Daten (Stamm- und

Bewegungsdaten).

Die Analyse des Wettbewerbs hilft zur eigenen Standort-

bestimmung und zur richtigen Zielsetzung sowie bei der

Analyse der notwendigen Schnittstellen für die technische

Integration.

Modellieren

Die Erkenntnisse der Analyse werden gepaart mit Kompetenz

und Fachkenntnis des Beraters zielgerichtet eingesetzt und

erste Lösungsansätze modelliert. Ganz vorne steht die Ide-

ation. Beim kreativen Prozess (mit vielen Kreativitätstech-

niken) werden Varianten für die Lösungen gesammelt.

Hierbei gibt es meist nicht nur die eine Lösung. Daneben

steht das Design-Konzept. Hier werden die Erkenntnis aus

der Analyse hinsichtlich Journey und Personas in Informa-

tionsarchitekturen gebracht, die ersten Wireframes erstellt

und das Design-Konzept erarbeitet. Mit dabei ist die Erstel-

lung von neuen Prozessen und ggfs. der Aufbau von neuen

Organisationsstrukturen.

Konkretisieren

Aus dem Modellieren zeichnet sich ein Lösungsansatz ab, der

in dieser Phase konkretisiert wird. Konkret genug, um damit

in einem agilen Prozess (Scrum) weiterzuarbeiten. Unkon-

kret genug, um auf etwaige Veränderungen während des

Entwicklungsprozesses reagieren zu können. Oftmals wer-

den in dieser Phase Prototypen entwickelt. Der Hauptfokus

liegt aber nach wie vor im Aufbau des notwendigen Back-

logs. Dass dies in Form von User-Stories getan wird, versteht

sich.

Wo ist denn nun das Schmiermittel?Wenn sie zwischen den einzelnen Schritten und Abläufen der

Phase 0 genau hinschauen, können sie dazwischen das Öl

tropfen sehen, das Ihrem Projekt die notwendige Geschmei-

digkeit verleiht.

Schmiermittel – Denkansatz & Gesamtmethode

Die Trennung der zwei Räume in einen Problemraum und

Lösungsraum stellt einerseits hohe Ansprüche an den Mode-

rator der Workshops, andererseits bietet es Ihnen klare

Handlungsweisen für alle Stakeholder im Projekt. Die klare

und eindeutige IST-Situation wird herausgearbeitet. Ein Ver-

bergen von Informationen ist durch das methodische Vorge-

hen nahezu ausgeschlossen und alle Informationen für eine

saubere Projektimplementierung sind gegeben.

Auch in der Modellierung von Lösungen innerhalb des

Lösungsraums gibt es Methoden, die verhindern, dass das

Projektteam in Problemen denkt und stattdessen eine

lösungsorientierte Herangehensweise verfolgt.

Auch die klar aufeinander aufbauende Reihenfolge der Pha-

sen in Kombination mit klaren Ergebnissen aus allen Work-

shops, lässt die Schmierung sichtbar werden. Die einzelnen

Phasen folgen einer klaren Logik und erzeugen vom IST-Zu-

stand ausgehend (Entdecken), über die Analyse der Zielset-

zungen und Wünsche (Analysieren), hin zur Lösungsfindung

(Modellieren) bis zur detaillierteren Konzeption (Konkretisie-

ren) einen klaren Weg. Das Projektteam wird auf eine struk-

turierte Reise mitgenommen, die Ergebnisse folgen und wer-

den vom Team mitgetragen.

Abbildung 2: Übersicht Phase 0


Schmiermittel – E-Business Canvas

Stark vereinfacht ausgedrückt erarbeitet man mit dem E-Bu-

siness Canvas in einem methodischen Prozess die Hypo-

these des Projektes. Die Annahme, die zur Veränderung des

Ist-Zustandes und damit zum Projekt führt, wird dadurch

dokumentiert und mit einigen weiteren Informationen

manifestiert. Das E-Business Canvas ist abgeleitet aus der

Businessplanung einer Geschäftsidee und beschäftigt sich

daher auch mit Risiken, Zielen, dem Wert, der mit dem Pro-

jekt erschaffen werden soll und natürlich auch mit Kosten

und Einnahmen.

Die Definition des E-Business Canvas zusammen mit allen

Stakeholdern sorgt von Anbeginn für klare Verhältnisse über

Zeit, Geld und Zielsetzung. Der „Sinn“ des Projektes für das

Unternehmen ist herausgearbeitet und dient als zentrale

Messlatte. Der Turbo im Schmiermittel wird erreicht, wenn

das Canvas im Projektraum einen zentralen Platz einnimmt

und in den zahlreichen Workshops und Diskussionen immer

wieder darauf verwiesen wird. Manche Widerstände verlau-

fen dadurch auf mysteriöse Weise im Sand.

Schmiermittel – der Nutzer

Bei der offenen und neutralen Betrachtung unserer bisheri-

gen Projekte stellen wir fest, dass die Anforderungen meist

aus dem Projektteam heraus definiert worden sind. Doch wie

viele dieser Anforderungen waren richtig? Welche sorgten

für eine Akzeptanz beim Nutzer respektive für einen Erfolg

für das Unternehmen? Definieren Sie diese Zahl für sich ein-

mal selbst! Das Problem mit dem Begriff „Anforderungen“

besteht vor allem darin, dass er suggeriert ein Feature sei

erforderlich, obwohl es in Wirklichkeit nur gewollt ist.

Das größte Schmiermittel ist daher der Nutzer. Im Idealfall

können wir in der Analysephase den/die Nutzer befragen,

was sie an der heutigen Lösung stört bzw. was sie von einer

künftigen Lösung erwarten. Diese Erkenntnis über die Auf-

gabenstellungen, die ein Nutzer mit einer Software verbin-

det (neben einigen weiteren Informationen), versetzt das

Projektteam in die Lage, nur über die Anforderungen/ Fea-

tures zu sprechen, die wirklich relevant sind. Funktionen, die

keiner braucht – das gehört der Vergangenheit an.

Schmiermittel – der Nutzer Teil II

Nicht nur die „richtigen“ Features werden über den Nut-

zer definiert. Auch die Architektur und die Workflows des

Gesamtsystems. So definiert der Nutzer letztlich, wie er

sich im System bewegt (bewegen möchte). Diese Definition

spiegelt sich in Journeys, Prozessen und Sitemaps letztlich

wieder. Heute spricht man hierbei von der User Experience

(UX). Hierbei geht es ganz konkret um das Erlebnis, das ein

Nutzer/ Anwender mit einem System hat. Also welche Erfah-

rung ein Nutzer bei der Interaktion mit einem IT-System /

IT-Gerät macht. Einige heute nicht mehr wegzudenkende

Geräte wären nicht erfolgreich, wenn sie dieses Schmier-

mittel nicht über alles gestellt hätten. Wenn Sie hier Ihre

Sitemap, Ihre Prozesse oder im besten Fall Ihre Wireframes

mit den Anwendern teilen – werden Sie das Schmiermittel

tropfen sehen.

Abbildung 3: E-Business Canvas

BusinessHypothese

Nutzer Wertangebot|Serviceversprechen Wettbewerb

Schlüsselaktivitäten USP|Stärken&Schwächen

Einnahmequellen |ROI Kostenstruktur

§ VorgebenderRichtung,positiv-formulierteVorstellung desSollzustandes§ DefinitionderZieledieangestrebtwerdensollen

§ DefinitionderKennzahlen/KPIsdiezurPrüfungderZielerreichungherangezogenwerden

§ FürwenwollenwireinenWertschöpfen?§ WeristunsereZielgruppe?§ WersinddieAnwender/Nutzer?§ WasistderenBusiness-Pain?

§ WelcheSchlüsselaktivitätenerfordernunserWertangebot?UnsereProduktion?Daten?Kundenbeziehung?

§ WassinddiewichtigenHandlungen,diegetanwerdenmüssen,damitdasVorhabenerfolgreichwird.

§ WelchenWertvermittelnwirdemKunden§ WelcheProblemeunsererKundenversuchenwirzulösen?WelcheKundenbedürfnisseerfüllenwir

§ WelcheProdukt- undDienstleistungspaketebietenwirjedemKundensegmentan?

§ WelcheähnlicheAngebotegibtesbereits?§ WersinddiewichtigstenWettbewerber?§ WelcheHerausforderungensindhierabsehbar?

§ WassindunsereUSPs?§ WassindunsereStärken,wassindunsereSchwächen?§ WiekönnenwirunsereStärkenstärken?

§ WiekönnenEinnahmequellengeneriertwerden?FürwelcheWertesindunsereKundenwirklichzubezahlenbereit?

§ WielässtsichanhandsolchermöglicherSzenarieneinROIdesVorhabensabschätzen?

§ WelchessinddiewichtigstenmitunseremModellverbundenenKosten?§ WelcheAktivitätensindamteuersten?§ Wert-,Fix,VariableKosten


Schmiermittel – der Nutzer Teil III

Bauen Sie einen Prototyp. Stellen Sie diesen Ihren Anwendern

zur Verfügung. Sammeln Sie die Erkenntnisse und Erfahrun-

gen ein. Passen Sie Ihre bis dahin gemachten User-Stories

auf diese Informationen an. Eine bessere Schmierung kann

Ihr Projekt nicht bekommen.

Schmiermittel – Story Mapping

Bei der Durchführung der Phase 0 entsteht das Backlog

(Liste der Dinge, die getan werden müssen). Das Backlog

in unserem Falle besteht aus den zahlreichen User-Stories

(resp. Epics), die sinnvoll zu strukturieren sind - also die Sor-

tierung, die User-Stories und die Organisation. Dieses Map-

ping beschäftigt sich mit der Frage nach dem minimal ver-

wendbaren Umfang, der zu realisieren ist, um einen Wert an

den Kunden zu liefern.

Hier kann man auch vom sogenannten MVP (Minimum Viable

Product) sprechen. Also die Definition des Projektes mit den

minimalsten Anforderungen und Eigenschaften, die es aber

benötigt, um das Projekt live zu stellen.

Allerdings befinden sich, sofern Sie Ihre Hausaufgaben in

allen Phasen richtig gemacht und die jeweiligen Schmier-

mittel gut eingesetzt haben, in Ihrem Backlog nur noch Sto-

ries die relevant für Ihre Nutzer sind. Eine erneute Prüfung

über den Weg eines MVP halte ich daher für nicht zielfüh-

rend. Sinniger erscheint mir eine klassische Priorisierung der

User-Stories, die vielfach auch durch Prozesse, Schnittstel-

len, Vermarktung und andere Rahmenparameter mit defi-

niert werden. Dies sollte zu Beginn der Implementierung

erfolgen.

Für mich ist das (bitte visuelle) Story-Mapping ein perfektes

Werkzeug, um im gesamten Projektteam über alle User-Sto-

ries / Epics zu sprechen und einen Plan zu erstellen, der sich

in sinnvolle Sprints teilen lässt. Hierbei geht es vor dem Start

der Implementierung um die klaren Elemente:

Transparenz über alle Epics / User-Stories hinweg für alle

Beteiligten

Überprüfung über alle User-Stories hinsichtlich der Rich-

tigkeit im Gesamtkontext

Anpassung der Stories. Denn diese werden nicht ein für

alle Mal festgelegt, sondern kontinuierlich detailliert und

angepasst (insbesondere in der Abwicklung = Scrum). Aber

vor allem gilt es hierbei komplexe Aufgaben zu zerkleinern

und in weniger komplexe Bestandteile aufzusplitten.

Neben der klaren Notwendigkeit, sich in Gänze mit allen

User-Stories auseinanderzusetzen, diese zu sortieren, pri-

orisieren, zu prüfen und ggfs. anzupassen, findet sich das

Schmiermittel in der Methode selbst. So sind die Transpa-

renz und das Hinterfragen der Stories über Richtigkeit und

Notwendigkeit das Entscheidende. Ein gutes Mapping der

Stories bedarf allerdings auch einer stringenten und guten

Moderation und Führung der Teilnehmer.

Am Ende der Phase 0Am Ende der Phase 0 steht ein von allen Stakeholdern getra-

genes priorisiertes Backlog. Eine perfekte Basis für die agile

Projektdurchführung. Insofern ist das Backlog schlichtweg

die Sammlung aller Anforderungen (= die Ergebnisse der

obigen Workshops) an die Software, die entwickelt werden

soll. Das Backlog folgt dem agilen Prozess. Insofern ist es

nicht zu verwechseln mit einem Lastenheft. Im Rahmen der

agilen Implementierung (Planning) ist es selbstverständlich

jederzeit möglich, das Backlog zu verändern und den Gege-

benheiten anzupassen. Insofern sollten Sie die User-Stories

auch nicht zu detailliert schreiben! Dennoch sollten Sie in

jede User-Story die im Rahmen der Phase 0 erstellten Daten

& Strukturen, Architektur & Interfaces, Business Prozesse

und UX / UI Design stecken. Viel Erfolg!

Gerd Bart kann auf über 17 Jahre

Erfahrung im E-Business zurück-

blicken und ist bei Sybit als Solu-

tion Principal E-Business tätig. In

seinen früheren Positionen war er

in Entwicklung, Beratung, Business

Development und Bereichsleitung tätig. Seine dort gesam-

melten Erfahrungen bringt er zielorientiert und pragmatisch

für unsere Kunden in strategischen und konzeptionellen

Fragestellungen ein und berät im E-Business Umfeld auf der

Basis von SAP Hybris.


Lust auf was Neues?

Zukunft gestalten - Karriere machen - Fortbildung nutzen - Teamspirit spüren - Freiheiten genießen - Sicherheit erleben.

Wie sich Ihre Karriere bei Sybit entwickeln wird, steht für uns schon fest: Wir wollen Ihnen keinen festen Werdegang vorschreiben, sondern Ihren per-sönlichen Weg ebnen. Ihre Potentiale und Wünsche bestimmen die Richtung. Wir bereiten Ihnen die Bühne mit flachen Hierarchien, motivierten Teams, maximaler Eigenverantwortung, ergebnisbezogener Führung und persona-lisierter Fortbildung. An unserer SyCademy können Sie an Ihren fachspezifi-schen Kenntnissen und persönlichen Fähigkeiten feilen.

sybit.de/karriere

The very best of Scrum

Thomas van Aken


The very best of Scrum

Agile ist Mainstream und Scrum das am meisten verbreitete

agile Framework. Doch warum ist das so? Was sind die gro-

ßen Vorteile von Scrum? Hier sind meine Favoriten unter den

Erfolgsfaktoren:

Mit Komplexität tanzen gehenDas Stacey-Diagramm (Abbildung 1) diskutiere ich gerne

schon ganz früh mit Kunden in gemeinsamen Projekten. Die

Aussage dahinter ist, dass die Parameter eines Projektes, die

es zum Erfolg führen (im Kontext von Softwareprojekten sind

dies Anforderungen, technische Rahmenbedingungen sowie

das Setup und die Zusammenarbeit des Projektteams), ent-

weder vollkommen bekannt oder gänzlich unbekannt sein

können (Y-Achse). Im Verlauf des Projektes sind diese Para-

meter entweder dauernden Änderungen unterworfen oder

bleiben gänzlich stabil (X-Achse). In der Diskussion hierzu

bitte ich meine Kunden, einen Punkt in dieses Diagramm zu

zeichnen, wo sie das Projekt sehen. Wenig überraschend:

Bisher wurde noch nie ein Punkt in der linken unteren Ecke

gemacht! Das würde ja auch bedeuten, dass a) das Projekt-

vorhaben langweilig ist und b) die Beteiligten das Wesen von

Softwareentwicklung[1] nicht verstanden haben: Denn dieses

ist per Definition komplex[2].

Abbildung 1: Das auf die Softwareentwicklung hin angepasste

Stacey-Diagramm

Nun können wir völlig zurecht fragen: Wie kann man in die-

sem Kontext auf die Idee kommen, sich selbst ein Menü mit

dem schönen Titel „Up-Front-Spezifikation im Dialog mit Fix-

Scope auf einem leichten Festpreis-Bett“ aufzutischen? Das

muss schwer verdaulich sein und kann mit klarem Verstand

nur zurück in die Küche gesendet werden.

Was also tun? Ein guter Start ist, sich als ganzes Projekt-

team eine partielle Unwissenheit einzugestehen (denn wer

sind wir schon, also ehrlich). Darüber hinaus sollten sich

alle Seiten bewusst sein, dass Änderungen auf dem Weg

nicht nur ein notwendiges Übel, sondern absolut erwünscht

sind. Denn wer am Anfang nicht alles weiß, sollte sich zum

gemeinsamen Lernen verabreden. Nur so kann man die Kom-

plexität im Projekt sanft aufs Parkett führen, anstatt sie

vom Start weg in der Garderobe verstecken zu wollen! Nun

brauchen wir noch ein Framework, in dem wir nach bestem

Wissen und Gewissen planen, den Plan ausführen und das

Ergebnis zeitnah reflektieren, um dann den Plan mit Hilfe

neuer Erkenntnisse zu verbessern. Dieser Ablauf nennt sich

in Scrum „Sprints“. Sprints bilden den Rhythmus bei dem

jeder mit muss.

Der Paradigmen-WechselKonkret bedeutet dies aber auch oft, dass es am Anfang

bereits einen Plan geben muss. Dieser detailliert zwar nur

das, was zeitnah auch umgesetzt werden kann, dennoch

muss in vielen Fällen für den gesamten Scope eine best-

mögliche Annahme über das Budget, das Team-Setup sowie

den zeitlichen Horizont gestellt werden. Da dies ja nur eine

Annahme sein kann, dreht man im nächsten Schritt (Abbil-

dung 2) das Dreieck einfach um. Ganz im Sinne von Scrum

bleibt die Time-Box des Projektes – und damit auch das

Budget – stabil. Jetzt liegt der Fokus auf der Anpassung

des Scopes. Wer an dieser Stelle das „Feature complete-

ness“-Schiff davon segeln lässt, macht Platz für die wirklich

wichtige Frage: Wie schaffen wir es gemeinsam und in dem

vorgegebenen Rahmen den höchsten Mehrwert für unsere

Kunden und Nutzer zu schaffen?

Abbildung 2: Paradigmen-Wechsel: Plan-getrieben versus

Wert-getrieben

Dem User seine echten StoriesDamit verbindet sich die Frage, wie man Einsichten darü-

ber sammelt, gegen welchen Bedarf man beim Nutzer und

am Markt überhaupt antritt und wie man echten Erfolg

messen kann. Denn die echte Feedback-Schleife wird nicht

PlanDriven

ValueDriven

KlassischerAnsatz AgilerAnsatz

fixed

estimated

Budget

Budget Time

Time Scope

Scope

Complex

Simple

Chaoticunknown

known

stable unstable


zwischen dem Planning und dem (internen) Review-Mee-

ting aufgespannt. „Entscheidend is auf’m Platz“[3]: Das gilt

vorne bei den Anforderungen sowie hinten nach der Aus-

lieferung. Das heißt, vorne sind quantitative Analysen (z.B.

Markt-Benchmarks und Analytics-Daten) sowie qualitative

Verfahren (Nutzer-Interviews, Online-Umfragen etc.) gefragt

und hinten – auch. Immer wenn ein Projektteam den eigenen

Mikrokosmos verlässt und echtes Nutzerfeedback mit einbe-

zieht, geht die Sonne auf[4]. Ab diesem Punkt fängt man an,

echte Stories über seine Nutzer zu schreiben. Das heißt für

mich, die agile Wertschöpfungskette zu Ende zu denken.

Raum für Zusammenarbeit und VertrauenLässt man sich auf die gemeinsame Suche nach echtem

Mehrwert im Projekt ein, ist man im besten Sinne zur Zusam-

menarbeit verdammt. In Scrum trifft sich das Scrum-Team

täglich und das ganze Projekt-Team (im besten Fall inklusive

echten Nutzern) alle ein bis vier Wochen. So lernt man sich

kennen, weiß um die Stärken und Schwächen des anderen,

gewinnt Vertrauen. Die Retrospektive in Scrum ist hierzu ein

wichtiger Schlüssel: Sie macht nicht nur Dinge transparent,

die alle Beteiligten verbessern können und damit offensicht-

lich, was ohnehin schon klar ist: Es sind nur Menschen am

Werk. Darüber hinaus wird hier deutlich, dass in der Regel

alle ihr Bestes für das gemeinsame Ziel geben. Ist dies ein-

mal nicht der Fall, adressiert die Retrospektive früh dieses

Projektrisiko der Kategorie 1 und schafft den Raum, die

Ursachen hierfür zu finden und zu beheben. Ich kenne kei-

nen Ansatz, der so viel schonungslose Offenheit und Trans-

parenz von allen Seiten fordert. Eine echte Herausforderung

für alle, aber damit auch eine echte Chance, immer wieder

neue und bessere Wege zu gehen.

Kein Platz für Helden: Selbstorganisierte Teams schaffen Räume und machen den UnterschiedIn der agilen Community wird viel darüber gesprochen, wie

man zu selbstorganisierten Teams kommt. Das ist in der Tat

nicht einfach und daher eine wertvolle Diskussion. Ein guter

Scrum Master mit einem guten Standing im Team sowie

gegenüber dem Management ist sicherlich ein wichtiger

Baustein hierzu (s.u.).

Seltener liest man darüber, warum man Selbstorganisation

überhaupt braucht. Vielleicht weil eine wesentliche Antwort

auf diese Frage so einfach ist: Es gibt keine Helden in der

Softwareentwicklung! Die Dinge sind immer zu komplex, als

dass einer den Plan für alles haben kann. In der Komplexi-

tätstheorie heißt es, dass zur Bewältigung einer komplexen

Aufgabenstellung die Einheit zur Bewältigung des Problems

eine Komplexität größer gleich der Aufgabenstellung vor-

weisen muss. Oder anders: Versammle Menschen mit soviel

Erfahrung und „Rechenleistung“ wie möglich und schaffe

ihnen einen Raum für eine effiziente Vernetzung. In Scrum

wird dieser Raum dadurch geschaffen, dass es niemanden

mehr gibt, der sagt, was der einzelne wann und wie zu tun

hat. Dies schafft Platz für jeden im Team, sich mit all sei-

nem Wissen und seinen Ideen kreativ einzubringen. Darüber

hinaus sind die Teammitglieder aufgefordert, sich in diesem

Raum selber bestmöglich zu vernetzen. All dies entfaltet

völlig neue Potentiale und bringt die Zusammenarbeit auf

eine neue Ebene. Doch der Kern des Ganzen liegt noch tiefer:

Durch diese Freiheit und der damit verbundenen wertschät-

zenden Aufforderung sich einzubringen, steigt die Motiva-

tion im Team. Das ist zum Beispiel der Moment, in dem der

Neue im Team in der Retro aufsteht und eine Idee hat, die

alle gut finden und so umsetzen.

Der Scrum Master – verdammt zu überzeugenDie Räume für Kreativität und Selbstorganisation zu schaf-

fen sowie das Team dahin zu führen, diese Räume konst-

ruktiv und produktiv zu nutzen, das sind die Kernaufgaben

des Scrum Masters. Effektiv Entscheidungen zu treffen und

Konsens herzustellen, wird im Rahmen der Selbstorgani-

sation zur Herausforderung für das ganze Team. Für jeden

einzelnen bedeutet dies, sein Ego in den Dienst der gemein-

samen Sache zu stellen[5]. Dies braucht eine Atmosphäre

und ein Miteinander, in der jeder zurückstecken kann, ohne

damit verlieren zu müssen. Der Scrum Master coacht in die-

sem Prozess das Team sowie jeden einzelnen. Auf diesem

mitunter nicht einfachen Weg ist es an ihm, immer wieder

klarzumachen, warum diese Art der Zusammenarbeit wichtig

und richtig ist und warum sich der Einsatz jedes Einzelnen

lohnt. Doch am Ende muss jedes Teammitglied diesen Schritt

für sich gehen.

Abbildung 3: Der Scrum Master als „Ego-Pushbacker“ bringt das

Team zum Fliegen. ;-) Quelle: fraport.de


Deswegen ist es so weise, dass der Scrum Master keinerlei

Weisungsbefugnis hat – er ist per Rollendefinition verdammt,

zu überzeugen. Verantwortung für sich und andere zu über-

nehmen, kann man nun mal nicht verordnen.

Das ist übrigens auch einer der besten Momente im Leben

eines Scrum Masters, wenn man feststellt, dass das Team

einen Schritt aufeinander zugeht, die persönliche Ebene

zurücktritt und die Energie für die fokussierte Arbeit an der

gemeinsamen Sache frei wird.

Keine Zeit zu lesen? Hier gibt es die Zusammenfassung:Scrum schafft Räume, in denen sich Menschen wohlwollend,

offen und nicht zuletzt mit Spaß begegnen können, um krea-

tiv an tollen Lösungen für komplexe Aufgabenstellungen zu

arbeiten[6].

Hierfür braucht es ein Umfeld, das diese Räume zulässt und

die Bereitschaft aller, sie positiv zu nutzen. Eine wichtige

Zutat hierfür: Der Scrum Master als Moderator und Katalysa-

tor. Letztlich sind jedoch alle Beteiligten gefragt, sich auf den

Paradigmenwechsel einzulassen. Wer eine solche Arbeits-

weise einmal erlebt hat, wird sie immer wieder suchen.

Quellen[ 1 ] Softwareprojekte können durchaus standardisierte Roll-out-Pro-

jekte sein. Diese seien hier ausgeklammert, um den Plot nicht zu

verwässern..

[ 2 ] Spätestens wenn der Faktor Mensch dazu kommt, wird es manch-

mal sogar abenteuerlich – sagt man sich.

[ 3 ] Frei nach Adi Preißler. https://de.wikipedia.org/wiki/Alfred_Preißler

[ 4 ] Im Lean User Experience Umfeld gibt es in diesem Kontext den

sehr heiter formulierten Imperativ „Get out the f*** building!“ –

was nicht nur im übertragenen Sinn gemeint ist.

[ 5 ] Mit dem Vortragstitel „Agree or Disagree, but commit“ haben es

Pamela Hackett und Mischa Ramseyer bei der Agile Bodensee

Konferenz 2015 auf den Punkt gebracht.

[ 6 ] Siehe auch die Definition von Scrum im Scrum Guide:

http://www.scrumguides.org/scrum-guide.html#definition

Thomas van Aken ist seit ca. 15

Jahren in der Softwareentwicklung

unterwegs. Seit 2008 wendet er

dabei in den verschiedensten Rollen

(Entwickler, Produkt-, Projekt- und

Programm-Manager) agile und

schlanke Methoden an. Seit 2012 begleitet Thomas van Aken

als Agile Coach Teams bei der Einführung agiler Methoden

und gibt Schulungen zu den Themen Scrum, Kanban, agiles

Anforderungs management sowie Agile und Lean UX.


Diese und alle bisherigen Ausgaben finden Sie auf unserer Website als PDF zum Download. Lesen Sie rein, es lohnt sich!

sybit-agile.de/community/agile-magazin

Sybit GmbHSankt-Johannis-Str. 1-578315 Radolfzell, DeutschlandFon: +49 (0) 7732 9508-0Fax: +49 (0) 7732 9508-111E-Mail: [email protected]: www.sybit-agile.de

Einige der verwendeten Fotos unterliegen der Creative Commons-Lizenz:

https://creativecommons.org/licenses/ by-sa/2.0/legalcode

Chefredaktion (V.i.S.d.P.):Johannes [email protected]

Redaktion:Stephan [email protected]

Autoren-Service:Sie möchten einen Artikel in einer der folgenden Ausgaben beisteuern? Sprechen Sie uns an:

Stephan [email protected]

Agile Softwareentwicklung im Fokussybit-agile.de

Ausgabe 1609/2016

Best of agile# - Sybit GmbH · 2018-01-17 · Das Geheimnis passionierter Teams Marc Löffler Das...

Documents

Transcript of Best of agile# - Sybit GmbH · 2018-01-17 · Das Geheimnis passionierter Teams Marc Löffler Das...