Nachhaltigkeit beginnt ganz vorne ...

futureloungeday
… 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:

„Modern Agile“ auf der Agile World Konferenz 2017

titel_agile_skalierung
Immer wieder werde ich nach speziellem Know-how in Skalierungsframeworks wie SAFe, LeSS, Nexus usw. gefragt. Natürlich kennen wir uns bei Teamprove auch damit aus. Aber geht es wirklich nur darum, die geeignete Blaupause auszuwählen -  und voilà, schon funktioniert das agile Großprojekt oder die agile Transition? Offensichtlich nicht, denn sonst würden sich nicht so viele Unternehmen so schwer damit tun. „A fool with a tool is still a fool“: Dieser bekannte Satz bringt es auf den Punkt, wenn sich Diskussionen um das geeignetste agile Framework festbeißen. Diese Entwicklung war auch auf der diesjährigen Agile World Konferenz in München deutlich zu spüren.
Weiterlesen

Was ist eigentlich ... Definition of Done (DoD)?

definition-of-done

Kennen Sie die Situation: In Meetings erhalten Sie vom Team Aussagen wie „Dieser Task ist so gut wie erledigt“ oder „Die User Story ist eigentlich fast fertig“. Wunderbar, alles „in time“ – doch am Ende des Sprints stellen Sie erstaunt fest, dass nur ein Teil der User Stories lieferbar ist. Das Problem: Ob ein Inkrement fertig ist, wird von verschiedenen Personen sehr unterschiedlich definiert und interpretiert. Woher wissen Sie also, wann eine Aufgabe wirklich abgeschlossen ist? Was erwarten Kollegen oder der Product Owner? Um langwierige Diskussionen und unliebsame Überraschungen zu vermeiden, gibt es in agilen Teams das Artefakt „Definition of Done“ oder kurz „DoD“.

Weiterlesen

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

Wie Teams agil werden

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

Frohe Weihnachten und einen guten Start ins neue Jahr!

Frohe Weihnachten und einen guten Start ins neue Jahr!
In wenigen Tagen ist Weihnachten und wieder geht ein ereignisreiches Jahr zu Ende. Die wichtigsten Milestones der letzten Monate hatten wir bereits in unserem Artikel zum 4. Teamprove-Geburtstag zusammengefasst. Anfang Dezember haben wir nun auch unsere Münchner Niederlassung eröffnet und freuen uns auf interessante Neukunden aus dem süddeutschen Raum. So bleibt es auch 2017 garantiert spannend!

Liebe Leser, Kunden, Geschäftspartner und Freunde, wir wünschen Ihnen und Ihren Familien frohe Weihnachten, erholsame Urlaubstage und einen guten Rutsch! Ab 9. Januar sind wir wieder für Sie da.

Herzlichst
Ihr Teamprove-Team
Weiterlesen

Alles agil oder doch nicht?

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

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:

Was ist eigentlich… DevOps?

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

4 Jahre Teamprove: ein neuer Look zum Geburtstag

4 Jahre Teamprove: ein neuer Look zum Geburtstag
Peinlich, peinlich … wir haben Ende Juli unseren eigenen Geburtstag vergessen! Tatsächlich ist unser „Baby“ Teamprove mittlerweile schon über 4 Jahre alt – fast bin ich versucht zu sagen: „Mensch, bist du aber groß geworden!“ Vier Jahre voll gepackt mit interessanten Projekten, tollen Kunden und spannenden Herausforderungen.
Weiterlesen
Markiert in:

MbO 2.0: Mit OKR zum Agile Leadership

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!

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:

Lean Startup: Küss den Frosch!

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

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.

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

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