Agilität

Nachhaltigkeit beginnt ganz vorne ...

… nämlich bei Bildung – und damit bereits in der Schule. Teamprove war im Juli beim sogenannten "Future Lounge Day" im Klenze-Gymnasium in München mit dabei. Im Rahmen dieses Studientags beschäftigen sich Schüler der 11. Klassen intensiv mit der Zukunft ihrer Berufswelt. Auf der Agenda standen auch dieses Jahr wieder topaktuelle Themen wie Industrie 4.0 und Arbeitswelt 4.0, die im Dialog mit Vertretern aus der Wirtschaft erarbeitet wurden.
Weiterlesen
Markiert in:

Wie Teams agil werden

Im Programm einer Entwicklerkonferenz entdeckte ich kürzlich die Session „Hurra, wir werden agil – aber wie?“ Der Titel trifft die Situation in vielen Unternehmen gut: Das Bewusstsein, dass „etwas“ passieren soll, ist da. Aber gleichzeitig herrscht große Unsicherheit, wo und wie angepackt werden soll. Das Thema Agilität brennt vielen Führungskräften auf den Nägeln. Teils, weil genaue Vorstellungen vorhanden sind, was anders bzw. besser werden soll. Teils, weil doch alle anderen auch agil sind und das Management diesen Trend nicht verpassen will. „Wir arbeiten agil“ – das klingt deutlich dynamischer als „Wir entwickeln noch nach Wasserfallmodell“. Und zahlreiche agile Erfolgsstories aus dem Bekanntenkreis und der Fachpresse kennt schließlich auch jeder. Aber wie bildet man agile Teams? Führt man einfach Scrum ein und ist damit automatisch agil? Und wie war das nochmal mit der Unternehmenskultur und den Agile Leaders? Gibt es vielleicht einen 10-Punkte-Plan, der nach und nach abgehakt werden kann?

Weiterlesen

Alles agil oder doch nicht?

Zum 5. Mal war ich nun auf der Manage Agile Konferenz in Berlin und bin mit einem zufriedenen Lächeln wieder nach Hause gefahren. Vor 5 Jahren wurde diese Konferenz ins Leben gerufen und hat damit eine Lücke geschlossen. Die zentrale Frage: Welche Rolle spielt das Management im Zusammenhang mit dem Wunsch nach agiler Transition? Damals war die neue Erkenntnis, dass agile Vorhaben ohne den SUPPORT des Managements auf Dauer kaum nutzbar sind und verkümmern werden. Heute ist die Erkenntnis, dass Agilität ohne den WANDEL des Managements selbst kaum Chancen hat, nachhaltig zum Unternehmenserfolg beizutragen.

Weiterlesen

Was ist eigentlich… DevOps?

Wie können wir neue Ideen schneller umsetzen? Wie reagieren wir flexibler auf Kundenwünsche und Marktveränderungen? Und wie stellen wir trotz kürzerer Innovationszyklen stabile und fehlerfreie Software sicher? Um in dynamischen Märkten wettbewerbsfähig zu bleiben, muss moderne IT hohen Anforderungen gerecht werden. In diesem Zusammenhang ist immer häufiger von „DevOps“ die Rede - eine Philosophie, die auf ein engeres Zusammenrücken der konkurrierenden Bereiche Softwareentwicklung (Development) und IT-Betrieb (Operations) setzt. Aber was genau ist der Grundgedanke der Bewegung, die bei Unternehmen wie Netflix, Walmart, Amazon oder Facebook bereits erfolgreich im Einsatz ist?

Weiterlesen

MbO 2.0: Mit OKR zum Agile Leadership

"Herr Schmidt, Ihre Zielvereinbarung für 2017 steht an – lassen Sie uns nächste Woche ein Mitarbeitergespräch machen!" Eine Ankündigung, die nicht immer für Vorfreude sorgt. Viele Mitarbeiter empfinden die jährlichen Zielvereinbarungen eher als lästige Pflicht denn als Motivation. Insbesondere die bei klassischen Führungsinstrumenten übliche Koppelung an leistungsorientierte Boni trägt nicht automatisch zum Unternehmenserfolg bei.

Weiterlesen

abas 2016 The Global Conference: Wir sind dabei!

In einer Woche ist es soweit: Am 22. September öffnet die diesjährige Konferenz des Software-Herstellers abas ihre Pforten. Im Frankfurter Konferenzzentrum THE SQUAIRE werden rund 1.500 internationale Teilnehmer über ERP und moderne Unternehmenssteuerung diskutieren.

Wir freuen uns sehr, dass wir eingeladen wurden, uns als Speaker am Konferenzprogramm zu beteiligen: Mit dem Teamprove-Vortrag „Das agile Unternehmen“ möchten wir Entscheider inspirieren, wie Unternehmen die Erfolgsfaktoren der agilen Methode nutzen können, um schneller zu sein als der Wettbewerb. Klingt spannend? Ist es auch!

Weiterlesen
Markiert in:

Lean Startup: Küss den Frosch!

Was haben Dropbox, AirBnB und Adobe gemeinsam? Diese Unternehmen haben auf dem Weg zum Erfolg viele Frösche geküsst – und mussten vermutlich auch die eine oder andere Kröte schlucken. Und doch zählen sie heute in ihrem jeweiligen Segment zu den Marktführern.

Nach ihren Erfolgsgeheimnissen gefragt, taucht bei allen drei Unternehmen das Zauberwort „Lean Startup“ auf.

Weiterlesen

Macht Agilität Manager überflüssig? Unternehmenskultur Teil 3

Management 3.0, Agile Leadership, agile Führungsmethoden: Schlagworte, die viele Unternehmen bewegen – im wahrsten Sinne des Wortes, denn Agilität soll Ihr Unternehmen „voranbringen“! Damit das gelingt, müssen nicht nur Entwickler und Tester umdenken, sondern auch Teamleiter und Manager stehen vor der Herausforderung, neue Führungs- und Steuerungsmethoden zu lernen und anzuwenden. Und zwar längst nicht mehr nur in der Softwareentwicklung, sondern in sämtlichen Branchen und Unternehmensbereichen.

Aber wie sieht ein moderner Führungsstil aus? Und benötigen agile Unternehmen überhaupt noch Manager?


Warum Agile Leader ein Herkules-Job ist

Es gibt jede Menge Informationen über agile Softwareentwicklung im Allgemeinen und agile Methoden wie Scrum im Speziellen, aber recht wenig konkrete Tipps für Führungskräfte. Scrum-Teams werden umfassend geschult – aber wer begleitet eigentlich Manager bei Ihrer Aufgabe, die nötigen Veränderungen in Ihrer Organisation einzuführen? Schließlich müssen agile Führungskräfte unter anderem …

  • ein neues Selbstverständnis ihrer eigenen Rolle im Unternehmen entwickeln
  • eine agile Unternehmenskultur schaffen und agile Werte vorleben
  • Ihr Team motivieren, begeistern und dafür sorgen, dass alle am Ball bleiben
  • Widerstände verstehen und damit umgehen

Kein Wunder also, dass zahlreiche Studien zu dem Ergebnis kommen, dass das Management häufig die größte Bremse auf dem Weg zum agilen Unternehmen darstellt.

Alle sitzen im gleichen Boot

In Teil 1 und Teil 2 unserer Serie „Unternehmenskultur“ haben wir es schon mehrmals angesprochen: Agile Transition führt fast immer zu Unsicherheit – nicht nur in den Teams, sondern auch bei den Führungskräften, vom mittleren Management bis hin zur Geschäftsleitung. Je traditioneller der bisherige Führungsstil ausgeprägt war, desto größer ist die Angst vor Macht- und Statusverlust und die Skepsis hinsichtlich der anstehenden Veränderungen.

Typische Frage: „Reicht es denn nicht, wenn das Entwicklerteam Scrum macht?“ Nein, tut es nicht. Zwar hat Agilität ihre Wurzeln in der Technik, aber sie entfaltet ihr volles Potenzial nur im Rahmen einer durch alle Ebenen gelebten agilen Unternehmenskultur. Das Management muss nicht nur mitziehen, sondern vorausgehen und „die Bahn freimachen“.

Braucht Selbstorganisation Führung?

Aber halt: Steuern sich agile Teams nicht selbst? Welche Rolle nimmt dann der bisherige „Leiter“ ein? Und werden Führungspositionen und Hierarchien nicht sowieso abgeschafft? Jein. 

Zum einen bedeutet Selbstorganisation nicht, dass künftig jeder tut, was er möchte. Ziel von Agilität ist, gemeinsam ein Ziel zu erreichen und immer besser zu werden. Dies bedarf – zumindest anfangs – durchaus fachlicher Führung, sprich das „Management 3.0“ hat nicht weniger Aufgaben, sondern andere: die Vision vermitteln, optimale Arbeitsbedingungen schaffen, die Team-Mitglieder weiterentwickeln etc. Die neue Freiheit agiler Teams ist kein Selbstläufer, sondern die Übernahme von deutlich mehr Verantwortung muss gelernt und vom Management gefördert und begleitet werden.

Zum anderen geht es nicht darum, alle Strukturen abzuschaffen, sondern eine Struktur zu schaffen, die den gemeinsamen Zielen am besten dient. Doch was bedeutet das mittelfristig, d.h. sobald das Team gelernt hat sich selbst zu organisieren? Für Firmeninhaber mag es als Fernziel durchaus reizvoll erscheinen, Verantwortung zu delegieren und mehr Zeit zu haben.

Beim mittleren Management hingegen regt sich bei dieser Vorstellung häufig Widerstand, sieht es doch im ersten Moment so aus, als würden Führungskräfte den Ast absägen, auf dem sie sitzen: Je besser sie ihren Job bei der agilen Transition machen, desto früher können ihre Positionen „abgeschafft“ werden?

Neue Manager braucht das Land!

Nein, abgeschafft wird lediglich das starre Festhalten an Hierarchien und Positionen, an Macht und Kontrolle und die alleinige Konzentration auf extrinsische Motivation. Manager, die Agilität wirklich verstanden haben, sehen ihre eigene Rolle aus einem anderen Blickwinkel: Mag sein, dass ihre bisherige Position überflüssig wird, aber nicht ihre Person! Im Gegenteil, Führungskräfte, die sich im Rahmen der agilen Transition bewähren, sind für das Unternehmen deutlich wertvoller als Führungskräfte, die auf ihre Stellenbeschreibung oder ihr Kästchen im Organigramm pochen und damit ihr Team blockieren.


Ein beliebtes Werkzeug, um Selbstorganisation spielerisch und schrittweise einzuführen, ist der „Delegation Poker“.

In agilen Unternehmen definiert sich Macht oder Wert nicht über den Titel auf der Visitenkarte, sondern ein Manager ist dann ein „guter“ Manager, wenn er motivieren kann, wenn er sein Team an den Punkt bringt, dass es auch ohne ständige Anleitung und Kontrolle bestens funktioniert. Und für solche Führungskräfte steht in einem agilen Unternehmen die nächste spannende Aufgabe garantiert schon bereit.

Was außerdem oft übersehen wird: Agiles Management führt nicht nur zu einer Optimierung der Arbeit in den Entwicklerteams, sondern auch der operative Geschäftsbereich „Management“ selbst profitiert ungemein von der neuen Denk- und Herangehensweise. Führungsaufgaben werden in den Unternehmen immer komplexer und strategische Entscheidungen müssen immer schneller getroffen werden. Die agilen Prinzipien kurzer Feedback-Zyklen und der Einsatz von Retrospektiven erhöhen auch im Management die Transparenz, Probleme in Unternehmenssteuerung werden schneller erkannt und können aktiv angegangen werden.

Die Top 5 Kernkompetenzen agiler Führung

  • Motivation
    Vermitteln Sie eine Vision und sorgen Sie dafür, dass Ihre Mitarbeiter aktiv und kreativ sind! Das beinhaltet auch eine entsprechende Wertschätzung und die Work-Life-Balance.
  • Vertrauen
    Befähigen Sie Ihr Team, indem Sie den nötigen Raum für Selbstorganisation schaffen! Setzen Sie die Stärken der einzelnen Mitarbeiter gezielt ein, lernen Sie Aufgaben zu delegieren und fördern Sie Mitbestimmung und Eigeninitiative!
  • Kommunikation
    Lassen Sie sich auf einen regen Austausch ein – mit Mitarbeitern, aber auch mit Kunden!  Schaffen Sie ein angenehmes Diskussions- und Feedback-Klima und greifen Sie nicht dominierend, sondern moderierend ein.
  • Reflexion
    Seien Sie kritikfähig und ehrlich zu sich selbst, wenn Sie in alte Muster zurückfallen – und machen Sie es nächstes Mal besser!
  • Entwicklung
    Akzeptieren Sie das System der kontinuierlichen Veränderung und nutzen Sie es – für Ihr Unternehmen, für Ihr Team, aber auch für sich selbst und Ihre Rolle in der Organisation.


Wenn Sie einer dieser „neuen Manager“ sind (oder werden möchten), begleiten wir Sie und Ihr Unternehmen gerne auf dem Weg in die Agilität – fragen Sie uns nach maßgeschneiderten Management-Workshops oder Coachings!

Bildnachweis:
Jakub Jirsak / 123rf.com

Weiterlesen

Agiles Testen: Wie es geht. Und warum es ohne nicht geht.

Klar, getestet wird Software schon immer. Auch bei klassischen Vorgehensmodellen ist Testen ein entscheidender Bestandteil des Qualitätsmanagements, denn mangelhafte Testprozesse sind nicht nur eine der Hauptursachen für Fehlfunktionen im Live-Betrieb, sondern auch für Effizienz-Einbußen: Die Wahrscheinlichkeit ist hoch, dass spät entdeckte Bugs die Arbeit des Entwicklerteams im Projektverlauf behindern.

Was aber macht agiles Testen so anders, dass ganze Bücher darüber geschrieben werden? Wie ändert sich das Selbstverständnis des Testers und welche Rolle spielt die Testautomatisierung?

Weiterlesen

Scrum. Oder die Kunst, doppelt so viel Arbeit in der halben Zeit zu schaffen.

„The Art of Doing Twice the Work in Half the Time“ – ein im wahrsten Sinne des Wortes viel versprechender Buchtitel des Scrum-Mitbegründers Jeff Sutherland. In der deutschen Übersetzung war der Verlag zwar nicht ganz so mutig, nichtsdestotrotz bringt auch der Titel „Die Scrum-Revolution“ das Ziel des agilen Frameworks zum Ausdruck: einen Umbruch im Unternehmen bewirken.

Aber was kann die Wunderwaffe Scrum wirklich? Eignet sich Scrum für jedes Projekt, jedes Unternehmen, jedes Team – auch für Sie?


Mal ehrlich: Wo ist der Haken?

Dass Scrum mehr ist als ein US-Hype mit dem typisch amerikanischen Hang zur Übertreibung, beweisen inzwischen zahlreiche deutsche Erfolgsgeschichten. Ein gutes Beispiel ist die Scout24-Unternehmensgruppe. Das Münchner Online-Unternehmen setzte schon vor rund 7 Jahren auf Scrum in der Produkt- und Softwareentwicklung – mit schnell sichtbaren (und messbaren) Erfolgserlebnissen: Im ersten Jahr nach der Scrum-Einführung stieg die Entwicklungsgeschwindigkeit nach eigenen Angaben um 200 Prozent und die Anzahl kritischer Fehler konnte um rund 80 Prozent gesenkt werden.

Effizienzsteigerungen durch Scrum im Vergleich zu klassischen Wasserfall-Modellen sind nachgewiesen. Aber wenn es so einfach ist, warum machen dann eigentlich nicht alle Scrum?

„Scrum is very easy to understand but very difficult to master.“
Ken Schwaber

Scrum ist komplex. Scrum fordert. Und Scrum verändert. Auch Scout24 berichtete von der Erfahrung, dass Scrum weit mehr ist als eine „Methode“. Die Einführung von Agilität geht Hand in Hand mit einer neuen Unternehmenskultur, die unter anderem das Verhältnis zwischen Team und Management und das Verständnis von Arbeit und Führung hinterfragt – und bei Bedarf eben auch umkrempelt.

Schon gewusst? „Scrum“ wird 30!

So revolutionär der Ansatz vielen Unternehmen scheint: Die Erkenntnis, dass kleine, interdisziplinäre und selbstorganisierte Teams bessere Ergebnisse erzielen, ist nicht neu. Bereits vor Jahrzehnten experimentierten renommierte Firmen mit vergleichbaren Modellen des Projektmanagements, ausgehend von der Lean-Production-Bewegung in Japan.

1986 stellten Hirotaka Takeuchi und Ikujiro Nonaka in einem Aufsatz der Harvard Business Review verschiedene Fallbeispiele von Unternehmen vor, deren Produktentwicklungen ungewöhnlich schnell und innovativ waren, u.a. Pkws bei Honda, Spiegelreflexkameras bei Canon, Kopierer bei Fuji-Xerox sowie PCs bei NEC.

Als ausschlaggebende Gemeinsamkeit der analysierten Unternehmen identifizierten die beiden Wirtschaftswissenschaftler kleine Teams mit einer charakteristischen Arbeitsweise, die Takeuchi und Nonaka „Scrum“ nannten (die engl. Bezeichnung für einen Rugby-Spielzug, übersetzt „Gedränge“).

„In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method - as in rugby, the ball gets passed within the team as it moves as a unit up the field.“
Hirotaka Takeuchi und Ikujiro Nonaka

Takeuchi und Nonaka formulierten 6 Bedingungen für effiziente Teams:

  • Built-in instability
  • Self-organizing project teams
  • Overlapping development phases
  • Multilearning
  • Subtle control
  • Organizational transfer of learning

Inspiriert von Takeuchi und Nonaka entwickelten Jeff Sutherland und Ken Schwaber rund 10 Jahre später den „Rugby Approach“ weiter zu dem Framework, das wir heute als Scrum kennen.

Die Zeit war reif für Scrum

1994 veröffentlichte die Standish Group den ersten CHAOS-Report mit desaströsen Zahlen: Rund ein Drittel aller IT-Projekte scheiterte vorzeitig, nur 16 Prozent erreichten das angestrebte Entwicklungsziel ohne Mängel. Gleichzeitig erhöhte sich Mitte der 90er Jahre die Nachfrage nach leistungsfähiger Software rasant – entsprechend händeringend suchte die Softwareindustrie nach Lösungen.

Auch Sutherland und Schwaber beschäftigten sich intensiv mit der Frage, wie die Produktion von Software effizienter gestaltet werden konnte. Großes Verbesserungspotenzial sahen sie in der Flexibilisierung der Projektprozesse, weg von „top down“, hin zu mehr Spielraum für eigenverantwortliches Handeln.

Die Veröffentlichungen von Schwaber und Sutherland wurden von der Entwickler-Community wissbegierig aufgenommen und getestet. 2001 hielten Jeff Sutherland, Ken Schwaber und 15 weitere Experten die neuen Werte der Bewegung im Agilen Manifest fest – bis heute das Fundament aller agilen Methoden, von denen Scrum die populärste ist.

Scrum: Freiheit in Grenzen 

„Wenn man ein Projekt beginnt, warum sollte man dann nicht regelmäßig überprüfen, ob die Richtung noch stimmt und man Leistungen erbringt, die tatsächlich gebraucht werden? Warum nicht prüfen, ob es vielleicht Mittel und Wege gibt, um besser und schneller voranzukommen, und welche Hindernisse dem womöglich entgegenstehen?“
Jeff Sutherland

Als Gegenentwurf zum klassischen Projektmanagement formuliert Scrum statt eines Plans eine Vision, die erst im Projektverlauf konkretisiert wird. Diese empirische Entwicklung erfolgt nicht völlig ungesteuert, sondern iterativ-inkrementell und innerhalb fest definierter Rollen, Ereignisse und Artefakte.

2010 verfassten Ken Schwaber und Jeff Sutherland mit dem „Scrum Guide“ einen offiziellen Scrum-Leitfaden, der kontinuierlich weiterentwickelt wird.

Wichtig für den Projekterfolg ist das Zusammenspiel der Rollen, Ereignisse und Artefakte nach Scrum-Regeln. Dazu betrachten wir den Scrum-Flow genauer:

Der Scrum-Flow / © Teamprove

Die Scrum-Rollen

  • Product Owner
    Der Produkteigner vertritt die Interessen der Anwender und Stakeholder und ist für die strategische Entwicklung und den wirtschaftlichen Erfolg des Projekts verantwortlich. Er pflegt das Product Backlog und priorisiert die Anforderungen. Kurz gesagt: Er bestimmt WAS gemacht wird und in welcher Reihenfolge. Falls kein direkter Kontakt zwischen Entwicklungsteam und Kunde möglich ist, ist der Product Owner das Bindeglied zum Kunden.

  • Entwicklungsteam
    Das Team entscheidet gemeinsam, WIE die Vorgaben des Product Owners umgesetzt werden, unter Berücksichtigung der gewünschten Reihenfolge und unter Einhaltung der vereinbarten Qualitätsstandards. Scrum-Teams arbeiten interdisziplinär, ohne Hierarchien und mit einer optimalen Teamgröße von 7 +/-2 Mitgliedern.

  • Scrum Master
    Der Scrum Master stellt sicher, dass die Scrum-Regeln und Werte eingehalten werden und hilft dem Team, selbstorganisiertes Arbeiten so anzuwenden, dass bessere Ergebnisse erzielt werden. Er ist nicht weisungsbefugt, sondern fungiert als Moderator und versteht sich als Dienstleister des Projektteams.

Die Scrum-Ereignisse

Aktivitäten im Scrum-Prozess:

  • Sprint Planning
    Priorisierung und Auswahl der Backlog Items für den nächsten Sprint

  • Daily Scrum
    Status quo und Tagesplanung

  • Sprint Review
    Präsentation des Inkrements

  • Sprint-Retrospektive
    Rückblick mit dem Ziel der Verbesserung

  • Product Backlog Refinement / Grooming
    Pflege des Product Backlogs

Die Scrum-Artefakte

Resultate des Scrum-Prozesses:

  • Product Backlog
    alle Anforderungen an das Produkt

  • Sprint Backlog
    alle ausgewählten Backlog Items für einen Sprint

  • Product Increment
    fertiges Teilprodukt, das am Ende des Sprints geliefert wird

Von der Vision zum Product Backlog

Aus der Vision des Product Owners werden sämtliche Elemente des Produkts abgeleitet, die entwickelt werden müssen.


Formulieren Sie die Funktionalitäten („Product Backlog Items“) in Form von User Stories auf Story Cards! Wichtig: Beschreiben Sie die Funktionalität aus Sicht des Anwenders in 1 Satz, ohne technischen Fachjargon und immer unter Betrachung des Kundennutzens. Bewährt hat sich das Muster „Ich als möchte <Ziel/Wunsch> um “. Ein Beispiel: „Als Nutzer des Onlineshops will ich zwischen verschiedenen Versandoptionen wählen können, um die Lieferung genau dann zu bekommen, wann ich sie benötige.“

Die Summe aller User Stories bildet das Product Backlog - eine Sammlung sämtlicher Funktionen und Merkmale, die das fertige Produkt haben soll. Zu Beginn des Projekts ist das Product Backlog noch grob und wird im Projektverlauf immer detaillierter. Auf Basis der User Stories wird auch der Aufwand für das Projekt geschätzt.

Nach dem Sprint ist vor dem Sprint

Charakteristisch für Scrum ist die Entwicklung in Zyklen („Sprints“). Die sogenannten Sprints sind während des Projekts immer gleich lang („Timebox“), um einen Entwicklungsrhythmus zu erzeugen. Gemäß Scrum-Guide sind die Sprints zwei bis maximal vier Wochen lang.


Wir haben gute Erfahrungen damit gemacht, eine Scrum-Einführung mit einwöchigen Sprints zu starten. So gewöhnen sich die Projektbeteiligten schneller an die Routine von Scrum-Ereignissen und Scrum-Artefakten und das Feedback fließt in kürzeren Abständen ein. Auch Fragen und Änderungen können in einwöchigen Sprints sehr zeitnah diskutiert werden.

Ziel jedes Sprints ist die Fertigstellung einer neuen, lauffähigen Funktion („Inkrement“), die dem Kunden ausgeliefert werden könnte, d.h. innerhalb jedes Sprints werden alle Aufgaben (Planung, Entwicklung, Test, Dokumentation) abgeschlossen. Auch wenn die sofortige Nutzung nicht in jedem Sprint funktioniert (und auch nicht bei jedem Inkrement sinnvoll ist), so ist ein „potentially shippable increment“ doch immer das Ziel! So wird im Verlauf der Sprints der Umfang bzw. die Qualität des Produkts immer ausgereifter.

Aber wann ist ein Inkrement „fertig“? Als Bemessungsgrundlage dient hier die „Definition of Done“ – eine Checkliste konkreter und verbindlicher Anforderungen, auf die sich Product Owner und Team vor Beginn des Sprints einigen.

Während eines Sprints organisiert sich das Entwicklungsteam selbst und die Anforderungen dürfen nicht verändert werden.

Und was macht man so während eines Sprints?

Der Vorteil von Scrum liegt in der Ritualisierung der Prozesse: Alle Meetings finden regelmäßig und innerhalb einer gleichbleibenden Timebox statt. Alle Teilnehmer kennen das Ziel des Meetings und die zur Verfügung stehende Zeit. So ist gewährleistet, dass sich jeder auf das Wesentliche konzentriert und jedes Meeting dazu beiträgt, das Projekt voranzubringen – das Projekt bleibt kontinuierlich in einem produktiven „Flow“.

Sprint Planning

Jeder Sprint beginnt mit einer meist eintägigen Sprint-Planung: Der Product Owner präsentiert sein Ziel sowie die Product Backlog Items mit der höchsten Priorität, und das Team stellt Rückfragen, bis alle Anforderungen verstanden sind.

Auf Basis der Aufwandsschätzung  und der Kapazitäten entscheiden die Teammitglieder dann gemeinsam, wie viele Stories sie in der vom Product Owner vorgegebenen Reihenfolge in den Sprint übernehmen („committen“) können. Aus der Liste dieser ausgewählten User Stories für den nächsten Sprint entsteht das Sprint Backlog.


Achten Sie darauf, dass das Team seine Arbeitsmenge und die Arbeitsweise unbeeinflusst selbst steuern kann – es bekommt keinerlei Vorgaben über das „WIEVIEL“ und das „WIE“! Gleichzeitig trägt das Team die Verantwortung für eine pünktliche Lieferung der zugesagten Funktionalitäten in der vereinbarten Qualität - ein typischer Knackpunkt zu Beginn einer Scrum-Transition, da sich die Teams häufig zu hohe, unrealistische Ziele setzen.

Daily Scrum

Jeden Tag zur selben Zeit trifft sich das Team zu einem 15-minütigen Meeting, das vom Scrum Master moderiert wird. Die Teammitglieder berichten über die Fortschritte, sprechen sich ab, wer welche Aufgabe übernimmt und informieren den Scrum Master über Probleme. (Was habe ich gestern getan? Was werde ich heute tun? Was hindert mich zu tun, was getan werden müsste?) Auf einem Scrum Board wird ähnlich wie beim Kanban-Board der Status der einzelnen Aufgaben visualisiert.


Verwenden Sie hier ein physisches Board, das viel Platz bietet! Es gibt zwar gute digitale Tools, aber eine Tafel erhöht die Transparenz und fördert die Kommunikation. Können Sie auf die Online-Variante nicht verzichten (z.B. weil sich die zeitweise räumliche Trennung des Teams nicht ganz vermeiden lässt), so ist ein zusätzliches physisches Board trotzdem sehr empfehlenswert.

Product Backlog Refinement

Für die Backlog-Pflege hat sich ein Product Backlog Refinement (oder „Grooming“) gegen Ende des Sprints bewährt. Ziel ist es, frühzeitig neue Informationen zusammenzutragen, so dass Product Owner und Teammitglieder optimal vorbereitet in das nächste Planning Meeting gehen.

Gegenstand des Refinement-Meetings sind beispielsweise Priorisierungen für den nächsten Sprint, Erweiterungen des Product Backlogs, das Herunterbrechen umfangreicher Backlog-Items in zeitlich umsetzbare Stories sowie neue oder genauere Aufwandsschätzungen.


Planen Sie ausreichend Zeit für das Grooming ein – der Scrum Guide sieht vor, bis zu 10 Prozent der Sprint-Zeit für das Refinement-Meeting zu reservieren, um das nächste Sprint Planning so effizient wie möglich zu gestalten.

Sprint Review

Am Ende des Sprints präsentiert das Team dem Product Owner die neue Funktionalität. Nur lauffähige Inkremente dürfen vorgestellt werden, alle nicht fertig gestellten Funktionalitäten gelten als nicht geliefert.

Sprint Retrospektive

Ein wesentliches Scrum-Element ist kontinuierliches Lernen: Im Rahmen einer Sprint Retrospektive analysieren die Teammitglieder die Prozesse und beschließen, welche Änderungen nötig sind, um in der Zukunft effektiver zu arbeiten („Backlog Impediment“).


Die Änderungen sollten nicht auf die lange Bank geschoben, sondern möglichst sofort umgesetzt werden! Übrigens: Zum effektiven Arbeiten zählt auch der Spaß an der Arbeit! Die Verbesserungsvorschläge können also durchaus auch Ideen aufgreifen, wie die intrinsische Motivation erhöht werden kann.

Und wann ist das Produkt fertig?

Der Scrum-Trick: Mit den Inkrementen erhält der Kunde während des Projekts schon sehr früh voll funktionsfähige (Teil-)Versionen geliefert, die mit jeder Iteration umfangreicher und/oder qualitativ hochwertiger werden. Neue Features können mit „echten“ Nutzern getestet werden, und in jedem Sprint können bestehende Anforderungen abgeändert oder neu priorisiert werden.

So bestimmt der Kunde während des gesamten Projekts die Entwicklungsrichtung – auch den Zeitpunkt des Projektabschlusses: Wenn der Product Owner mit den Funktionalitäten der aktuellen Produktversion zufrieden ist und keine weiteren Entwicklungen wünscht, ist das Scrum-Projekt beendet.

Scrum: lean, aber nicht leicht

„Prima, Scrum passt ja auf 1 DIN-A4-Blatt!“, so scheint der erste Eindruck. Stimmt, das Rahmenwerk ist schlank und die Regeln sind einfach zu verstehen – aber in der Umsetzung alles andere als trivial! Insbesondere das neue Rollenverständnis und das selbstorganisierte, interdisziplinäre Arbeiten ohne übergeordneten Projektmanager und ohne genaue Vorgaben „von oben“ muss verinnerlicht werden.

In Unternehmen mit anweisungsorientierter Unternehmenskultur sind außerdem nicht nur die Erwartungen hoch, sondern auch die Bedenkenliste lang:

  • Wird unser Management durch Scrum entmachtet?
  • Was passiert mit den Zielvereinbarungen (MBO) unserer Mitarbeiter?
  • Was machen künftig überhaupt unsere Projektleiter?
  • Wie sollen wir Budgets planen, wenn die Aufwände nicht exakt geschätzt werden können?
  • Sind unsere Projekte nicht zu groß für agile Methoden (Thema Skalierung)?

Fakt ist: Der Erfolg von Scrum hängt von zahlreichen Faktoren ab. Wie aufgeschlossen sind die Teammitglieder für die neuen Prozesse – und wie gut setzen sie Selbstorganisation um? Hält sich das Management in den Meetings tatsächlich mit „top down“-Ansagen zurück? Wird von beiden Seiten offen und ehrlich kommuniziert? Hat das Team Unterstützung durch einen versierten Scrum Master?


Sofern im Team niemand die nötige Erfahrung hat, um die Rolle des Scrum Masters einzunehmen, ist die Begleitung durch einen externen Scrum-Coach empfehlenswert, der übergangsweise die Rolle des Scrum Masters übernimmt und das Team bei der Transition unterstützt. 

Die wichtigste Voraussetzung für eine erfolgreiche Scrum-Transition ist die Bereitschaft für die in Sutherlands Buch versprochene Revolution im Unternehmen – alles andere ist erlernbar. Um auf den Titel zurückzukommen: Ja, dann kann Scrum tatsächlich dazu führen, die doppelte Arbeit in der halben Zeit zu schaffen. Wir helfen Ihnen gerne dabei! Eine Liste mit Lesetipps finden Sie übrigens hier.

Welche Erfahrungen haben Sie mit der Einführung von Scrum gemacht? Wir freuen uns auf Ihre Kommentare und Fragen!

Bildnachweis:
Titelbild Scrum: matthewjones / 123RF

Weiterlesen

Was ist eigentlich ... iteratives Arbeiten?

Haben Sie heute schon einen Kaffee getrunken? Dann haben Sie vermutlich ein iterativ entwickeltes Produkt benutzt, vielleicht eines der Nespresso-Modelle EN166, EN266, EN520 oder EN550 - je nachdem in welcher Iteration Sie Ihre Maschine gekauft haben. Ob Kaffeemaschine, Smartphone, Computer, Fotoapparat oder Software: Sehr viele Produkte werden iterativ entwickelt, d.h. es wird eine vorläufige Version vorgestellt, anschließend sofort hinterfragt und auf Basis des Feedbacks weiter verbessert, bis das gewünschte Ergebnis erreicht ist.


Oder wissenschaftlich ausgedrückt:
„Iteration (von lat. iterare ,wiederholen‘) beschreibt allgemein einen Prozess mehrfachen Wiederholens gleicher oder ähnlicher Handlungen zur Annäherung an eine Lösung oder ein bestimmtes Ziel.“ (Quelle: Wikipedia)

Spannend an der iterativen Herangehensweise ist, dass sich die Ergebnisdefinition (in unserem Beispiel "die perfekte Kapsel-Kaffeemaschine") im Projektverlauf jederzeit ändern kann und ändern darf!

Iterativ: vom Vorläufigen zum Perfekten

Auch in der agilen Softwareentwicklung ist iteratives Arbeiten eine Grundvoraussetzung. Alle Projektbeteiligten akzeptieren, dass es unwahrscheinlich ist, das Produkt gleich beim ersten Versuch perfekt abzuliefern. Stattdessen wird ein Prototyp entwickelt und Feedback eingeholt, das sofort in eine Nachfolgeversion einfließt. Diese Feedbackschleifen (Iterationen) werden so oft wiederholt, bis der Auftraggeber zufrieden ist.

Wichtig: Es wird nicht einfach willkürlich an irgendwelchen Ecken "herumverbessert", sondern jede Iteration geht zurück zum Start, d.h. hinterfragt in einer Analyse den aktuellen Status Quo, macht sich erneut Überlegungen zum Design und führt nach der Implementierung wieder Tests durch. Im klassischen Wasserfallmodell hingegen wird das komplette Projekt zuerst analysiert, dann designed, implementiert und erst zum Schluss getestet.

Der Nachteil: Ein isolierter iterativer Ansatz führt dazu, dass erst recht spät ein marktfähiges Produkt vorliegt. Also vielleicht doch lieber inkrementell?

Inkrementell: vom Kleinen zum Großen

In inkrementellen Prozessen wird nicht am Gesamtsystem gearbeitet, sondern festgelegte Teilbereiche („Inkremente“) peu à peu fertiggestellt. So erhält der Auftraggeber sehr früh einzelne voll funktionsfähige Bausteine, allerdings fehlt im Gegensatz zur iterativen Arbeitsweise der Blick für „das große Ganze“ - Sie sehen den Wald vor lauter Bäumen nicht mehr.

Beispiel Straßenbau: Stellen Sie sich vor, Sie erhalten den Auftrag, eine neue Straße durch unwegsames Gelände zu bauen. Arbeiten Sie iterativ, roden Sie zuerst einen schmalen Trampelpfad für Fußgänger frei und testen die Wegeführung. Vielleicht korrigieren Sie noch einzelne Wegabschnitte, bevor Sie anfangen die Straße zu verbreitern, zu teeren, Leitplanken anzubringen, eine Ampelanlage zu bauen usw. Jede Straßenversion ist ein Stück ausgereifter, aber grundsätzlich kommen Sie bereits ab der ersten Iteration von A nach B.

Entscheiden Sie sich hingegen für eine inkrementelle Arbeitsweise, bauen Sie die Straße abschnittsweise – Sie kennen das vom klassischen Autobahnbau. Zwar ist jeder Teilbereich für sich früh bis ins kleinste Detail perfekt und nutzbar, aber mit dem Auto von A nach B fahren können Sie erst, wenn alle Etappen fertig sind.

Iterativ-inkrementell: Veränderung als Vorteil

Sie ahnen es bereits: Erst in Kombination entfalten beide Arbeitsweisen ihr volles Potenzial, insbesondere wenn es sich um komplexe Projekte handelt. So gegensätzlich die beiden Ansätze auf den ersten Blick wirken – sie ergänzen sich wunderbar. Scrum beispielsweise ist ein typisches iterativ-inkrementelles Framework.

Vereinfacht dargestellt wird die Gesamtaufgabe in kleinere Einheiten eingeteilt, die wiederum iterativ realisiert werden, d.h. die Teilbereiche werden basierend auf dem Feedback des Auftraggebers überarbeitet, bis sie den gewünschten Reifegrad erreicht haben. Dabei werden nicht wahllos Inkremente herausgepickt oder in einer sturen Reihenfolge abgearbeitet, sondern eine sinnvolle Priorisierung führt zu früh voll funktionsfähigen Key-Features, die ggf. sogar als marktfähige Prototypen eingesetzt werden können.

Tipp: Falls Sie noch mehr über den Unterschied zwischen inkrementell und iterativ wissen möchten - eines der anschaulichsten und meistzitierten Beispiele ist der „Mona-Lisa-Vergleich“ von Jeff Patton.

Und was bringt iterativ-inkrementelle Softwareentwicklung?

  • Höhere Kundenzufriedenheit: Durch die kontinuierliche Einbeziehung des Auftraggebers erhält der Kunde exakt das, was er benötigt und wann er es benötigt. Er arbeitet von Stunde Null an intensiv mit und versteht so auch die Komplexität des Projekts und die Qualität des Produkts besser. Durch die Kombination erhält der Auftraggeber sehr schnell sowohl einen ersten Eindruck vom kompletten Ergebnis als auch einzelne fertig ausgearbeitete Teilbereiche, die genutzt (oder vermarktet) werden können. Anhand des Straßenbeispiels: Von Beginn an wird am gesamten Straßenverlauf gearbeitet, aber vielleicht wird eine von vier geplanten Fahrbahnspuren schon zu einem frühen Zeitpunkt so weit ausgebaut, dass sie von Autos befahren werden kann. Die Erkenntnisse aus der Nutzung dieser Spur fließen dann wiederum in die weitere Bauplanung ein.
  • Geringere Kosten: Der Weg zum Ziel ist direkter, es wird nur entwickelt, was wirklich benötigt wird. Anforderungen, die sich als überflüssig oder unbrauchbar herausstellen, werden früh entdeckt und ggf. durch wichtigere, wertvollere Ideen ersetzt. Auf das Straßenbaubeispiel übertragen: Vielleicht stellt der Auftraggeber bei der Nutzung der ersten Spur fest, dass der Verkehr weniger dicht ist als geplant und dass statt einer vierspurigen Straße zwei Spuren völlig ausreichen (und das gesparte Geld besser in ein Stauwarnsystem investiert wird.)
  • Kontinuierliches Lernen: Zwar wird in jeder Art von Prozess gelernt – egal ob Wasserfall oder iterativ. Beim iterativen Vorgehen kommt das Gelernte aber den noch anstehenden Entscheidungen zu Gute. Beim Wasserfall werden bereits zu Projektbeginn die Weichen gestellt, d.h. die im Projektverlauf gewonnenen Erkenntnisse können nicht mehr mit einfließen. Das verursacht nicht nur mehr Arbeit und Kosten, sondern auch Frust.
  • Bessere Planbarkeit: Grundsätzlich wird nur das geschätzt, was zum jeweiligen Zeitpunkt Sinn macht. Während des Projekts wird die Geschwindigkeit des Entwicklungsteams gemessen, so dass die Schätzungen für künftige Projektabschnitte immer zuverlässiger werden.

Auch Scrum betrachtet die Unsicherheiten zu Projektbeginn nicht als Nachteil, sondern nutzt Veränderlichkeit aus, um innovative, an den Kundenbedarf angepasste Produkte zu schaffen. Was der iterativ-inkrementelle Ansatz mit Scrum-Sprints zu tun hat, werden wir demnächst in einem eigenen Artikel ausführlich vorstellen.

So, und jetzt hole ich mir einen Kaffee aus meiner (fast) perfekten Kaffeemaschine ...

Bildnachweis: anyaivanova / 123RF

Weiterlesen
Markiert in:

Wie werden wir agil? | Unternehmenskultur Teil 2

Kann man agile Unternehmenskultur lernen? Darüber diskutieren sich Experten und Praktiker die Köpfe heiß. Wir sind überzeugt: Ja, man kann. Aber der Wandel braucht Zeit. Und er benötigt einiges an Mitmachwillen im Team und im Management – die Bereitschaft zum Umdenken, die Bereitschaft betriebliche Abläufe zu verändern. Aber wie geht man die agile Transformation an? Gibt es überhaupt „den“ Königsweg?

Weiterlesen

Warum die Unternehmenskultur Ihre Strategie zum Frühstück frisst. | Unternehmenskultur Teil 1

Sie sind Führungskraft und wollen Ihre Mitarbeiter für agile Softwareentwicklung begeistern? Oder stecken Sie schon mittendrin und fühlen sich wie Don Quijote beim Kampf gegen die Windmühlen? Wie geht das überhaupt mit der agilen Transition? Wie viel Veränderung verträgt und erträgt ein Unternehmen – und wie schnell kriegen Sie Change nachhaltig in die Köpfe Ihres Teams?

In diesem Zusammenhang taucht immer wieder der diffuse Begriff der „Unternehmenskultur“ auf: Für die einen ein wesentlicher Erfolgsfaktor im Change Management, für die anderen nur unkonkretes Geschwätz. Gleichermaßen belächelt und beschworen polarisiert diese unsichtbare Macht wie kaum ein anderes Thema bei der Einführung agiler Methoden.

Weiterlesen

Was ist eigentlich ... eine Retrospektive?

Menschen machen Fehler. Auch Softwareentwickler. Und je komplexer das Projekt, desto höher die Fehlerquote. Die gute Nachricht: Wir können aus Fehlern lernen. Klar, hinterher ist man immer schlauer. Aber der Anglizismus „Lessons Learned“ bringt es auf den Punkt - wir müssen dieselben Fehler nicht zweimal machen. Genau deshalb ist es auch pragmatisch, mit der Nabelschau eines Projekts nicht bis zum Ende zu warten, sondern bereits projektbegleitend zu lernen und sich kontinuierlich zu verbessern. In agilen Projekten sind die sogenannten Retrospektiven Pflichtbestandteil des Projektablaufs, um Qualität und Effizienz zu erhöhen und das Team zu stärken. Aber wie läuft das genau?

Weiterlesen

Was ist eigentlich ... das Agile Manifest?

Alle Welt spricht von „Agiler Software-Entwicklung“, von Methoden wie Scrum, Kanban und Extreme Programming - aber woher kommt die agile Bewegung eigentlich? Ein wichtiger Eckpfeiler für das Verständnis von Agilität ist das „Agile Manifest“, dem wir deshalb einen eigenen Glossar-Beitrag widmen.

Weiterlesen
Markiert in: