Einen Download der Präsentation findet ihr als PDF am Ende des Beitrags.
Am Montag den 02.03.2015 war ich als Speaker zu Gast an der HSR in Rapperswil um mit Studenten über das Thema “Agiles Development” und “Scrum” zu reden.
Ich bin sehr froh, dass das geklappt hat. Wir haben den Vortrag x-mal verschoben aber endlich hat es hingehauen! Vielen Dank an alle Involvierten an der Stelle.
Getting started…
Mein Ziel in diesem Talk war es, Studenten zu erzählen was Scrum ist und für was SCRUM gut ist. Sie sollten den Unterschied erkennen zwischen dem “alten” klassischen Ansatz und dem agilen Ansatz mit Scrum. Weiter wollte ich das Framework erläutern und ihnen erklären, wie man richtig “scrummt”. Mit allen Meetings, Rollen und Artefakten, die dazu gehören.
Klassik!
Hah, dieses Slide habe ich selber gemacht! (Was übrigens zu schallendem Gelächter geführt hat…). Hier sehen wir einen klassischen Ansatz der Softwareentwicklung, jedoch stark heruntergebrochen. Die Software ist vollends geplant, relativ “straight-forward” sollte sie zu Ende gebracht werden. Mit jedem Feature, das der Kunde bestellt hat und mit einem Kunden, der die Software am Ende sieht und völlig von den Socken gehauen wird, wie gut alles geklappt hat, wie schön es ist, dass jedes Feature an Board ist und der ganze Spass dann sogar noch im Preislichen Rahmen geblieben ist. Okay…das ist cool. Aber es ist absolut nicht realistisch. Software ist viel zu komplex, als dass man ein Projekt von A-Z duchplanen könnte. Was passiert, wenn eine neue Technologie herauskommt, die einem sehr viel Arbeit erleichtern könnte? Was, wenn der Kunde Änderungswünsche hat? Und die hat er! Dann haut der komplette Plan bzw. die komplette Planung für einen so riesen Zeitraum gar nicht mehr hin. Eine komplette Planung für ein Projekt ist unrealistisch.
Getting Ideas.
Die Frage, die man sich als Entwickler stellen muss, ist nicht OB man Ideen zu der Software hat, die die Software verbessert, sondern WANN man diese hat. Die Antwort ist denkbar einfach: Während des Projekts. Wir sind Software-Entwickler. Wir arbeiten an einer Sache. Wir kennen mit Scrum die Produktvision und wissen wo es hingehen soll. Natürlich haben wir Ideen während wir arbeiten.
Und der Kunde hat die auch. Ebenfalls während des Projekts. Jede vorangegangene detaillierte Planung würde ja nur heissen, dass ich meine besten Ideen schon am Anfang des Projekts hätte haben müssen. Und dann sind Ideen in der Mitte der Entwicklung nichts wert ausser Chaos weil sie jeden Plan umschmeissen würden. Scrum sagt: Ideen während des Projekts zu haben ist gut. Fast alle bringen Mehrwert für die Software. Und darum geht es. Änderungswünsche sind im Scrum willkommen. Wenn man einen Prozess hat, der mit so etwas umgehen kann, dann sind solche Feedbacks das höchste Gut. Genau diese Tür kann Scrum für uns öffnen. Änderungswünsche sind absolut willkommen und kein Störfaktor mehr.
Get Feedback
Also arbeitet man statt in einem grossen Zeitraum lieber in vielen kleinen Abständen, in Sprints. Danach holen wir uns Feedback für unsere Software, planen den nächsten Sprint und legen mit dem los. Wir implementieren einfach die Sachen, die der Kunde wirklich braucht. Komischerweise kommt am Ende vielleicht gar nicht die Software heraus, die der Kunde anfangs wollte. Aber wenn er sie mitentwickelt und er sagt, was er braucht, dann ist es am Ende genau die Softwarelösung, die der Kunde braucht. Das heisst ja nur, dass er von Anfang an eine andere Software brauchte, als er bestellt hätte. Entwickler und Kunde entwicklen das Produkt zur Laufzeit in einem ständigen Austausch, in einem Dialog. Die Kommunikation ist wohl das wichtigste dabei.
Getting better
Scrum ist empirisch. Das heisst: ¨Wir gewinnen Wissen aus Erfahrung. Das geht einmal extern, also zum Kunden hin. Wir wissen, was der Kunde will, jedes mal ein wenig mehr, trotz Produktvision. Vor allem wissen wir nach einem Feedback, was der Kunde nicht will. Sowas macht uns besser. Auch unsere Schätzungen, unsere Überlegungen werden mit der Zeit besser. Hat man sich einmal für ein Arbeitspaket verschätzt, ist es das nächst emal genauer, das nächste mal noch genauer etc.
Aber auch intern bringt Empirismus sehr sehr viel. Ein Team kann sich intern immer verbessern. Hand aufs Herz: Wir sind nicht perfekt. Deswegen läuft der Sprint auch nicht perfekt. Ein weiterer Grund um besser zu werden. Und wenn wir wissen was gut läuft: Verstärken wir es. Wenn wir wissen, was nicht so gut hinhaut: Das lassen wir im nächsten Sprint einfach wieder weg. Scrum bietet uns die Möglichkeit uns anzupassen. Haben wir beispielsweise zehn Sprints im Projekt, dann haben wir 10 mal die Möglichkeit uns zu verbessern. Das geht mit kaum einem anderen Prozess.
Das Team organisiert sich selbst
Scrum ist Teamwork. Das Team steht im absoluten Mittelpunkt von Scrum. Es ist mit allen Rechten ausgestatten und mit allen Pflichten belegt. Es muss am Ende des Sprints ein fertiges Inkrement liefern. Dafür sollte das Team alles geben. Die Methoden sind dem Team überlassen. Das ist recht einfach zu verstehen. Hier kommen aber schnell die Werte, wie beispielsweise Commitment, und Fokus, die es braucht um sich absolut fokussiert auf das zu konzentrieren, was ich gerade mache, auf den einen Sprint um am Ende etwas zu liefern, was dem Kunden wirklich etwas bringt. Das Team organisiert sich selbst. Damit hat das Team alle Hände voll zu tun!
Pläne sind nichts, Planung ist alles
Das Planungsmeeting ist nur ein Meeting im Scrum. Es stellt den Start in einen neuen Sprint dar. Es wird gefüttert mit den Inputs vom Kunden und mit den Fragen und Antworten von Entwicklern. Das wohl längste Meeting im Scrum besteht aus zwei Teilen: Im ersten Teil wird der Sprint-Backlog erstellt, im zweiten Teil werden Tasks für jedes Item, für jede UserStory oder sogar für jeden geplanten Bug erstellt. Ergebnis dieses Meetings ist ein vollständiger Sprint-Backlog, der am Scrum-Board aufgezogen werden kann.
Walt Disney
Ich liebe dieses Zitat. Es bringt auf den Punkt, was Scrum von Entwicklern verlangt. Mut. Courage. Neugierde. Probiert etwas neues. Viele vergessen, dass es bei Scrum auch darum geht die Arbeit zu verbessern. Damit meine ich auch den Spass an der Arbeit. Das Team organisiert sich selbst. Wir verbringen am Tag so viel Zeit mit unseren (lieben) Kollegen. Wieso sollten wir uns das Leben nicht angenehmer machen? Und wieso sollten wir nicht den Mut haben, Sachen auszuprobieren, an die vorher niemand gedacht hat? Geschweige denn es gewagt hat, diese zu machen? Wir haben Sprints, die verändet werden können. Wenn etwas nicht gut läuft, liegt es genauso schnell wieder raus, wie es reingekommen ist. Es geht darum, gute Arbeit abzuliefern. Dann macht Scrum auch Spass und die Leute haben Lust auf Scrum. Wir haben die Möglichkeit. Wir können es machen. Also probieren wir es doch aus?!
Redet miteinander
Software wird am Ende vom Tag immernoch von Menschen entwickelt. Das ist nunmal so. Ohne Produktvision, die eben nicht von einer ellenlangen Dokumentation kommt, ohne gleiches Verständnis, ohne kurze, direkte Entscheidungen kann keine gute Software entwickelt werden. Daher ist der Schlüssel zu all dem immer immer immer die Kommunikation. Redet miteinander! Die Kommunikation ist der Schlüssel zu der Vermeidung von vielen Problemen. Dinge, die direkt geklärt werden können: Klärt sie! Redet miteinander, anstatt E-Mails und allem, was es sonst noch gibt. 5 Minuten reden können 50 Emails ersetzen. Erster Schritt zu einem leeren Postfach 😉
Die kompletten Slides als pdf gibt es hier
