Sybit agile · agile Agile Softwareentwicklung im Fokus Sybit Ausgabe 11 Kudo Kasten Jurgen Appelo...

agile Agile Softwareentwicklung im Fokus

Ausgabe 11Sybit agile

Kudo Kasten Jurgen AppeloSeite 3

DevOps - Agilität weiter gedacht Thomas WilhelmSeite 5

Introducing Continuous Delivery Christoph Lukas und Alexander BirkSeite 8

Agile Innovation – Produktmanagement in turbulenten Zeiten Vasco DuarteSeite 12

2 Sybit agile | Ausgabe 11

Diese Sybit agile Ausgabe ist in zweierlei Hinsicht speziell: Zum einen ist sie größtenteils nicht in Köpfen von Sybit Mitarbeitern entstanden, sondern wir konnten gleich drei Gastautoren für Artikel gewinnen. Zum anderen erscheint sie begleitend zur ersten Agile Bodensee Konferenz. Beide Aspekte machen uns natürlich ein klein bisschen stolz und ich hoffe, dass sie wertvolle Anregungen aus jedem der Artikel mitnehmen können. Jurgen Appelo hat mit seinem Buch „Management 3.0“ für Furore in der Szene gesorgt. Ich muss gestehen, dass ich nach der Lektüre aufgrund der Fülle des Stoffs schon etwas erschlagen war. In sei-nem Artikel „Kudo Box“ beschreibt Jurgen eine ganz kon-krete Maßnahme, wie ein Belohnungssystem aussehen kann. Die Kollegen Alexander Birk und Christoph Lukas konnten uns schon in einem Agile Breakfast in Konstanz von Ihrer Idee einer Continuous Delivery Implementierung überzeugen. Wir haben uns gedacht, dass es sich lohnt, dieses Thema einem breiteren Publikum aufzudecken. Gut dazu passt auch der Artikel „DevOps“ meines Kollegen Thomas Wilhelm.

Und Vasco Duarte (er ist auch Mitorganisator der Agile Bodensee) bringt uns das Thema „Agile Innovation“ näher – spätestens seit Management 3.0 wissen wir, dass Agilität nicht nur in der Projektorganisation Sinn macht, sondern auch Organisation und Strategie/Innovation bereichern und zum Erfolg führen kann.

AUSGABE 11

Johannes HartmannsgruberJohannes Hartmannsgruber

3Sybit agile | Ausgabe 10

2001 wurde das amerikanische Energie- und Dienstleis-tungsunternehmen Enron insolvent, weil seinen Managern ihre Boni wichtiger waren als die Wahrheit. Sie motivierten sich selbst dazu, ihre Gehaltskonten zu maximieren, nicht aber den Unternehmenserfolg [Duarte, Resonate, S. 199]. Die Geschichte der Unternehmen ist übersät mit den Über-resten von Organisationen, die es zuließen, dass die Gier und das Ego von Einzelnen größer wurden als die Solvenz des Unternehmens.

Extrinsische MotivationBelohnungen gehören zu den schwierigsten und am wenigsten verstandenen Werkzeugen des Managements. Wenn sie aber richtig eingesetzt werden, können sie beeindruckende Ergebnisse bewirken. Leider gehen viele Manager von der Annahme aus, dass Geld die beste Wahl ist, um jemanden härter, länger oder effi zienter arbeiten zu lassen. Ebenso wird oft davon ausgegangen, dass eine solche extrinsische Motivation am besten wirkt, wenn sie in Form eines fi nanziellen Bonus realisiert wird. Beide Annahmen sind falsch.Die wissenschaftliche Forschung hat gezeigt, dass Ar-beitsanreize genau umgekehrt funktionieren. Die Erwar-tung einer Belohnung wirkt kontraproduktiv, da sie die innere Motivation zunichtemacht. Dieser Effekt wird als „Überrechtfertigung“ (overjustifi cation effect) bezeichnet [Kohn, Punished by Rewards, S. 320]. Ein weiteres Problem besteht darin, dass ergebnisabhängige Belohnungen das Risiko von Täuschungsversuchen erhöhen, da sich die Mit-arbeiter darauf konzentrieren, „eine Belohnung zu erhal-ten“, statt „gute Arbeit zu leisten“ [Fleming].

Intrinsische MotivationGlücklicherweise gibt es aber auch gute Nachrichten: Be-lohnungen, die die intrinsische Motivation auslösen, sind wirksamer und kosten deutlich weniger.Belohnungen können sich für Ihr Unternehmen auswirken, wenn Sie die folgenden sechs Regeln beachten:

1. Versprechen Sie Belohnungen nicht im Voraus. Ertei-len Sie Belohnungen zu einem unerwarteten Zeitpunkt, damit die Mitarbeiter nicht ihre Ziele ändern und sich auf die Belohnung konzentrieren. [Pink, Drive l:524].

2. Halten Sie erwartete Belohnungen klein. Wenn Sie nicht vermeiden können, dass Mitarbeiter eine mög-liche Belohnung erwarten, setzen Sie keine zu große Belohnung ein, da der mit der Erwartung verbundene Stress das Arbeitsgedächtnis der Mitarbeiter beein-trächtigt [Fleming].

3. Erteilen Sie Belohnungen kontinuierlich, nicht nur einmal. Wenn Mitarbeiter täglich gute Arbeit leisten, besteht jeden Tag Gelegenheit zu einer Belohnung [Mc-Crimmon, „Celebrating Success“].

4. Vergeben Sie Belohnungen öffentlich, nicht unter vier Augen. Ziel von Belohnungen ist es, dass gute Arbeit anerkannt wird – und auch, dass die Mitarbeiter sich darüber freuen können [Alberg, „Celebrate Success“].

5. Belohnen Sie Verhalten, nicht Ergebnisse. Wenn Sie das Augenmerk auf gutes Verhalten richten, lernen die Mitarbeiter, wie sie sich verhalten sollen. Wenn Sie sich auf gewünschte Ergebnisse konzentrieren, lernen sie möglicherweise zu täuschen [Fleming].

6. Belohnen Sie gleichgestellte, nicht untergeordnete Mitarbeiter. Gleichgestellte Mitarbeiter wissen oft besser als Führungskräfte, welche ihrer Kollegen ein Kompliment verdienen [Tynan, „Reward Employees“].

Kudo KastenJurgen Appelo, Autor: Management 3.0

Für die Belohnung von Mitarbeitern gibt es viele fal-sche Möglichkeiten. Ein einfacher, aber wirkungsvoller Ansatz ist das Aufstellen eines „Kudo-Kastens“, mit dem sich die Mitarbeiter gegenseitig kleine Belohnun-gen zukommen lassen können. Der Kudo-Kasten erfüllt die sechs Regeln für Belohnungen und funktioniert we-sentlich besser als jede Art von fi nanzieller Motivation.

tungsunternehmen Enron insolvent, weil seinen Managern ihre Boni wichtiger waren als die Wahrheit. Sie motivierten sich selbst dazu, ihre Gehaltskonten zu maximieren, nicht aber den Unternehmenserfolg [Duarte, Resonate, S. 199]. Die Geschichte der Unternehmen ist übersät mit den Über-

und das Ego von Einzelnen größer wurden als die Solvenz

beeindruckende Ergebnisse bewirken. Leider gehen viele Manager von der Annahme aus, dass Geld die beste Wahl 1. Versprechen Sie Belohnungen nicht im Voraus. Ertei-

sche Möglichkeiten. Ein einfacher, aber wirkungsvoller

dem sich die Mitarbeiter gegenseitig kleine Belohnun-gen zukommen lassen können. Der Kudo-Kasten erfüllt die sechs Regeln für Belohnungen und funktioniert we-sentlich besser als jede Art von fi nanzieller Motivation.

KudosPaul Klipp, President und Scrum-Trainer bei Lunar Logic Polska in Polen, erzählte mir, dass seine Mitarbeiter die Möglichkeit haben, jedem Kollegen ein Geschenk im Wert von 20 Euro zu machen. Diese Geschenke werden als Kudos bezeichnet und können in Form einer E-Mail an ein zent-rales Postfach oder durch Einwerfen einer Karte in einen Karton überreicht werden. Wenn jemand in der Firma das Gefühl hat, dass jemand anders ein Geschenk verdient hat, dann bekommt diese Person ein Geschenk – und alle erfahren davon.Wie Paul berichtet, funktioniert das Ganze hervorragend; und das Vertrauen wurde noch nie missbraucht.

Philip Rosedale, ehemaliger CEO von Linden Lab, entwi-ckelte ein ähnliches System namens LoveMachine [Mar-kowitz, „Make Employees Happy“] – ein Tool, mit dem Mitarbeiter ihren Kollegen kurze Anerkennungen zusenden konnten. Wie Rosedale berichtet, bewirkte die gegenseitige Anerkennung für die geleistete harte Arbeit allgemeine Zufriedenheit; und weil alle Vorgänge transparent abliefen, gewannen die Vorgesetzten wertvolle Einblicke, welche Mitarbeiter gute Leistungen erbrachten – und wer nie ein Kompliment erhielt.

LiteraturverzeichnisAlberg, Amy. „How to Celebrate Success throughout Your Projects“

<http://bit.ly/I94FWZ> Making Things Happen, 21. Mai 2008. Web, 23. Juli 2012.

Duarte, Nancy. Resonate: Present Visual Stories that Transform Au-diences. Hoboken, NJ: Wiley, 2010. Gedruckte Veröffentlichung.

Fleming, Nic. „The Bonus Myth: How Paying for Results Can Backfire“ <http://bit.ly/fK7uXJ> NewScientist, 12. April 2011. Web, 23. Juli 2012.

Kohn, Alfie. Punished by Rewards: The Trouble with Gold Stars, Incen-tive Plans, A's, Praise, and Other Bribes. Boston: Houghton Mifflin Co, 1993. Gedruckte Veröffentlichung.

Markowitz, Eric. „3 Weird, Game-Changing Ways to Make Employees Happy“ <http://bit.ly/Jqa1fj> Inc.com, 11. Mai 2012. Web, 23. Juli 2012.

McCrimmon, Mitch. „Celebrating Success at Work“ <http://bit.ly/N1XLrP> Business Management @ Suite101, 9. April 2008. Web, 23. Juli 2012.

Pink, Daniel. Drive: The Surprising Truth about What Motivates Us. New York, NY: Riverhead Books, 2009. Gedruckte Veröffentlichung.

Tynan, Dan. „25 Ways to Reward Employees (Without Spending a Dime)“ <http://bit.ly/XAdfV> HR World, 2007. Web, 23. Juli 2012.

4

ZUM AUTOR

Sybit agile | Ausgabe 11

Anerkennungskarten, die bei der Konferenz Agile Lean Europe 2011 zum Einsatz kamen (Foto: Corinna Baldauf, www.finding-marbles.com, Verwendung mit Genehmigung)

Jurgen Appelo ist Verfasser des Buchs Management 3.0, das die Rol-le des Managers in agilen Organi-sationen beschreibt, sowie von How to Change the World, einem Modell für organisatorische Veränderung. Dieser Beitrag wird in das 2013 erscheinende Buch Management Workout einfließen. Jurgen Appe-lo ist außerdem Verfasser des in vielen Ländern erhältlichen Kurses Management 3.0.

Ausführlichere Informationen über die Bücher und den Kurs erhalten Sie unter www.management30.com

Jurgen Appelo


Das ProblemAllzu oft wurde und wird dem Betrieb der Software während der Entwicklungsphase immer noch zu wenig oder keine Aufmerksamkeit geschenkt. Nichtfunktionale Anforderungen an Sicherheit, Skalierbarkeit, Monitoring und Rollout der entwickelten Lösung werden vom Entwicklungsteam igno-riert und auf den IT-Betrieb abgeschoben. Das Team liefert zwar mit jedem Release neue funktionale Features, bis diese aber tatsächlich produktiv genutzt werden können, ist häufi g schon der nächste Sprint beendet. An der Schnittstelle zwischen Entwicklung und Betrieb herrscht oft gegenseitiges Unverständnis für die Probleme

und Prioritäten der Gegenseite. Auf der einen Seite ist das agile Entwicklungsteam stetig bemüht, die Anzahl der gelieferten Features, d.h. auch die Anzahl der Änderungen am Softwareprodukt zu erhöhen. Auf der anderen Seite hat der IT-Betrieb, der letztendlich die Verantwortung für Stabilität und Sicherheit der Anwendung trägt, das Bestre-ben, möglichst wenige Änderungen zuzulassen, um einen stabilen Betrieb der Anwendung zu gewährleisten. Zusätzlich ergeben sich aus dem anhaltenden Trend zur Virtualisierung und dem verteilten Deployment von An-wendungen neue Herausforderungen für den Betrieb von Software. Cloud-Deployments und Verteilung in virtuellen

DevOps - Agilität weiter gedachtThomas Wilhelm, Product Owner, Sybit GmbH

DevOps - Agilität weiter gedacht

Viel hat man in letzter Zeit über "DevOps" lesen können. Die noch recht junge Bewegung fand ihren Namen mit den ersten "DevOpsDays", die Patrick Debois[1] 2009 in Belgien organisierte. Seither hat sich der Begriff "DevOps" rasant verbreitet und seinen festen Platz in der agilen Bewegung gesichert. Doch was verbirgt sich hinter dem Begriff? Wo-her kommen seine Anhänger und was bedeutet "DevOps" für die tägliche Arbeit in der Softwareentwicklung?

Schaut man zurück auf die ersten DevOpsDays, so fi nden sich Themen wie • "Cucumber-nagios … rethinking monitoring for the cloud", • "Non-Functional Requirements: do user stories help?", • "Introducing Kanban in operations", • "Continuous Integration, Pipelines and Deployment" Diese wurden mehrheitlich von Sprechern aus dem IT-Operations-Umfeld präsentiert. Es ging also um die Frage, wie sich agile Methoden und Ideen auf IT-Betrieb und Qualitätssicherung der entwickelten Software auswirken.


Maschinen können und sollten nicht erst beim Rollout der Software Beachtung finden, sondern müssen von Anfang an bei der Architektur der Anwendung berücksichtig und getestet werden. Hier genau setzen die Ideen der DevOps-Bewegung an, in-dem sie zum einen versucht, agile Methoden ins Lager der IT-Operations zu tragen, sowie andererseits Entwickler für Betriebsthemen zu sensibilisieren. Die vielbeschriebene „Time-To-Market“ kann letztendlich nur dann erfolgreich verkürzt werden, wenn entwickelte Features kontinuier-lich ausgerollt werden können, ohne dabei die Sicherheit, Stabilität und Qualität der Lösung zu gefährden.

Drei Ziele

ZusammenarbeitDie enge Zusammenarbeit zwischen Entwicklung und IT-Betrieb ist also ein zentrales Anliegen der DevOps Bewe-gung. Nicht zuletzt sollen Veranstaltungen wie die DevOps-Days neben dem gegenseitigen Verständnis auch dazu dienen, den Austausch zwischen Dev und Ops zu fördern. Für die Projektarbeit bedeutet dies nicht zwangsläufig, dass jedes Entwicklungsteam einen Betriebsexperten in seinen Reihen braucht. Vielmehr ist es wichtig, die aus Be-triebssicht wichtigen Anforderungen von Anfang an bei der Planung der Stories zu beachten und schon mit der ersten Iteration auch den Rollout bis zum Produktionssystem als Teil der erfolgreichen Umsetzung anzusehen. Spätestens hier wird das Entwicklungsteam zumindest punktuell einen erfahrenen "Betriebsmann" brauchen, der einerseits ein grundlegendes Verständnis für den Betrieb der Software, andererseits aber auch ein Verständnis für die Methoden und Werte der agilen Softwareentwicklung mitbringt.

AutomatisierungDer komplette Rolloutprozess wird somit als Teil des Entwicklungsprozesses etabliert und kontinuierlich auf-gebaut und verbessert. Von der "Continuous Integration", die mittlerweile zum Grundsetup eines Softwareprojektes zählt, bewegen wir uns zur "Continuous Delivery". Dabei ist

das Ziel die vollständige Automatisierung des Rollout, ohne jedoch Stabilität und Qualität der Software zu gefährden. Mittlerweile hat sich eine ganze Reihe von Tools etabliert, die bei der Automatisierung des Rollout und den Regressi-onstests unterstützen und diese nahtlos in den Software-entwicklungsprozess einbinden. Im Idealfall können neue Features somit direkt nach der Fertigstellung und Freigabe ohne manuellen Aufwand im produktiven System aus-gerollt werden. Regelmäßige "große" Releases, welchen mehrwöchige Optimierungs- und Testphasen vorausge-hen, werden durch den automatisierten Rollout einzelner Features ersetzt. Natürlich ist dies nicht in jedem Kontext ohne weitere qualitätssichernde Maßnahmen möglich.

ProzesseDie Diskussion über diese wichtigen Prozesse zu führen und daraus Best-Practices und Empfehlungen abzuleiten, ist ein weiteres Anliegen der DevOps-Bewegung. Schaut man sich die Vielzahl der heute eingesetzten Entwick-lungsplattformen und Anwendungsbereiche von Software an, so ist es nicht verwunderlich, dass hier die Vorstel-lungen und Ideen noch weit auseinandergehen. Von einer einheitlichen Sicht auf typische DevOps-Prozesse und deren Einführung sind wir daher sicher noch weit entfernt. Alleine die Tatsache, dass die Diskussion geführt wird


und das Thema in den Fokus agiler Softwareentwicklung gerückt ist, ist jedoch ein großer Erfolg der DevOps-Bewe-gung. Einen interessanten Ansatz zur Strukturierung von DevOps-Praktiken stellt Patric Debois auf seinem Blog zur Diskussion[2]. Er schlägt darin ein Vorgehen zur struktu-rierten Erfassung von gängigen DevOps-Praktiken vor.

DevOps in der Praxis

Motiviert durch den Wunsch entwickelte Software schnel-ler auszuliefern, stellen sich die typischen Fragen und Pro-blemstellung, welche die DevOps-Bewegung versucht zu adressieren. Zum Beispiel: Wie kann eine Continous Deli-very Pipeline eingeführt werden? Um das Ziel der vollauto-matischen Auslieferung von Softwarepaketen zu erreichen, ist - wie oben aufgezeigt - eine enge Zusammenarbeit zwi-schen Entwicklung und Betrieb unabdingbar. Für das Setup von Systemen und den Rollout sind mittlerweile sehr gute Tools vorhanden und es gibt viele Projekte die Continuous Delivery erfolgreich umgesetzt haben[3]. Scheut man den initialen Aufwand zum Aufsetzen der Continuous Delivery Pipeline und die Anschaffung der nötigen Rechenpower nicht, so steht dem vollautomatischen Rollout technisch nichts im Wege.

Die Herausforderungen liegen in der Praxis im Zwischen-menschlichen und Organisatorischen. In der Abstimmung zwischen Entwicklung und Betrieb muss ein Umdenken vollzogen werden: weg von "Das ist aber in der Verant-wortung des Betriebs" hin zu "Wie bekommen wir als EIN Team unsere Software schneller vom Entwickler zum Kun-den". Dabei hilft auch keine noch so gute Prozessbeschrei-bung sondern nur, sich an einen Tisch zu setzen, und eine für beide Seiten gute Lösung gemeinsam zu erarbeiten.

Ein Thema, das in der Diskussion zu DevOps oft stief-mütterlich behandelt wird, ist die Qualitätssicherung der ausgelieferten Software. Denn allein mit der vollautoma-tischen Auslieferung von Artefakten ist es natürlich nicht getan. Das Vorhandensein von Unit-Tests sollte mittler-weile selbstverständlich sein. Darüber hinaus müssen aber möglichst vollständige System- und ggf. Lasttests automatisch durchgeführt werden, um dem Entwickler eine aussagekräftige Rückmeldung zur Qualität seiner Änderungen zu geben. Gerade für den Test komplexer Webanwendungen entstehen hier erfahrungsgemäß

häufig nicht unerhebliche Aufwände für die Erstellung und vor allem Wartung der Tests. Alle vom System benötigten Daten und externen Schnittstellen müssen außerdem für die Tests absolut stabil sein. Dies bedeutet in der Pra-xis, dass man das System für die Tests mit geeigneten Testdaten initialisieren und diese nach jedem Test auch zurücksetzen muss. Externe Schnittstellen müssen in den meisten Fällen durch eigene „Mock“-Implementierung ersetzen werden, um die Reproduzierbarkeit der Tests zu gewährleisten. Für die eigene Umsetzung empfiehlt sich in der Praxis ein pragmatisches Vorgehen getreu dem Motto „Teste so viel wie nötig aber so wenig wie möglich“. Hier ist Finger-spitzengefühl gefragt, um einerseits ein schnelles und aussagekräftiges Feedback zur Qualität des Systems zu generieren und andererseits die Aufwände für die Pflege der automatischen Tests im Rahmen zu halten. ZukunftNeben der konkreten Anwendung von DevOps-Praktiken und -Tools wird das Thema von einigen seiner Protagonis-ten mittlerweile in einem weit größeren Kontext disku-tiert. So plädiert Patrice Debois auf seinem Blog[4] dafür, die Ziele und Ideen neben Entwicklung und Betrieb auch auf andere Unternehmensbereiche zu übertragen. Auch Damon Edwards zielt mit seinem Blogbeitrag "DevOps is not a technology problem. DevOps is a business problem." [5] in die gleiche Richtung. Geht es bei DevOps also doch um mehr als die optimale Integration von Entwicklungs- und Betriebsprozessen? Man darf gespannt sein, welche Richtung die Diskussion hier in Zukunft noch nehmen wird. Im Moment haben wir im Projektalltag sicher genügend zu tun, um „Continuous Delivery“ Realität werden zulassen und dabei gleichzeitig Qualität und Budget im Zaum zu halten.

Quellenverzeichnis[1] http://devopsdays.org/events/2009-ghent

[2] www.jedi.be/blog/2012/05/12/codifying-devops-area-practices

[3] http://blog.sybit.de/2012/07/continuous-delivery

[4] www.jedi.be/blog/2012/05/12/codifying-devops-area-practices

[5] http://dev2ops.org/blog/2010/11/7/devops-is-not-a-technology-

problem-devops-is-a-business-prob.html

ZUM AUTORThomas Wilhelm ist Projektleiter und Product Owner bei der Sybit GmbH. Als Certified Scrum Product Owner hat er Erfahrung in Soft-warearchitekturen und Entwicklung von webbasierten und verteilten Anwendungen. Mit agilen Metho-den bringt er die Kundenprojekte zuverlässig in Time und in Budget ans Ziel.Thomas Wilhelm


Introducing Continuous Delivery

Softwareentwicklung in klassischen Releasezyklen folgt häufi g dem folgenden Schema: Nach einer intensiven Pla-nungsphase wird die Software isoliert im “stillen Kämmer-lein” entwickelt, sporadisch integriert und nach Abschluss der Entwicklung in einer länglichen Testphase geprüft. Die gefundenen Bugs werden gefi xt um schlussendlich irgend-wann ein Release zu erhalten. Dieses Release wird dann kurz vor geplantem Projektende zum ersten Mal ernst-

haft auf der Produktionsumgebung deployed. Bei diesem Vorgehen liegt ein hohes Risiko gerade in der seltenen Integration und dem späten Deployment. Daher ist die grundsätzliche Idee hinter Continuous Delivery:Jeder Commit produziert ein potentielles Release der Software.Alle Schritte, die oben beschrieben sind, werden dabei voll automatisiert mit jedem Commit durchgeführt. Technisch baut man dazu eine sogenannte Build Pipeline aus mehre-ren Stufen auf:

In Zeiten immer kürzerer Produktzyklen sollen neue Features nicht mehr im Zeitrahmen von Monaten son-dern innerhalb weniger Wochen oder Tage beim Kunden ankommen. Gleichzeitig darf man sich keine Abstriche in der gelieferten Qualität leisten und muß die Software

vor jedem Release ausgiebig testen. Diesen scheinbaren Widerspruch zwischen 'wir wollen alle zwei Wochen live gehen' und 'wir brauchen eine umfangreichere Testpha-se' kann man nur mit Techniken wie Continuous Delivery aufl ösen.

Introducing Continuous DeliveryChristoph Lukas & Alexander Birk, pingworks

Introducing Continuous Delivery


Jeder Commit triggert einen kompletten Build-Prozess und läuft schrittweise von links nach rechts durch die oben abgebildete Pipeline.

1st StageIn der sogenannten 1st Stage oder Commit Stage werden die Komponenten der Anwendung kompiliert und alle Unittests ausgeführt. Ist beides erfolgreich, werden die Binärartefakte der Anwendung paketiert. Für den weiteren Durchlauf durch die Pipeline und alle weiteren Tests wer-den jetzt diese Pakete genutzt. Waren diese Schritte erfolg-reich, werden die Binärpakete der 2nd Stage übergeben.

2nd StageIn der 2nd Stage werden die Pakete Integrationstests unterzogen. Hier findet also bereits die Integration der Komponenten der Anwendung statt. Seiteneffekte sollten eigentlich spätestens hier auffallen. Und diese Integrati-on passiert nicht einmal pro Sprint, nicht einmal am Tag, sondern mit jedem einzelnen Commit, so dass man solche Seiteneffekte einem einzelnen Commit zuordnen kann. Sind auch die Integrationstests erfolgreich, werden die Binärpakete zur 3rd Stage weitergereicht.

3rd StageIn der 3rd Stage werden die Systemtests mit den Paketen durchgeführt. Dies können bei Webanwendungen z.B. Seleniumtests sein. Haben die Pakete auch diese dritte auto-matische Teststufe passiert, können weitere manuelle Testschritte folgen und bei Erfolg die Pakete zu einem echten Release werden.

Vertrauen in die Qualität des BuildsDie aus einem Commit erzeugten Pakete werden jeweils nur dann in die nächste Stage weitergereicht, wenn die je-weiligen Tests erfolgreich waren. Je weiter also die Pakete aus einem Commit in der Pipeline gekommen sind, desto höher wird das Vertrauen in die Qualität dieser Pakete.

Produktionsnahe UmgebungenZugleich werden die Systeme, auf denen die jeweiligen

Tests durchgeführt werden, immer produktionsnäher, so dass man mit dem Durchlauf der Pakete durch die Pipe-line auch ein immer realistischeres Deployment und einen immer realistischeren Betrieb der Software testet.

FeedbackWährend die Pakete durch die Pipeline laufen, bekommt der Entwickler kontinuierlich Feedback über die Qualität seines Commits. Die Ergebnisse aus der 1st Stage sollten dabei bereits in unter 10 min vorliegen, da sonst die Gefahr besteht, dass die Entwickler sich längst anderen Aufgaben zugewandt haben, bevor die Unittests fertig sind.

Buildpipeline im DetailWill man eine solche Buildpipeline umsetzen, so kann man dazu einen Continuous Integration Server wie z.B. Jenkins einsetzen. Mit einem solchen Server können viele ver-schiedene Build Schritte vom einfachen Bau der Software bis hin zum Aufruf von externen Programmen abgebildet werden.

Das obige Bild zeigt die Pipeline noch einmal mit etwas mehr Detailtiefe:Die Entwickler committen eine Änderung in das zentrale Source-Code-Repository, von dort wird automatisch die Build Pipeline getriggert.In der 1st Stage aktualisiert Jenkins den Softwarestand aus dem Sourcecode Repository, kompiliert die Kompo-nenten und führt alle Unittests aus.Bei erfolgreicher 1st Stage wird die Anwendung paketiert,


die Binärpakete werden dann in einem zentralen Reposito-ry abgelegt. Von dort bedienen sich alle folgenden Schritte in der Pipeline und nutzen exakt diese in der 1st Stage erstellen Binärpakete für die weiteren Tests.Wird nach erfolgreicher 1st Stage für einen Commit die 2nd Stage getriggert, so werden die Binärpakete vom Jen-kins aus dem Repository geholt, auf eine Testumgebung deployed, die Anwendung dort konfiguriert und danach auf dieser Umgebung die Integrationstests gestartet.Sind auch die Tests der 2nd Stage erfolgreich, so wird das gleich Prozedere für die 3rd Stage durchgeführt. Der Jen-kins holt die entsprechenden Binärpakete aus dem Repo-sitory, deployed diese auf eine Umgebung für Systemtests, konfiguriert die Anwendung und lässt dort die Systemtests laufen.Aus diesem Repository können beliebige Stände der Anwendung manuell auch auf weitere Testumgebungen (Staging, …) oder Entwicklersysteme deployed werden.

Bevor es losgeht

Damit man eine Build Pipeline für Continuous Delivery Umsetzen kann, müssen ein paar Voraussetzungen erfüllt sein.

Continuous Delivery braucht Continuous IntegrationOhne kontinuierliche Integration der Anwendung macht Continuous Delivery nicht viel Sinn. Elementare Idee hinter Continuous Delivery ist, alle Komponenten der Anwendung bereits mit jedem Commit zu testen und zu integrieren. Dazu gehören nicht nur Unittests sondern eben auch Integ-rations- und Systemtests.

Continuous Delivery braucht automatisierte TestsEigentlich klar, oder? Alle Tests müssen automatisch mit jedem Commit ausgeführt werden können. Das schließt allerdings auch Dinge wie die Vorbereitung der Testdaten mit ein!

Continuous Delivery braucht Configuration ManagementDie Anwendung muss schon in der 2nd Stage mit jedem Commit unter Umständen mehrfach automatisch auf

Testsystemen deployed werden. Aber die wenigsten An-wendungen werden dann ohne Eingriff in die Konfiguration gleich funktionieren. Dazu ist zwingend ein entsprechendes Tooling notwendig, um automatisch eine passende Konfi-guration für die Anwendung generieren zu können. Wo-möglich unterschiedlich, je nachdem, welche Komponente man gerade testen will.

Continuous Delivery braucht DevOps ThinkingDer Gedanke von “Everybody is responsible for delivery” muss letztlich bei allen Entwicklern ankommen, wenn man Continuous Delivery implementieren möchte. Das Deploy-ment der Anwendung rückt durch Continuous Delivery sehr nah an die eigentliche Entwicklungstätigkeit heran. Nehmen die Entwickler diese Verantwortung nicht an, kann Continuous Delivery nicht funktionieren. Eine ausführliche-re Betrachtung dazu liefert Thomas Wilhelm in 'DevOps - Agilität weiter gedacht' in dieser Ausgabe.

Konkrete Implementationsschritte

Bei der eigentlichen Implementierung von Continuous Delivery sind häufig die folgenden konkreten Aufgaben zu lösen:

• Standardisierung der Testumgebungen• Standardisierung des Deployments• Standardisierung der Konfiguration• Aufbau der Build Pipeline

Diese Schritte kann man allerdings nicht sequentiell abar-beiten, sondern eher in vielen Iterationen “gleichzeitig”.

TestumgebungenFür Continuous Delivery benötigt man eine flexible Zahl von Testumgebungen. Hier ist der Einsatz von Virtualisie-rung unumgänglich, da man mit physikalischen Maschinen schlicht zu unflexibel und zu langsam ist.

Alle Testumgebungen müssen aus Sicht der Anwendung (nahezu) identisch ausssehen. So vereinfacht es das De-ployment beispielsweise erheblich, wenn z.B. die REST-Schnittstelle der Businesslogik immer unter dem gleichen Hostnamen erreichbar ist.

Testumgebungen müssen sich schnell und unkompliziert erzeugen lassen. Um das zu erreichen, sollte man Techni-ken wie gescriptetes Cloning und Setup der Umgebungen einsetzen.

DeploymentAuf die so standardisierten Testumgebungen kann man dann in immer der gleichen Art und Weise die Anwendung deployen.

Dazu sollte die Anwendung einen einfachen Installer erhalten, der die immer wiederkehrenden Aufgaben beim


Deployment (Installation, Konfiguration, Restart von Kom-ponenten) auf die immer gleiche Weise durchführen kann.

Infrastructure as CodeGrundsätzlich sollten alle für den Betrieb der Anwendung nötigen Infrastrukturen, wie z.B. Definition von Testsyste-men, Installer, Konfigurationstooling auch als Code aufge-fasst und genauso behandelt werden.

Hürden bei der ImplementationBei der Umsetzung von Continuous Delivery sind allerdings auch einige Hürden zu überwinden.

Spätestens wenn man automatisiert Testumgebungen clonen und konfigurieren will und damit z.B. vollen Zugriff auf einen firmeneigenen Virtualisierungs-Server braucht, wird man damit konfrontiert, den Graben zwischen Deve-lopment und Operations zuschütten zu müssen. Man muss auf beiden Seiten für die Interessen der Anderen werben, damit man solche Techniken einsetzen kann.

Wenn man die Vorteile von Continuous Delivery dauer-haft nutzen will, kann das nur dann gehen, wenn sich alle Entwickler auch für die Delivery verantwortlich fühlen. Die beste Build-Pipeline kann nur dann wertvolles Feadback liefern, wenn fehlschlagende Tests oder fehlschlagende Deployments auch von den Entwicklern zeitnah angegan-gen werden.

Leider gibt es Continuous Delivery auch nicht ganz um-sonst. Die Entwickler lassen sich schnell von der Vorteilen überzeugen: Wer erstellt schon gerne Testprotokolle von Hand oder verbringt Stunden mit der Konfiguration des Testsystems. Beim Management ist die Hürde etwas höher. Wenn man allerdings den Aufwand für das manuelle Tes-ten, Deployment und die Delivery ehrlich aufrechnet und dazu die messbar höhere Qualität der Software ins Feld führt, wird sehr schnell ersichtlich, dass das Geld hier gut investiert ist.

GewinnUnd ist es jetzt auch wirklich die Sache wert? Was lässt sich damit gewinnen?

• Die Software wird tagtäglich zig mal deployed. Das Deployment wird also kontinuierlich mit getestet. Überraschungen beim Deployment der Software in der Produktivumgebung sollten damit der Vergangenheit angehören.

• Die Konfiguration der Software ist unter Kontrolle, auch auf dem Produktivsystem. Damit sollte sich das häss-liche Ping-Pong zwischen Entwicklern und Operations wegen fehlerhafter Konfiguration vermeiden lassen.

• Die Software hat insgesamt deutlich weniger Fehler. Decken die Tests einen wesentlichen Teil der Funktio-nalität ab und testen sie nicht immer nur den einfachs-ten Positivfall, kommt dies der Qualität der Software deutlich zu Gute.

• Den Entwicklern bleibt mehr Zeit für die Entwicklung von Features, da der manuelle Build, das Deployment und die Konfiguration der Software entfällt.

Ausblick

Leider ist Continuous Delivery kein Produkt, das man zu der Entwicklung einfach so dazu kaufen kann. Die Imple-mentation von Continuous Delivery ist sehr projektspezi-fisch und erfordert vor allem und in vielerlei Hinsicht ein Umdenken aller Beteiligten. Aber jeder, der den Schritt von Softwareentwicklung ohne Tests zu Continuous Integration schonmal gemacht hat, kennt den Effekt: Einmal gemacht will man nie mehr ohne.

ZU DEN AUTORENUnter dem Namen pingworks beschäftigen sich Christoph Lukas und Alexander Birk bereits seit 1998 mit der Entwicklung von Webapplikationen. Getrieben durch Ihre technische Neugier, vor allem für offene Standards, Frameworks und Betriebssyste-me, haben sie in vielen Projekten als Entwickler, Architekten und zuletzt immer auch als agile Men-toren mitgearbeitet. Insofern wundert es nicht, dass sie derzeit die Herausforderung “Continuous Delivery” besonders spannend finden: Lean/Agile Mind-set, übergreifende Kommunikation und breites technisches Know-how werden hier gleichermaßen gefordert. www.pingworks.de

Christoph Lukas

Alexander Birk


Wie können wir uns diesen Herausforderungen stellen?

Langsame Prozesse schaden der Wettbewerbsfähigkeit und…Wir könnten vermutlich schneller sein – deutlich schneller als heute. Wenn Experten die Arbeitsweise in einem durch-schnittlichen Unternehmen untersuchen, werden sie in der Regel feststellen, dass ein großer, sogar ein sehr großer Teil der in diesen Unternehmen geleisteten Arbeit schlicht-weg verschwendet ist. Diese Arbeit leisten wir zwar, aber sie erbringt keinerlei Wert für unsere Kunden. Das ist ein ernstes Problem, denn alles, was wir tun, erhöht die Kos-ten unserer Produkte und Dienstleistungen. Wenn unsere Arbeit keinen Mehrwert erbringt, so geben wir im Prinzip Geld aus, das wir niemals zurückbekommen können. Kein Mehrwert! Viele Beratungsfi rmen beziffern das Verhältnis zwischen wertschöpfender und verschwendeter Zeit mit

ca. 1–5 %. Das heißt, 95–99 % werden verschwendet!Ein weiteres wichtiges Ergebnis besteht darin, dass lang-same Prozesse in der Regel mit niedrigerer Qualität ver-bunden sind. Das leuchtet ein, denn je kürzer ein Prozess ist, desto weniger Fehler können wir uns dabei leisten. Wenn wir viele Fehler machen, wird der Prozess lang-samer, beispielsweise weil eine umfangreiche Prüf- und Testphase am Ende des Projekts erforderlich ist.Es gibt aber auch gute Nachrichten. Wenn langsame Prozesse verschwendete Zeit enthalten, dann tragen wir, indem wir uns um eine Beschleunigung dieser Prozesse bemühen, zwangsläufi g zur Qualitätsverbesserung und Kostenreduzierung bei. Niedrigere Kosten sind also eine Konsequenz schnellerer, hochwertigerer Prozesse.

Fall I: Auftragsabwicklungsprozess einer Softwarefi rmaDas folgende Beispiel ist eine Wertstromanalyse (Value

Agile Innovation – Produktmanagement in turbulenten ZeitenVasco Duarte, Agile Coach, Avira

Agile Innovation – Produktmanagement in turbulenten Zeiten

Ständig hören wir heute, dass uns der Wettbewerb auf den Fersen sitzt, dass der Markt und das Umfeld sich verändern und dass auch wir uns entsprechend verändern müssen. Vor allem aber wird uns gesagt, dass wir auf unsere Kunden hören müssen, um ihnen die richtigen Produkte liefern zu können. Wir als Produktmanager müssen über die grundlegenden Produktentscheidungen (z. B. „Erweitern wir Funktion A oder Funktion B?“) hinausblicken können. Wir müssen weiter denken als bis zum „Tellerrand“ unserer Aufgabe.Das Problem dabei ist: Wir müssen• wissen, was als Nächstes geschieht, damit wir besser

als unsere Wettbewerber sein können;• erkennen, welche Prozesse zu langsam ablaufen, da-

mit wir sie beschleunigen und uns am Markt gegen die Konkurrenz durchsetzen können;

• sondieren, was praktikabel ist, damit wir das richti-ge Produkt und den richtigen Produktmix für unsere Kunden fi nden können.

All dies wäre möglich, wenn wir schnell lernen und uns anpassen könnten – unter anderem mithilfe von Kunden-feedback und schnelleren Prozessen. Die Frage, die wir uns stellen müssen, lautet also: Wie können wir das erreichen? Wie können wir lernen, zu lernen? Wie können wir – als Produktmanager – zur Fortentwick-lung unserer Organisation beitragen, um durch Lernen und Anpassung an neue Bedingungen zu verbessern? Nur durch diese Fähigkeit zum Lernen und zur schnel-len Anpassung können wir schneller werden, indem wir unsere Prozesse verschlanken und nur die Arbeit leisten, die wirklich nötig ist. Auf diese Probleme möchte ich in meinem Beitrag eingehen.


Stream Map)[1], die bei der Analyse einer Auftragsabwick-lung in einer Softwarefirma erstellt wurde.

Aus Sicht des Kunden hat sich dieses Unternehmen 6385 Minuten lang mit Aufgaben beschäftigt, die keinen Mehr-wert für das Endprodukt geschaffen haben, und dagegen nur 116 Minuten lang Arbeiten geleistet, für die der Kunde zu zahlen bereit war. Das Verhältnis von wertschöpfender zu verschwendeter Zeit betrug bei diesem Vorgang insge-samt 1,8 %; das heißt, aus Kundensicht waren 98,2 % der aufgewendeten Zeit verschwendet. Der entscheidende Aspekt ist hier, dass ein Prozess immer nur mit einer begrenzten Menge von Wert ausgestattet werden kann, dass aber die mögliche Menge der ver-schwendeten Zeit unbegrenzt ist. Mehr verschwendete Zeit steigert die Kosten des Produkts, ohne seinen Wert zu er-höhen, und bewirkt für unsere Unternehmen einen erheb-lichen Wettbewerbsnachteil gegenüber der Konkurrenz.Wir konnten zwar nicht die gesamte bei dieser Analyse ermittelte Zeitverschwendung eliminieren, aber einen Teil davon durchaus. Außerdem wussten wir, welche langfristi-gen Veränderungen erforderlich waren, um einen deutlich schlankeren Prozess mit weniger Verschwendung zu errei-chen. Dieses Verfahren wird als „Wertstromanalyse“ (Value Stream Mapping)[1] bezeichnet und lässt sich auf jeden Pro-zess anwenden. Dabei ist jedoch Folgendes zu beachten:• Eine Wertstromanalyse muss den kompletten Prozess

(von der Idee bis zum Produkt) abdecken. Wenn wir die entscheidenden Schritte nicht in den Prozess einbeziehen, laufen wir Gefahr, einen Teil des Prozesses zu optimieren, der nicht zur Verbesserung unserer Organisation beiträgt.

Als Produktmanager befinden wir uns in einer Schlüssel-position zur Verbesserung der Prozesse unseres Unter-nehmens. Wenn wir unser F&E-Portfolio immer nur durch neue Projekte erweitern, aber keine Zeit für Verbesserun-

gen reservieren, sind immer langsamere Prozesse das einzige Ergebnis (Littles Gesetz[2]). Die Beschleunigung unserer Prozesse und die Reduzierung der noch nicht ab-geschlossenen Arbeit ist SCHRITT 1 unserer Bemühungen, unsere Wettbewerbsfähigkeit zu verbessern.

Arbeiten Sie mit dem Kunden zusammen, um Ihre Produkte besser kennenzulernenDie Ermittlung und Eliminierung von Verschwendung ist eines der wichtigsten Hilfsmittel des „Verschlankungsan-satzes“ (Lean approach) für kontinuierliche Verbesserung. Durch gute Ergebnisse bei der Eliminierung von Ver-schwendung können wir allerdings nur schneller werden. Darüber hinaus müssen wir noch herausfinden, wie wir das Richtige tun und unsere Kunden durch eindrucksvolle Leistungen oder Services überzeugen können. Einer der Eckpfeiler der „agilen“ Softwareentwicklung[3] ist Feedback, und zwar insbesondere Kundenfeedback. Auch hier befinden sich die Produktmanager wieder in einer Schlüsselposition, um ihren Unternehmen zu helfen, sich zu verbessern. Unser erstes Augenmerk sollte darauf gerichtet sein, nicht mehr mit langfristigen Roadmaps zu arbeiten, die keinen Verhandlungsspielraum lassen. Es ist eine Tatsache, die wir akzeptieren müssen: Wir können nicht vorhersagen, was in ein, zwei oder drei Jahren von Bedeutung sein wird; und wenn wir versuchen, solche Vor-aussagen zu machen und unsere Roadmaps entsprechend langfristig festzulegen, ist die Wahrscheinlichkeit groß, dass ein wendigerer Mitbewerber unseren Innovations-prozess überholt und uns insgesamt aus dem Geschäft verdrängt. Erinnern wir uns: Giganten wie Yahoo! folgen mittlerweile in großem Abstand hinter den Wettbewerbern, denen es gelungen ist, die Innovationsgeschwindigkeit ihrer Produkte deutlich zu erhöhen (z. B. Facebook, Google usw.)Wenn wir akzeptiert haben, dass langfristige Roadmaps ohne Verhandlungsspielraum keine kluge Wahl sind, dann lautet die nächste Frage: Wie kann das funktionieren? Was sagen wir dem Kunden in der Besprechung über ein kom-mendes Produkt, wenn wir keine Roadmap haben? Das sind wichtige Einwände; zunächst müssen wir uns aber eingestehen, dass wir den zukünftigen Bedarf schlichtweg nicht kennen. Wenn uns ein Kunde fragt: „Welche Relea-ses/Produkte/Services bekomme ich nächstes Jahr?“, verschafft uns das eine hervorragende Gelegenheit, Infor-mationen von diesem Kunden zu erhalten. Fragen wir doch einfach zurück: „Was wäre denn aus Ihrer Sicht in einem Jahr für Ihr Geschäft wichtig?“Auf diese Weise entsteht ein dringend erforderlicher Dialog mit dem Kunden, der uns einen entscheidenden Vertriebs-vorteil verschafft: Wir haben unseren Kunden nämlich so-eben dazu gebracht, sich schon teilweise auf unser Produkt festzulegen, indem er uns mitgeteilt hat, was er in einem Jahr benötigen wird!Unsere Herausforderung besteht also darin zu verstehen, wie wir die langfristige Entwicklung unserer Produkte handhaben können, ohne die langfristigen Roadmaps zu strikt festzuschreiben.Als Produktmanager müssen wir uns überlegen, was für unser Geschäft von Bedeutung ist, und wir benötigen eine

Vorgang Wertschöpfende Zeit (in Min.)

Verschwendete Zeit (in Min.)

Partner erteilt einen Auftrag (100 CDs)

5 Min. 0 Min.

Auftrag wird in das hausinterne System eingetragen

1 Min. 10 Min.

Auftrag wird in der Fabrik registriert

0 Min. 5 Min.

Auftrag ruht bis zum Erreichen der Mindestlosgröße (z. B. 1000)

0 Min. ~2 Tage (2880 Min.)

Auftragskarton wird angefertigt

1 Min. x Anzahl CDs = 100 Min.

5 Min. x Anzahl CDs = 500 Min.

Versandpaket für den Auftrag wird angefertigt

0 Min. 10 Min.

Versandpakete für alle Aufträge werden angefertigt

5 Min. 50 Min. (im Mittel jeder 10. Auftrag)

Paketversand 5 Min. 50 Min. (im Mittel jeder 10. Auftrag)


Vorstellung davon, was unser Geschäft seinen Kunden bieten soll; wenn wir uns aber durch langfristige Roadmaps ohne Verhandlungsspielraum selbst die Hände binden, ist das offenbar nicht die beste Vorgehensweise.

Fall II:Flexible Anforderungen bei großen SoftwareprogrammenBei einem unserer größten Programme haben wir eine Tech-nik eingesetzt, mit der wir unsere Anforderungen flexibel gestalten konnten, obwohl wir unseren Entwicklungsteams sehr genaue Langzeitvorgaben machten (die sie z. B. für Qualifizierungszwecke benötigten). Wie war das möglich?Wir verwendeten bei der Festlegung der Anforderungen einen Drei-Ebenen-Ansatz, wobei jede Anforderungsebene im Zuständigkeitsbereich einer anderen Rolle innerhalb der Organisation lag und eine jeweils unterschiedliche Abstraktionsstufe aufwies. Auf diese Weise konnten wir umfangreiche Funktionalitätsbereiche (Epics) diskutieren, ohne uns auf eine konkrete Umsetzungsstrategie (Features / User Stories) festzulegen.

Ein zweiter Ansatz, den wir bei der Gestaltung eines Portfolios verfolgen können, ist die Methode des „flexiblen Portfolios“, bei der wir als Produktmanager unser Portfolio entlang zweier Achsen analysieren: Breite (wie viele neue Funktionen wollen wir bereitstellen?) und Tiefe (wie viel technologische Entwicklung sollten wir in jede Funktionalitätsgruppe ein-bringen?). Ein „tiefes“ Portfolio sollte in einem anderen Ge-schäftsumfeld eingesetzt werden als ein „breites“ Portfolio; auch eine Kombination dieser beiden Ansätze ist möglich.

Die folgende Abbildung zeigt, wie Sie Ihr Portfolio entlang dieser beiden Achsen visualisieren können:

Während wir eine langfristige Roadmap erarbeiten, können wir Feedback zu den Zwischenreleases sammeln und diese Ergebnisse in unser Portfolio einfließen lassen, indem wir entscheiden, wo wir eine „tiefere“ Funktionalität implemen-tieren möchten und wo wir das Portfolio „verbreitern“ wollen.Der Vorteil dieses Konzepts besteht darin, dass es das Feedback über einen Rückkopplungskreis direkt in den Portfoliomanagement-Prozess einfließen lässt und uns die Möglichkeit bietet, die Tiefe jedes Epic an die verfügbare Zeit anzupassen (Innovation und Wettbewerbsfähigkeit).Dieses Verfahren können Sie gleich morgen einsetzen: Zeichnen Sie die beiden Dimensionen für Ihr Portfolio auf. Überlegen Sie sich, was für Sie wichtiger ist: wenige „tiefe“ Epics oder viele „flache“ Epics.

Agile Produktentwicklung. Lernfähige ProzesseDer oben beschriebene Fall ist nur ein Beispiel dafür, wie wir einen Rückkopplungskreis herstellen können, mit des-sen Hilfe unser Unternehmen lernen und sich an die jewei-ligen Entwicklungen des realen Umfelds anpassen kann.„Agil“ beschränkt sich aber nicht nur auf das Portfolio-Management. Wir müssen in der Lage sein, Prozesse zu gestalten, die unser Unternehmen lern- und anpassungs-fähig machen. In einem „agilen“ Produktentwicklungsprozess beziehen wir das Produktentwicklungsteam von Anfang an mit ein. Dadurch erhalten wir einen sehr reaktionsschnellen Rück-kopplungskreis für das Feedback zu dem Produkt, während wir es konzipieren und gestalten. Dieser Rückkopplungs-kreis ist wichtig, um1. ein Produkt zu gestalten, das aus technischer Sicht

machbar ist2. den F&E-Teams zu ermöglichen, ihr fundiertes tech-

nisches Know-how anzuwenden und technische Inno-vationen in das Produkt einzubringen, die uns anderen eventuell nicht bewusst sind.

Fall III: Der zyklische unternehmensweite ProzessHier sehen wir eine völlig andere Vorgehensweise beim Entwurf eines unternehmensweiten Prozesses. Das vor-herrschende Bild hier sind „Zyklen“ (Cycles): Zyklen, die im Unternehmen unterschiedliche Aufgaben erfüllen, aber miteinander interagieren müssen, damit wir den in jedem Zyklus geschaffenen Wert nutzen können.

Man sieht, dass bei dem oben dargestellten Ansatz für die Prozessgestaltung die Erkenntnisse, die aus einem monat-


lichen Release des Produkts gewonnen werden, schnell in den Produktmanagementprozess zurückgespeist und dort zur Anpassung an die neuen realen Sachverhalte genutzt werden können. Schnelle Lern- und Anpassungsfähigkeit kann einen entscheidenden Wettbewerbsvorteil für unsere Unternehmen und Produkte darstellen.

Umsetzung in die Praxis

Da wir uns in einem zunehmend wettbewerbsorientierten Umfeld befinden, in dem Innovationsgeschwindigkeit der entscheidende Faktor ist, benötigen wir neue Konzepte für unsere Arbeitsweise. Einfach immer wieder das Gleiche zu tun und doch ein anderes Ergebnis zu erwarten, ist keine Option.Mit den folgenden Maßnahmen können Sie gleich morgen anfangen:1. Analysieren Sie Ihre momentane Arbeitsweise und

eliminieren Sie unnötige Arbeit. Bei GE wurden „Aus-arbeitungs-Meetings“ abgehalten, in denen langsame Prozesse analysiert und Prozessschritte, die keinen Mehrwert zu den betreffenden Produkten oder Dienst-leistungen beitrugen, tatsächlich abgeschafft wurden. Sie können eine „Wertstromanalyse“ (Value Stream Map-ping)[1] als Methode zur Visualisierung und Überprüfung Ihrer Prozesse einsetzen.

2. Arbeiten Sie mit Ihren Kunden zusammen. Verwenden Sie die oben beschriebene „Flexible Scope“-Technik, um den Dialog mit dem Kunden zu erleichtern, bei-spielsweise indem Sie den Kunden in die Auswahl der Epics mit einbeziehen, aber den Teams die Festlegung der Features und Stories überlassen. Verwenden Sie die „Flexible Scope“-Technik, um die flexible Integration neuer Ideen später im Projekt zu ermöglichen; legen Sie sich beispielsweise gemeinsam mit dem Kunden auf die Epics fest, aber lassen Sie Spielraum für spätere Änderungen auf der Feature- und Story-Ebene in Ab-hängigkeit von den während des Projekts gewonnenen Erkenntnissen.

3. Welche Zyklen gibt es in Ihrer Organisation bereits? Werten Sie sie aus und nutzen Sie sie anschließend zur Entwicklung einer Rückkopplungskette, sodass Ihre im Feld gewonnenen Erkenntnisse nicht verloren gehen, sondern schnell in den Produktentwicklungsprozess einfließen können.

4. Und schließlich: Nehmen Sie keine neuen Projekte in Angriff, bevor die laufenden abgeschlossen sind. Akzeptieren Sie die Ergebnisse der Mathematik (Littles Gesetz[2]). Hören Sie auf anzufangen und fangen Sie an aufzuhören!

Weitere Informationen über diese und weitere Experimen-te erhalten Sie auf den Veranstaltungen von Agile Finland (www.agilefinland.com).Agile Finland organisiert jährlich mehrere Veranstaltun-gen; die Hauptveranstaltung zu Agile findet jährlich in Helsinki statt: www.scan-agile.org.

Falls Sie Unterstützung bei der Umsetzung der oben be-schriebenen Verfahren wünschen oder an weiteren „Agile“- oder „Lean“-Ansätzen für die Produktentwicklung interes-siert sind, können Sie mich gerne kontaktieren.

Quellenverzeichnis[1] Wertstromanalyse: http://en.wikipedia.org/wiki/Value_stream_mapping

• Weitere Lektüre:

• Toyota Way, Liker: www.bookdepository.

co.ukbook/9780071392310/The-Toyota-Way

• Learning to See, Shook et al.: www.lean.org/bookstore/Product-

Details.cfm?SelectedProductId=9

[2] Littles Gesetz: http://en.wikipedia.org/wiki/Little's_law

• Weitere Lektüre: Agile Software Development, An Agile Toolkit,

Poppendieck: www.bookdepository.co.uk/book/9780321150783/

Lean-Software-Development

[3] Agile Software Development, Cockburn: www.bookdepository.

co.uk/book/9780321482754/Agile-Software-Development

ZUM AUTORDerzeit ist Vasco Duarte, ein erfahrener Produkt- und Projekt-manager, Agile Coach bei Avira. Seit 1997 arbeitet Vasco in der Software-Industrie und ist seit 2004 auch ein agiler Praktiker seit 2004. Als einer der Leader und Ka-talysatoren von agilen Methoden und Adaption von agilen Kulturen arbeitet er bei Avira und zuvor bei Nokia und F-Secure. Vascos Beiträge zur Entwicklung der

Software-Industrie können in seinem Blog gelesen werden: http://bit.ly/vasco_blog Twitter: @duarte_vasco http://bit.ly/vasco_profile

Vasco Duarte

Agile Breakfast

In losen Abständen von rund zwei Monaten treffen sich agil Interessierte der Scrum User Group Lake Constance (SUGLC) zum Erfahrungsaustausch. Beim „Agile Breakfast“ im Wasserturm Stromeyersdorf in Konstanz hält nach einemkleinen Frühstück ein Teilnehmer oder ein geladener Speaker einen Vortrag zu einem agilen Thema. Daran schließt sich eine Diskussion an (Dauer: 8.00 – 10.00 Uhr).

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

Informationen zu den aktuellen Veranstaltungen:www.sybit.de/agile-breakfast

Sybit GmbH Sankt-Johannis-Str. 1–5 D-78315 Radolfzell Tel. +49 (0) 7732 9508-0 [email protected]

© 2

012

Sybi

t Gm

bH ·

All

e R

echt

e vo

rbeh

alte

n · F

otos

: Tob

ias

Link

- S

ybit

& S

teph

an S

trit

tmat

ter

- Sy

bit

© 2

012

Sybi

t Gm

bH ·

All

e R

echt

e vo

rbeh

alte

n · F

otos

: Tob

ias

Link

- S

ybit

& S

teph

an S

trit

tmat

ter

- Sy

bit

IMMER UP-TO-DATE:

Holen Sie sich die kostenlose iPad-App mit allen Ausgaben von Sybit agile im iTunes-Store.von Sybit agile im iTunes-Store.

Sybit agile · agile Agile Softwareentwicklung im Fokus Sybit Ausgabe 11 Kudo Kasten Jurgen Appelo...

Documents

Transcript of Sybit agile · agile Agile Softwareentwicklung im Fokus Sybit Ausgabe 11 Kudo Kasten Jurgen Appelo...