Category Archives for "Scrum Grundlagen"

Agil und Lean übertrieben einfach

Agil und Lean - übersichtlich und einfach

Manchmal vereinfache ich gerne Dinge. Agil und Lean jemanden zu erklären, der sich noch gar nicht damit auskennt erfordert oft so eine Vereinfachung. In diesem Artikel stelle ich Ihnen einmal meine einfach übertriebene Art und Weise vor.

Agil: Kundenwert und Flexibilität

Das wichtigste für mich im Bereich von Agil ist das Inkrement. Durch das Inkrement sind Sie in der Lage wirkliche Agilität zu leben. Wenn ich wählen müsste, wäre das Inkrement genau das, was für mich den Ausschlag gibt, ob Sie Agilität vorfinden können.

Das Inkrement zahlt maßgeblich auf die Flexibilität und den Kundenmehrwert ein.​ Beide Variablen sind die, an denen z.B. Scrum das System optimiert. 

Lean: kurze Durchlaufzeit

Schauen wir uns nun ebenso übertrieben einfach einmal an, was Lean ist, dann können wir sagen, dass eine besonders kurze Durchlaufzeit maßgeblich auf alles von Lean einzahlt. Auch hier spielen weitere Faktoren mit hinein. Wenn Sie es aber schaffen eine kurze Durchlaufzeit zu erreichen, dann haben Sie vieles von Lean erreicht zu haben.

Das Scrum nicht agil sein muss und das alles agile gleich Scrum ist, lasse ich an der Stelle einmal bewusst außen vor. Ebenso können Sie natürlich auch schnelle Durchlaufzeiten erreichen ohne sich mit Lean je beschäftigt zu haben. In der Regel werden Sie aber genau diese beiden Ausprägungen vorfinden, wenn sich die Ergebnisse (Inkrement, schnelle Durchlaufzeit) in der Realität finden lassen.

Agil und Lean - einfache Schlüsselkonzepte

Lernen ist ein inhärent wichtiger Bestandteil

Egal welche Wünsche ein Kunde hat, egal was wir in ein Backlog schreiben. Wenn wir es nicht schaffen aus einem Inkrement zu lernen und uns weiterzuentwickeln, dann haben wir nichts gewonnen. Wir können dann Verbesserungen eben nicht übernehmen.

Und das geht wiederum nur, wenn das Inkrement vorhanden ist. Wenn Sie kein Inkrement erzeugen, dann sollten Sie alles daran setzen, genau damit zu starten.

Reflektieren Sie einmal ihre agil und lean Implementierungen gegen diese Aussage. Ich bin mir sicher, dass Sie dort genau solche Ausprägungen finden werden.

YouTube ScrumKurs24

ScrumKurs24 jetzt mit YouTube Kanal!

ScrumKurs24 und YouTube

Der ScrumKurs24 ist jetzt mit einem eigenen YouTube Kanal vertreten. In diesem YouTube Kanal wird es in unregelmäßigen Abständen kleine Videos zu Scrum geben. Diese Video behandeln immer genau einen Aspekt aus Scrum oder dem Umfeld von Scrum.

Ziel und Zweck

Zum einen bin ich ein Fan von Videos im Ausbildungsbereich. Zum anderen denke ich, dass es eine gute Möglichkeit darstellt, Wissen über einen visuellen Kanal mit aufzunehmen. Ich möchte so die Möglichkeit geben, neben den hier existierenden Artikeln auch bewegte Informationen rund um Scrum darzustellen. Sie können sich den Kanal abonnieren und ganz kostenlos ansehen.

Fokus

Fokus ist nicht nur ein Scrum-Wert, sondern stand auch Pate für meine YouTube Videos: keines dieser Videos ist länger als 2:30min! So ist es möglich, den passenden Bereich herauszugreifen und in sehr kurzer Zeit das Wichtigste sich anschauen zu können.

Erklärstil

Die Videos sind alle im sogenannten „Erklärstil“ oder auch „Explainer-Video“ erstellt. Dabei sehen Sie praktisch, wie sich ein Whiteboard füllt und können der Hand folgende, die das schreibt. Diese Art der Produktion lässt den Aufwand in Grenzen halten, im Gegensatz zu Videos bei denen ich zum Beispiel selbst vor der Kamera stehen würde.

Nun wünsche ich aber viel Spaß mit meinem neuen YouTube Kanal! Schreiben Sie mir doch einfach, welche Videos Sie gerne noch sehen würden!

Nutzen Sie das Sprint Ziel richtig!

Das Sprint Ziel in Scrum

Scrum Entwicklungsteam Sprint ZielDas Sprint Ziel definiert den Nutzen, den ein Produktinkrement am Ende des Sprint erreicht. Das Sprint Ziel wird allerdings so definiert, dass es nicht die Summe der umzusetzenden User Stories ist. Ein Sprint Ziel schreibt den Nutzen des Produktinkrements in einer abstrakten Form, so ist es möglich das Sprint Ziel zu erreichen, auch wenn z.B. eine User Story getauscht wurde oder nicht umgesetzt wurden konnte.

Das Entwicklungsteam und der Product Owner definieren

Das Entwicklungsteam und der Product Onwer definieren gemeinsam das Sprint Ziel. Dabei gehen die Teams in der Regel so vor, dass der Product Owner ein solches Ziel als Vorschlag mit in das Team bringt. Dann wird mit dem Entwicklungsteam darüber diskutiert und im besten Falle gleich übernommen. Es kann auch vorkommen, dass das Entwicklungsteam kleine Anmerkungen hat oder das Sprint als utopisch ansieht – dann muss in die Verhandlung mit dem Product Owner gegangen werden. Das Sprint Ziel wird während des Sprints nicht verändert.

Das Sprint Ziel am Sprint Board

Sprint BacklogDas Sprint Ziel wird immer zum Sprint Backlog gehängt. Das hilft zum einen sehr im Sinne der Visualisierung – das Team schaut zwangsläufig immer jeden Tag (zu Beispiel im Daily Scrum) auf dieses Ziel und wird erinnert. Ach wenn dieser Aspekt oft als „lächerlich“ oder „überflüssig“ angesehen wird, ist es in meinen Augen sehr entscheidend.

Zudem kann das Team so auch viel besser die drei Fragen im Daily Scrum auf dieses Sprint Ziel beziehen.

Sprint Ziel kann nicht erreicht werden

Scrum Sprint PlanningEs kann durchaus auch vorkommen, dass ein Sprint Ziel einmal nicht erreicht wird. Das sollte immer die Ausnahme bleiben und ebenso in der Retrospektive ausführlich untersucht werden. Nehmen wir an das Scrum Entwicklungsteam hat sich komplett verschätzt und das Ziel des laufenden Sprints ist jetzt schon nicht mehr erreichbar. Dann kann und sollte der Sprint durch den Product Owner abgebrochen werden. Auch der Product Owner kann durch eine Änderung der Anforderungen und andere wirtschaftliche Entscheidungen sich dazu genötigt sehen, das Sprint Ziel einzustellen, da es nicht mehr zu erreichen ist.

Der Sprint wird in diesem Falle abgebrochen. Es ist besser den aktuellen Sprint abzubrechen, als ihn zu Ende zu führen, obwohl wir wissen, dass das Ziel nicht mehr erreicht werden kann.

Beispiele

Wenn Sie Ziele zum ersten Mal aufstellen wollen, suchen Sie in der Regel eine Vorlage, ein Beispiel – kurz: wie machen es denn eigentlich andere? So ein Ziel könnte lauten: Ersten haptischen Prototypen für das neue Navigationsgerät erstellen, die Loginfunktionalität des Portals etablieren oder auch den Umgang mit Scrum lernen. Sie sehen schon, dass das Ziel ganz unterschiedlich sein kann. Nur eines sollte es eben nicht sein: eine einfache Wiederholung von Anforderungen / Product Backlog Einträgen.

Sie können sich nun bestimmt auch vorstellen, dass das im Sprint definierte Ziel als eine kleine Vision für den Sprint gilt. Es ist konkret genug eine Richtung festzulegen, aber noch so abstrakt, dass Sie sich für oder gegen Eigenschaften des Produktes entscheiden können.

Es ist nun vollkommend ausreichend, wenn Sie dieses Ziel am Sprint Backlog des Team festhalten. So kann jedes einzelne Teammitglied aus dem Entwicklungsteam tagtäglich seine Arbeit gegen eben dieses Ziel reflektieren!

4

Scrum Werte als Grundlage

Scrum Werte

Die Scrum Werte existieren schon lange, nämlich seit dem ersten Buch von Ken Schwaber und Mike Beedle Agile Software Development with Scrum. Dort wurde fünf Werte definiert: Mut, Commitment, Fokus, Offenheit und Respekt. Diese Scrum Werte stellen die Basis für den Umgang mit Scrum dar. Die Werte erlauben eine gute Reflexionsmöglichkeit und nach wie vor finden sich bei nicht ganz rundlaufenden Scrum Implementierungen die Probleme tatsächlich in diesen Scrum Werten begraben. Zeit, sich diesen Werten einmal genauer zu nähern und diese zu analysieren.

Was sind Werte?

Schauen wir uns kur an, was Werte eigentlich sind, um dann diese Definition mit unseren Scrum Werten in Beziehung zu setzen. Wikipedia schreibt dazu:

Wertvorstellungen oder kurz Werte bezeichnen im allgemeinen Sprachgebrauch als erstrebenswert oder moralisch gut betrachtete Eigenschaften bzw. Qualitäten, die Objekten, Ideen, praktischen bzw. sittlichen Idealen, Sachverhalten, Handlungsmustern, Charaktereigenschaften beigelegt werden.

Wikipedia

Ich finde die Aussage „[…]erstrebenswerte oder moralisch gut betrachtete Eigenschaft[…]“ in diesem Zusammenhang sehr treffend. Ich denke das diese Werte anzustreben sind, denn nur wenn sich innerhalb des Teams oder oder der Organisation diese Scrum Werte richtig etabliert haben, ist auch die Scrum Implementierung erfolgreich. Wir müssen im Scrum Umfeld diese Werte also erstreben, damit wir eine gute Basis für eine gute Scrum Implementierung haben.

Bei diesen Scrum Werten müssen wir zusätzlich noch etwas im Kopf haben, das Unterschiedliche Kulturen Werte sehr unterschiedlich interpretieren können. In Asien wird ein Wert Commitment anders interpretiert, als wir das in Europa kennen. Bei sämtlichen Betrachtungen dieser Werte, darf man das nicht außer Acht lassen.

Commitment

Scrum Werte - CommitmentDen Scrum Wert Commitment zu übersetzen finde ich immer etwas schwierig. Ich orientiere mich dabei gerne an einer Verpflichtung. Sehr oft findet sich das Wort Commitment im Deutschen ebenso, die Bedeutung schwankt aber durchaus in Extremen.

Das Team in Scrum verpflichtet sich auf eine zu entwickelnde Funktionalität und Arbeitsumfang in einem Sprint. Es committed sich damit praktisch auf das, was es zusagt. Das ist ganz elementar. Das ist einer der Scrum Werte, der in Teams dann zum Beispiel nicht umgesetzt ist, wenn Teams immer wieder die zugesagten Product Backlog Items (PBI) in den nächsten Sprint schieben.

Der Volksmund sagt gerne auch „wenn ich etwas sage, dann mache ich es auch!“ – auch das ist letztendlich genau das, was mit diesem Commitment auch gemeint ist. Natürlich kann es immer mal passieren, dass diese Selbstverpflichtung nicht erreicht wird, dann sollte in der Retrospektive ein genauer Blick auf diesen Sachverhalt geworfen werden.

Fokus

Produktinkrement in ScrumFokus ist ein Wert, den heute – gerade in der digitalen Zeit – immer weniger Menschen wirklich besitzen. Es ist nicht leicht, sich auf eine Sache zu konzentrieren, diese abzuschließen und sich nicht zu verzetteln. Große Aufgaben werden zerkleinert und in Stücke bearbeitet, die es erlauben den Fokus auf genau diesen auch zu behalten. Wenn wir Aufgaben haben, die klar und klein sind, dann können wir den Fokus recht gut behalten und diese auch abschließend umsetzen.

In Scrum gibt es mit Meetings wie dem Daily Scrum auch eine gute Möglichkeit den Fokus auf der täglichen Arbeit zu behalten. Diese Visualisierungen in Scrum führen ebenso dazu, klar herauszustellen woran gerade gearbeitet wird und wo somit der Fokus im Projekt liegt.

Offenheit

Daily Scrum KommunikationOffenheit finde ich ebenso einen nicht ganz einfachen Werte der Scrum Werte. Offenheit muss immer im Verhältnis gesehen werden, denn sich komplett zu offenbaren will wahrscheinlich niemand und alles transparent zu machen auch nicht. Deshalb kommt es bei Offenheit auch und gerade auf das Verhältnis an.

Jeder einzelne im Scrum Team sollte offen und neugierig gegenüber neuen Techniken und Praktiken sein. Ebenso muss ich Konflikte offen und ehrlich auch ansprechen können und wollen.

Ein Stück weiter, dann sind wir bei der Transparenz, die sich auf den Arbeitsfortschritt und die Artefakte in Scrum bezieht.

Respekt

Scrum ZertifizierungenRespekt finde ich nicht nur in Scrum wichtig, sondern ist für mich ein ganz grundlegender Wert. Wenn wir mit anderen zusammenarbeiten, dann haben wir alle unterschiedliche Meinungen und Sichtweisen. Das ist wichtig und ganz elementar – gerade in Scrum.

Wir brauchen für den Wert Respekt einen Umgang miteinander, der es erlaubt mit unterschiedlichen Meinungen umgehen zu können und auch Stärken und Schwächen angemessen zu behandeln.

Mut

Scrum Werte - MutMut ist wichtig wenn wir neue Wege gehen wollen, wenn wir in unbeständigen Märkten unterwegs sind und komplexe Produkte entwickeln wollen. Ohne Mut verlassen wir keine alten, eingetretenen Wege und entdecken auch wenig neues. Doch nicht nur in Hinsicht auf das zu entwickelnde Produkt braucht es Mut, sondern auch für die eigene Organisation. Wer aus klassischen Organisationen mit starken Hierarchien kommt, muss mehr Mut beweisen, wenn er andere Wege gehen will. Innerhalb einer Organisation Neues zu versuchen bedarf ebenso mehr Mut – neue (höher in der Hierarchie angesiedelte ) Menschen müssen befragt und überzeugt werden und gerade die „Extra Mile“ muss mehr und mehr gegangen werden.

 

 

11

Was ist Scrum? (und was ist es eben nicht!)

Was ist Scrum? Darum geht es!

was ist scrum

Was ist Scrum? Scrum wird als agiles Projektmanagement Framework bezeichnet. Scrum erlaubt es mit wenig Regeln und Artefakten komplexe Produkte zu entwickeln. Dabei kann Scrum in den unterschiedlichsten Branchen und Situationen angewendet werden. Dieses Framework gibt Ihnen einen groben Rahmen an die Hand, in dem entwickelt wird. Den eigentlichen Prozess aus dem Framework ableiten, das müssen Sie selbst.

Ursprünge von Scrum finden sich bereits 1986 in dem Paper The New New Product Development Game der beiden Japaner Takeuchi und Nonaka, in dem Grundzüge von dem betrachtet wurden, was heute inhärent in Scrum enthalten ist. Niemand hat sich zu dem Zeitpunkt gefragt, was ist Scrum! Das überraschende aus heutiger Sicht ist mit Sicherheit, dass es in diesem Paper nicht um Softwareentwicklung ging! Die erste Software, die mit Scrum erstellt wurde, erblickte 1993 das Licht der Welt. 1995 formalisierte Jeff Sutherland auf der OOPSLA’95 den Scrum Prozess und stellte ihn vor.

2001 entstand das agile Manifest, das praktisch die Grundlage von allen agilen Methoden bildet. In diesem Manifest befinden sich vier Wertepaare und zwölf Prinzipien, die in der eigenen Organisation interpretiert und verstanden wollen werden. Ein Jahr später erschien das erste Buch zu Scrum. Im Jahre 2013 erschien der erste Scrum Guide, der bis heute gepflegt wird.

agiles manifest

Während früher der Scrum Fokus auf der Software lag, ist heute längst bewiesen, das Scrum in vielen Bereichen – auch Hardware oder dem Marketing – funktioniert und Vorteile bringt.

Doch was ist Scrum genau?

Scrum Werte

Die fünf Scrum Werte gehören sicherlich dazu, wenn es um die Frage geht, was Scrum ist! Denn diese Scrum Werte sind praktisch gesehen die Basis auf der Scrum aufbaut. Die Scrum Werte sind ebenso im letzten Update des Scrum Guide eingezogen, auch wenn diese schon seid dem Buch von Jeff Sutherland und Mike Beedle 2002 existierten.

  • Mut
  • Commitment
  • Fokus
  • Respekt
  • Offenheit

Das Framework

Scrum kennt drei Rollen: den Scrum Master, den Product Owner und das Entwicklungsteam. Dazu kommen drei Artefakte, nämlich das Product Backlog, das Sprint Backlog und das Inkrement. Mit fünf Events ist dann das Framework komplett, das wären der Sprint, das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive.

Das ist letztendlich auch das, was Scrum ausmacht. Mehr braucht es erstmal nicht, um komplexe Produkte zu entwickeln. Aber dieses Framework bildet auch nur den Rahmen. Scrum macht zum Beispiel keine Angaben darüber, wie Software zu entwickeln ist, welche Teststrategien Sie fahren sollten oder gar Angaben über Tools. Alles das ist Ihre Aufgabe, wenn Sie Scrum implementieren!

Die Rollen

Die eben angesprochenen Rollen sind im folgenden etwas genauer, aber dennoch abstrakt dargestellt. Auf die einzelnen Rollen gehe ich in separaten Artikeln ein, für das Verständnis soll es zunächst auf dieser Ebene ausreichen.

Scrum Master

Der Scrum Master

Der Scrum Master ist der Hüter des Prozesses. Er ist derjenige, der sicherstellt, dass alle Scrum so benutzen können, wie es vorgesehen ist. Er moderiert Meetings und hilft beim Coaching des Teams.

Scrum Product Owner

Der Product Owner

Der Product Owner bringt die fachlichen Anforderungen („was“) mit in das Team. Er ist derjenige der wirtschaftlich für das Produkt verantwortlich ist. Er stimmt sich mit den Stakeholdern ab und kennt das Produkt.

Scrum Entwicklungsteam

Das Entwicklungsteam

Das Entwicklungsteam setzt das Produkt um („wie“). Es besteht aus Mitgliedern, die in Summe alle Fähigkeiten haben, das gewünschte Produkt auch umzusetzen.

Die Artefakte

Scrum Product Backlog

Das Product Backlog

Das Product Backlog ist die einzige Liste an Anforderungen (also so eine Art Wunschzettel) was das Produkt enthalten soll. Diese stellt den aktuellen Kenntnisstand dar und ist niemals abgeschlossen, sondern bewusst lebendig.

Sprint Backlog

Das Sprint Backlog

Das Sprint Backlog enthält das, was sich das Team für den aktuellen Sprint vorgenommen hat. Es stellt damit eine Teilmenge des Product Backlogs dar und führt zu einem Inkrement.

Produktinkrement in Scrum

Das Inkrement

Das Produkt(Inkrement) wird am Ende eines Sprints immer vorgeführt und zeigt den Stakeholdern und dem Product Owner eine funktionierendes Inkrement des zu entwickelnden Produktes, das live erlebt werden kann.

Die Events

Die Events sind die vier existierende Meeting und der Sprint. Das Backlog Refinement wird im Scrum Guide nicht als einzelnes Meeting aufgeführt. Meine Erfahrungen zeigen, es macht sehr wohl Sinn das als solches wie die anderen Meetings zu etablieren. Deshalb führe ich es hier mit den Events auf und Sie finden sechs, statt fünf Events hier.

Sprint Scrum

Der Sprint

Der Sprint stellt den zeitlichen Rahmen zur Verfügung, in dem Scrum durchgeführt wird. Dieser hat eine feste Länge und immer einen definierten Start- und Endpunkt. Grundsätzlich wird ein Sprint in der Länge nicht verändert.

Scrum Sprint Planning

Das Sprint Planning

In der Sprint Planung wird festgelegt, was in dem kommenden Sprint umgesetzt wird. Dabei wird das Planning in zwei Teile aufgeteilt: einem ersten Teil der beschreibt, „was“ umgesetzt werden soll und einem zweiten Teil der beschreibt, „wie“ etwas umgesetzt werden soll.

Daily Scrum Kommunikation

Das Daily Scrum

Das Daily Scrum dient der Entwicklung für ein kurzes Statusmeeting in dem jedes Teammitglied die anderen Teammitglieder mit drei kurzen Fragen auf den aktuellen Stand bringt. Der Scrum Master sammelt hier erste mögliche Hindernisse (Impediments) ein.

Sprint Review

Das Sprint Review

Im Sprint Review wird auf das Erreichte im im Sprint zurückgeblickt und alles was funktioniert und fertig wurde vorgestellt. Wichtig dabei ist die Definition of Ready. Sie regelt, wann ein Eintrag aus dem Backlog als fertig gilt.

Retrospektive

Die Sprint Retrospektive

In der Sprint Retrospektive wird der aktuelle Sprint hinsichtlich Zusammenarbeit, Infrastruktur, … (grob: der Prozess) betrachtet und Verbesserungen abgeleitet. Eine Verbesserung wird im nächsten Sprint angegangen und versucht umzusetzen.

Backlog Refinement Toolbox

Das Backlog Refinement

Im Backlog Refinement werden die Anforderungen aus dem Backlog verfeinert. Dabei werden diese geschnitten, geschätzt und mit Akzeptanzkriterien versehen.

Was gibt es sonst noch in Scrum?

Scrum Vision

Die (Produkt) Vision

Die Vision wird zusammen mit dem Kunden erarbeitet und skizziert ganz grob, wo das Vorhaben hingehen soll. Dabei gibt es unterschiedliche Möglichkeiten eine solche Vision zu visualisieren. Oft wird ein klassisches Flipchart mit vier Sätzen gebildet, oft aber auch eine Art Canvas mit einer Struktur genutzt. Wichtig ist, aus der Vision wird das Product Backlog abgeleitet.

Impediment list

Impediment List

Die Impediment List – eine Liste mit allen Hindernissen – wird vom Scrum Master gepflegt und abgearbeitet. Diese Hindernisse behindern das Team an einer optimalen Arbeitsweise. Folglich können die Hindernisse auch unterschiedlicher Natur sein.

DoR DoD

Definition of Done

Die Definition of Done beschreibt wann ein Eintrag als erledigt gilt. Dabei kann es durchaus auf verschiedenen Ebenen mehrerer solcher DoD’s geben. Sie wird vom Team und Product Owner zusammen definiert und festgeschrieben.

DoR DoD

Definition of Ready

Die Definition of Ready beschreibt, wann ein Eintrag aus dem Backlog fertig für die Planung ist. Das wird zwischen dem Product Owner und dem Team definiert und festgelegt.

Was ist Scrum und was eben nicht?

Bis jetzt haben wir nun einen ersten Eindruck davon, was ist Scrum. Wichtig ist es aber auch ein Augenmerk darauf zu legen, was Scrum eben nicht ist. Hier zeige ich gerne mal meine favorisierten Aussagen, die natürlich etwas plakativ und überspitzt dargestellt werden, aber vom Grundsatz so vorgekommen sind.

Scrum ist ein Plug & Play für das Projektmanagement

Scrum anzuwenden bedeutet sich mit Veränderungen im Unternehmen zu beschäftigen. Es geht nicht darum eine Änderung einer Methode vorzunehmen und alles funktioniert so wie bisher auch. Scrum ist mal nicht ebenso gemacht. Natürlich lässt sich ein Buch zu Scrum am Wochenende durchlesen, aber die korrekte, effektive und effiziente Anwendung dauert Jahre.

Scrum ist ein Silverbullet und ermöglicht phänomenale Einsparungen

Scrum funktioniert überall dort gut, wo Sie komplexe Produkte entwickeln wollen oder müssen. Wenn Sie zum Beispiel das Gegenteil (einfache oder komplizierte Produkte) entwickeln, können Sie natürlich auch Scrum machen, werden aber nicht die Vorteile erzielen, wie wenn Sie komplexe Produkte entwickeln. Ebenso ist Scrum sehr auf das Team und die Transparenz ausgelegt und ständige Verbesserung. Haben Sie diese Grundlagen nicht, wird Scrum nicht wie angedacht funktionieren.

Planung und Dokumentation benötigen wir nicht mehr in Scrum

Ein Klassiker, der sich zum Glück schon weit wieder verflüchtigt hat, trotzdem aber noch vorkommt und das vor allem indirekt in vielen Fragen mitschwingt. Scrum ist ein sehr disziplinierter Ansatz und hat eine sehr genaue Planung und Scrum selbst sagt über die Dokumentation erst einmal gar nichts aus. Der Wert aus dem agilen Manifest „Working Software over comprehensive Documentation“ hat scheinbar zu dieser irren Annahme geführt. Er wird gerne so interpretiert, dass nur Software ohne Dokumentation zu erstellen ist.

Was ist Scrum für Sie?

Wie sehen Sie das Thema Scrm für sich? Was wäre, wenn ich Ihnen die Frage stellen würde, „was ist Scrum?“ – wie lautet dann Ihre Antwort? Gerne in den Kommentaren!