Mitgründer von Teamprove, Mittler zwischen der klassischen und agilen Welt, Informatiker,  pragmatischer Projektmanager und Prozessoptimierer, Fußball-Fan.

Design Thinking #2: Der Business-Beschleuniger

Design Thinking #2: Der Business-Beschleuniger

Was passiert, wenn man eine beruflich bunt gemischte Kleingruppe in einen hip ausgestatteten Raum mit Sofas, Whiteboards, Lego, Knete und großen Stapeln von Post-its sperrt? Vielleicht ist es die Geburtsstunde eines millionenschweren Start-ups wie „Pulse“. Vielleicht entwickelt ein renommierter Markenartikler das Trendprodukt von morgen. Vielleicht wird aber auch lediglich eine bestehende Dienstleistung optimiert. Denn neben märchenhaften Gründerstories ist das eigentlich Faszinierende an Design Thinking, dass es bei allen Unternehmenstypen, Unternehmensgrößen und Portfolios funktioniert. Ob Start-up oder Marktführer, Einzelkämpfer oder Großkonzern: Langfristig erfolgreiche Geschäftsmodelle basieren immer auf Kundennähe und der Fähigkeit, starke Ideen zu selektieren und rasch auf den Markt zu bringen.

Weiterlesen
Markiert in:

Design Thinking #1: Innovation mit Methode

Design Thinking #1: Innovation mit Methode

Von Null auf 90 Millionen Dollar in 3 Jahren? Geschafft haben das zwei Studenten – und zwar mit Hilfe von Design Thinking. Akshay Kothari und Ankit Gupta belegten 2010 den Crash-Kurs „launchpad“ an der d.school in Stanford. Die Aufgabenstellung: In 10 Wochen ein fertiges Produkt inklusive Businessmodell entwickeln. Das Ergebnis: Die App „Pulse“, ein Nachrichtenaggregator für das iPad. Nur wenige Wochen später erwähnte Steve Jobs „Pulse“ auf einer Apple Keynote, die App stürmte Platz 1 im Apple Store und gewann innerhalb von 3 Jahren über 20 Millionen Nutzer in 190 Ländern. 2013 verkauften Kothari und Gupta ihr Start-up für 90 Millionen Dollar an LinkedIn. Auch Unternehmen wie AirbnB, Google, Apple, IBM und E.ON sind (nicht nur, aber auch) durch Design Thinking so erfolgreich.

Okay, niemand kann Ihnen garantieren, dass Sie nach einem Design-Thinking-Workshop zum Millionär werden. Aber Design Thinking ist eine Denkschule, die Ihre Softwareentwicklung um eine entscheidende Komponente bereichert: den Kunden.

Weiterlesen

Was ist eigentlich… Continuous Delivery?

Was ist eigentlich… Continuous Delivery?

Neu entwickelte Software möglichst zügig ausliefern oder lieber erst ausgiebig testen? Der Spagat zwischen immer kürzeren Releasezyklen einerseits und Qualitätssicherung andererseits gießt kontinuierlich Öl auf den schwelenden Konflikt zwischen Software-Entwicklung und IT-Betrieb. Ein Konflikt, in dem beide „Parteien“ das übergeordnete – und gemeinsame – Ziel aus den Augen verlieren: die richtigen Features schnell und hochwertig zum Endkunden zu bringen und so einen Mehrwert für das Unternehmen zu generieren. In diesem Zusammenhang verspricht Continuous Delivery eine deutliche Beschleunigung, ohne Abstriche bei der Qualität und Stabilität zu machen. Aber was verbirgt sich hinter dem Begriff genau?

Weiterlesen

Unser neues Büro in München ist eröffnet!

Unser neues Büro in München ist eröffnet!

Die hohe Dichte an IT-Unternehmen im „Isar Valley“ generiert eine wachsende Nachfrage nach Dienstleistungen rund um die agile Transformation. Mit dem Teamprove-Büro in München bieten wir nun auch unseren Kunden im süddeutschen Raum eine optimale Präsenz vor Ort. Egal ob Coaching, Beratung oder Training: Gemeinsames Arbeiten und enge Begleitung sind bewährte Pfeiler der Teamprove-Philosophie. Unser zweiter Standort im Herzen der bayerischen Landeshauptstadt ist deshalb ein konsequenter Schritt, der kurze Wege, schnelle Reaktionszeiten und maximale Kundennähe gewährleistet.

So erreichen Sie uns in München:
Teamprove GmbH
Schellingstraße 109a
80798 München
Telefon: +49 89 21542026
Mail: muenchen@teamprove.de

Wir freuen uns auf Sie!

Weiterlesen
Markiert in:

abas 2016 The Global Conference: Wir sind dabei!

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:

So schreiben Sie richtig gute User Stories

So schreiben Sie richtig gute User Stories

Wenn Sie Software entwickeln, machen Sie sich regelmäßig Gedanken, wie Ihr Team mit den Wünschen, Ideen und Anforderungen des Auftraggebers umgeht. Gibt es ein Lastenheft und einen Projektplan? Arbeiten Sie sich vom Grobkonzept zum Feinkonzept? Oder arbeiten Sie schon agil? Dann kennen Sie sicherlich User Stories - eine beliebte und bewährte Variante in Scrum. Eigentlich ganz einfach: Anforderungen werden aus Nutzersicht so weit heruntergebrochen, dass sie auf eine DIN-A6-Karte passen. Trotzdem tun sich viele Teams anfangs mit User Stories schwer. Wie schreibt man also "gute" User-Stories?

Weiterlesen
Markiert in:

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

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

Teamprove-Lesetipps "Scrum"

Teamprove-Lesetipps "Scrum"

Ergänzend zu unserem letzten Artikel zum Thema Scrum haben wir noch ein wenig in unseren Bücherregalen und Linklisten gestöbert und eine kleine Leseliste empfehlenswerter Bücher und Websites rund um das Thema Scrum für Sie zusammengestellt.

Download "Scrum: Teamprove Lesetipps" (PDF / 3 Seiten / 150 KB)

Gibt es Bücher oder Links, die Sie vermissen? Dann freuen wir uns über Ihre Ergänzungsvorschläge!

Weiterlesen
Markiert in:

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

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

Wie werden wir agil? | Unternehmenskultur Teil 2

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

Frohe Weihnachten und einen guten Rutsch!

Frohe Weihnachten und einen guten Rutsch!

Das Jahr 2015 war wieder in Windeseile vorbei und Weihnachten steht vor der Tür. Auch wir legen eine kleine (Blog-)Pause ein, besorgen die letzten Geschenke, genießen einige ruhigere Tage und lassen die letzten 12 Monate Revue passieren.

Weiterlesen
Markiert in:

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

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 ... intrinsische Motivation?

Was ist eigentlich ... intrinsische Motivation?

Jedes Unternehmen wünscht sich ein motiviertes Team - das gilt auch und ganz besonders im "War of Talents" um Softwareentwickler. Aber wie schafft man das als Arbeitgeber? Eine Erkenntnis vieler Studien: Geld ist nicht alles, sondern für unsere Motivation spielen auch noch andere (häufig wichtigere) Faktoren eine Rolle. In dem Zusammenhang ist immer wieder von „intrinsischer Motivation“ die Rede – diesen wichtigen Fachbegriff nehmen wir deshalb etwas genauer unter die Lupe.

Weiterlesen

Coaching will gerlernt sein - ein Erfahrungsbericht.

Geschafft! Das Zertifikat zum „Systemischen Coach“ liegt vor mir. In die Freude über die abgeschlossene Coaching-Ausbildung mischt sich auch ein wenig Wehmut. Die letzten 6 Monate waren zwar oft anstrengend, aber immer inspirierend – und vor allem war unser Kurs eine richtig nette Truppe. Jetzt bin ich – unter anderem – Coach. Soll ich der Presse glauben, ist das nicht automatisch ein Mehrwert. Ganz nach dem Motto „Coach werden ist nicht schwer, ein guter Coach sein dagegen sehr“ wurde in den letzten Jahren ein regelrechtes Coach-Bashing betrieben.

Was hat mich also angetrieben, Zeit und Geld in diese Zusatzqualifikation zu investieren?

Weiterlesen

Was ist eigentlich ... die Engpasstheorie?

In unserem Artikel über Software-Kanban haben wir die Engpass-Theorie nur knapp angerissen – da diese für das Verständnis der Prozessoptimierung ausschlaggebend ist, greifen wir die „Theory of Constraints“ hier nochmal etwas ausführlicher auf.

Weiterlesen
Markiert in:

Lesetipp: "Entwickler, die stillen Königsmacher"

Haben Sie gerade eine Stelle für Software-Entwickler zu besetzen? Dann geht es Ihnen vermutlich wie vielen Unternehmen: Der Markt scheint leer gefegt. Und wenn Sie selbst Software-Entwickler auf der Suche nach einem neuen Job sind, haben Sie gut lachen: Sie zählen zu den aktuell meist gesuchten Experten auf dem Arbeitsmarkt für IT-Berufe. Wie schafft man es also als Arbeitgeber, dieses "rare Gut" zu begeistern?

Weiterlesen
Markiert in:

Gut geschätzt ist halb gewonnen | Aufwandsschätzung Teil 1

Programmierer sind die schlechtesten Schätzer der Welt. Behauptet zumindest Anders Abel in seinem Blog „Passion for Coding“. Der schwedische Software-Consultant geht noch weiter und präsentiert eine mathematische Formel, um die tatsächlich benötigte Zeit zu ermitteln: Man nehme die geschätzte Zeit des Entwicklers, multipliziere sie mit Pi und rechne sie in die nächsthöhere Zeiteinheit um. Schätzt der Entwickler also einen Manntag, wird er – nach Abel – 3,14 Wochen benötigen. Sicherlich eine provokant formulierte These, nichtsdestotrotz ist das Thema Aufwandsschätzung ein Dauerbrenner in der Softwareentwicklung.

Weiterlesen
Markiert in:

Beratung & Coaching: Alles in einen Topf?

 

Wie gehen Sie eigentlich vor, wenn Sie kompetente externe Unterstützung bei der Software-Entwicklung suchen? Googeln Sie eine Runde? Bitten Sie Kollegen oder Geschäftspartner um Empfehlungen? Lassen Sie sich von Werbeanzeigen in Fachmagazinen inspirieren? Wie auch immer – bestimmt werden Sie ungläubig den Kopf schütteln über die Vielzahl an Anbietern und Angeboten: Berater und Coaches, Trainer und Consultants... aber was oder wen brauchen Sie denn nun genau? 

Weiterlesen
Markiert in:

Was ist eigentlich ... ein Projekt?

Wir starten unsere Teamprove-Glossar-Reihe "Was ist eigentlich ...?" mit einer ganz grundlegenden Frage: Was ist ein Projekt genau? Rund 3.000 Mal täglich wird der Suchbegriff „Definition Projekt“ bei Google eingegeben - die Frage scheint also viele zu beschäftigen. Und das ist auch gut so, schließlich erfordert jedes Projekt ein Projektmanagement und bindet damit Ressourcen im Unternehmen. Zeit, Mitarbeiter und nicht zuletzt Geld. Es macht also durchaus Sinn, Aufgaben von echten Projekten zu unterscheiden, um nicht ständig mit Kanonen auf Spatzen zu schießen.

Weiterlesen
Markiert in: