Ja was hab ich aus dem Kurs bei Roman Pichler wirklich mitgenommen…
1. Die Erkenntnis, das es wohl was Software Entwicklung angeht, die selben oder ähnliche Probleme überall gibt, wie z.B. unscharfe Kundenspezifikationen.

2. 100% Auslastung ist evil. Entwickler, die zu mehr als 80% verplant werden verlieren an Produktivität. Dieses Prinzip ist aus der Physik in Form von Widerstandsproblemen bei Prozessoren usw. bekannt.

3. Transparenz ist wichtig. Ein Beispiel aus dem Scrum Bereich ist, das es wohl oft so ist, das eine Tafel verwendet wird, auf der die bestehenden Probleme bzw. Produktivitätsstörungen dokumentiert werden. Ziel ist, das jeder sehen kann, was gerade an Problemen da ist.  Ich glaub jeder von uns Fricklern hätte da sicherlich was drauf zu schreiben und wenn es nur um Sinnvolle Kommunikationsmöglichkeiten mit Externen oder Monate lange Wartezeiten auf benötigte Software aus dem Internet geht, die man auch per CC dort runterladen könnte. Ein gerne genommener Punkt ist hier auch warten auf irgendetwas, z.B. Internetanbindung zu schlecht, CVS zu langsam usw.

4. Scrum ohne den Einsatz Agiler Methoden wie z.B. Permanente Integration nur bedingt möglich ist, aber nicht unmöglich.

5. Es macht nur bedingt Sinn, für den einzelnen Menschen überschaubare Dimensionen zu verlassen. Beispiel kann hier die Abschätzung von Komplexität sein. Es macht Sinn sich Gedanken zu machen ob etwas in etwa 2 mal soviel Aufwand ist wie etwas anderes, es macht aber keinen Sinn zu versuchen zu ermittel, ob etwas 100 mal soviel Aufwand ist wie etwas anderes. Dabei ist allerdings vorausgesetzt, dass es keine Vergleichsgrößen gibt.
Prinzip: Wird etwas zu groß, dann teile und herrsche.

6. Was mir zwar vor dem Kurs bereits bekannt war, was mir hier mal wieder deutlich wurde, ist die Tatsache, dass die Informatik als ganzes einfach noch in den Kinderschuhen steckt und auch mental die Kunden mit Software nicht so umgehen können, wie mit Autos. Die es bereits doppelt so lange gibt und die mittlerweile derartig viele Abstraktionsschichten haben, das bekanntlich auch schon 8 jährige auf den Straßen anzutreffen sind, obwohl das wohl weder erlaubt noch zu sinnvollen Ergebnissen führt.

7. Wir machen das mal nach bestem Wissen und Gewissen ist evil! Wenn man was macht, dann muss in jedem Fall klar sein, was genau zu tun ist oder zumindest muss jemand da sein, der es weis. Es macht auch nur wenig Sinn, wenn jemand da ist, der mal schnell nachfragen muss, da so Produktivitätseinbusen hinzunehmen sind. Und wer kann sich heute sowas leisten?

Ein Paar Erfahrungen aus dem Scrumbereich sind zu finden unter:
Scrum im Leben von Jean-Pierre: Blog

Diese Woche hatte ich das Vergnügen, einen Scrum Master Zertifizierungskurs zu besuchen. Wunderbar für mich wird sich der geneigte Leser nun denken.

Aber "What the fuck is that?"

Gut also Scrum bezeichnet sich selber als Framework von Methoden, wie man Softwareentwicklung organisieren kann. Das Wort Framework ist allerdings nur bedingt zu glauben, denn sobald man einen Teil des Framework weglassen will, kommt gleich jemand und behauptet, dass man nicht mehr Scrum macht. Scrum basiert auf einigen Ideen, mit denen Probleme bisheriger Vorgehensweisen, Wasserfall is evil, beseitigt werden können. Die Ideen, die verstanden habe sind:

1. Teile und Herrsche
Um das allgemein bekannte Problem der Termintreue und der Kundenorientierung zu verbessern, wird die Aufgabe in Iterationen, wie sie aus den Agilen Methoden bekannt sind, geteilt. Das Ergebnis heißt dann "Sprint" (1-4 Wochen)

2. Tu nur was Du gerade brauchst
Just in Time Spezifizierung wird so gemacht, das die Details des Softwarestücks, das im nächsten oder übernächsten Sprint entwickelt werden sollen erst relativ kurz vor dem Sprint im Detail spezifiziert werden. Somit minimiert sich die Spezifikationsarbeit für Softwareteile, die später gar nicht mehr implementiert werden. Bei der Softwareentwicklung wird nur bedingt Rücksicht auf die Anforderungen in der Zukunft genommen, es ist wichtig, das am Ende des Tages, also am Ende des Sprints die spezifizierte Funktionalität existiert.

3. Schlanke Organisation
Im Zentrum steht ein Entwicklungsteam, das den Hit the Bus Test bestehen würde, mit 5-9 Entwicklern. Diese haben einen Teamunterstützer, explizit keinen Teamleiter, ohne Entscheidungsbefugnisse, der aber das Team berät und unterstützt bei der Beseitigung von Problemen. Er hört auf den absolut genialen Titel "Scrum Master". Die Zentrale Rolle bei dieser Form von Organisation hat der Kundenvertreter, also der nette Mensch, der Weis was dar Kunde will es dem Team beibringt. Sein Job lautet "Product Owner", er ist auch derjenige, der das Geld verwaltet und Funktionalitätsentscheidungen trifft bzw. Vertritt. Das war es auch schon. Es gibt zwar noch einige Erweiterungen für den Fall "Große und Verteilte Entwicklungsteams", hierzu werde ich allerdings erst in einem anderen Artikel zum Thema "Scrum und seine Grenzen und Probleme" was verkünden.

4. Tu was Du willst aber trage auch die Folgen
Im normalen Prozess eines Unternehmen hat man Hierarchien, die Handlungsanweisungen nach unten geben und von unten Ergebnisse bekommen, diese aber dann auch nach oben Vertreten müssen. Die Scrum spricht man von der Autorisierten Vorgehensweise. Das Team entscheidet, was sei ein einem Sprint an Aufgaben leisten können, hierbei berät sie der Scrum Master nur, aber am Ende des Sprints müssen die Ergebnisse vom Team aber auch komplett dem Kunden gegenüber verantwortet werden. Das selbe Prinzip gilt beim Product Owner. Er entscheidet für was Geld ausgegeben wird, bzw. wie das Ergebnis im Detail aussehen soll, muss das Ergebnis dann aber auch komplett dem Kunden gegenüber vertreten.

5. Das haben wir uns aber ganz anders gedacht => Der Kunde muss arbeiten
Um dieses Grundübel der Softwareentwicklung zu minimieren, wird der Kunde in den Persona des Product Owners engst möglich an die Softwareentwicklung angebunden. Dies geschieht, durch möglichst häufige Präsenz der PO beim Team für Fragen oder Teilabnahmen. Ein weiteres Mittel ist die Aufteilung des Gesamtprojekts in Teilprojekte "Sprints". Jeder Sprint wird mit einer Abnahme, "Review" der zu erledigten Arbeiten beendet und so zwischen Feedback in Hinblick auf das Gesamtprojekt gegeben.

6. Das Leben auf der Überholspur
Wer kennt das nicht, das der Kunde als solches und der Software Kunde im Besonderen immer auf der Überholspur lebt. Alles im Internet muss so schnell gehen wie Google. Wir haben heute eine Idee, das muss doch möglich sein, das bis morgen umzusetzen. Was auch gerne genommen, wird, das man Sprüche hört wie "Jetzt machen wir das mal so und können wir das ja wieder ändern.". Machen die das beim Bau eines Büroturms auch so? Um alle diese Unwägbarkeiten ein wenig mehr in den Griff zu bekommen wird eine Liste der gerade benötigten Funktionen vorgehalten und dann diese der Priorität nach abgearbeitet "Product Backlog". Da eine Detailspezifikation ja erst kurz vor der Umsetzung stattfindet und auch die Tätigkeiten eines Sprints erst vor Beginn festgelegt werden, ist dieses System hochflexibel und somit reif für die Überholspur.

7. Nachhaltigkeit
Ein großes Problem in der Softwareentwicklung ist die Nachhaltigkeit. Noch 8 Features sind offen und nur noch 1 Woche Zeit … Was leidet? Genau, Qualität und Dokumentation.
In Scrum wird deshalb die Qualität als hohes Gut angesehen und zu Gunsten von  der Anzahl der Features hochgehalten. Das sieht so aus, das man nicht mehr Features spricht, sondern von "Software Inkrementen" die aus dem Code, Tests und Dokumentation bestehen. Am Ende eines Sprints müssen Inkremente stehen, die Ausführbar sind, sonst dürfen sie nicht abgenommen werden und müssen im nächsten Sprint nochmal bearbeitet werden. Man spricht hier auch von sogenannten "Done Kriterien", die ein korrektes Inkrement definieren.

Soweit zu den Ergebnissen. Ich werde in einigen weiteren Texten mir noch weitere Gedanken machen, Themen könnten sein "Ist alles rosa mit Scrum?", "Was hab ich bei dem Kurs wirklich gelernt?", "Muss man Scrum sofort einführen?", "Scrum und seine Grenzen und Probleme"

Weitere Infos zu dem Thema findet man unter:
Scrum Sektenvereinigung : http://www.scrumalliance.org/
Scrum "Gott" 1: Mike Cohn / Blog
Scrum "Gott" 2: Roman Pichler
Scrum im Leben von Jean-Pierre: Blog