Software Engineering Blog

Mit seinem ersten Buch "Scrum - Agiles Projektmanagement erfolgreich einsetzen", hat Roman Pichler ein für die deutsche Scrum-Gemeinde wichtiges Buch geschrieben. Was mir an dem Buch besonders gut gefällt, ist der präzise Stil mit dem Pichler die wichtigen Grundlagen von Scrum erklärt, sodaß man das Gefühl hat sofort loslegen zu können, auch wenn dem vielleicht gar nicht so sein mag. Wer sich intensiver mit Scrum beschäftigt hat merkt, das Scrum und seine Grundlagen viel weiter reichen, als es auf den ersten Blick erscheint. Aber das ist ein anderes Thema.

Jetzt gibt es ein neues Buch von Roman Pichler: "Agile Product Management with Scrum", das zuerst auf Englisch bei Addison-Wesley erscheint, da Pichler mittlerweise in Großbritannien lebt. Eine deutsche Übersetzung ist bereits angekündigt und ich hoffe, daß diese von Pichler selber vorgenommen wurde.

Thema des Buches ist agiles Produktmanagement (Produktpolitik). Also all die Tätigkeiten, die bei einer Produktentwicklung notwendig sind, um ein Produkt erfolgreich weiterzuentwickeln.

Leider kann ich noch nicht allzuviel zum Buch selber sagen, da ich es erst heute bestellt habe und nach Angaben von Amazon die Lieferung erst im Mai erfolgen soll. Empfehlen kann ich aber in dem Zusammenhang "Management von IT-Produkten", auf das ich in diesem Blog-Artikel schon einmal hingewiesen habe. Das Buch gibt einen sehr guten Überblick über alle notwendigen Tätigkeiten im Umfeld von IT-Produkten. Der Anspruch des Buches dabei ist es eine Einführung in die Grundlagen zusammen mit einem theoretischen Überblick zu geben. Das gelingt den Autoren auch sehr gut, vorallem da sie sich bewußt sind, daß dies nur die Grundlage für eigenes Handeln sein kann. Pichlers Buch könnte da eine gute Ergänzung sein.

Vor ein paar Tagen habe ich ja schon einmal den Vortrag von Alan Atlas über die Einführung von Scrum bei Amazon berichtet, über die der bei ImmobilienScout24 gesprochen hat.

Marion Eickmann von agile42 hat Altas kurz danach zum Berliner Scrumtisch eingeladen und das auch in ihrem Blog mit Fotos dokumentiert. Aus dem Blog heraus kann man auch die Präsentation herunterladen.

Isabel Drost hat sich die Zeit genommen und Atlas' Vortrag in Ihren Blog ausführlich dokumentiert.

Gestern bin ich auf dem Scrum-Symposium hier in Berlin von ImmobilienScout24 gewesen und hatte die Möglichkeit zwei Vorträge über Scrum in der Praxis zu hören. Der erste beschäftigte sich mit Scrum bei ImmobilienScout24. Leider habe ich dank der vereisten Berliner Straßen das meiste davon verpaßt. Der zweite wurde Vortrag an diesem Abend wurde von Alan Atlas gehalten, der bei Amazon die Webservices-Sparte (mit?) aufgebaut hat. Altas erzählte auf eine sehr unterhaltsame Art und Weise, wie er bei Amazon Scrum eingeführt hat. Eine kurze Zusammenfassung kann hier gefunden werden.

Was aber für mich wieder am interessantesten zu beobachten war, war daß in den Fragerunden, fast egal wo man ist, immer wieder die gleichen Fragen auftauchen. Wie gehe ich mit dem Testen um? Wie plane ich richtig und auch über längere Zeiträume? Wo bleibt der Architekt und was macht er? Wie tue ich dies oder jenes? Warum sagt und Scrum nicht, wie wir das zu tun haben? Einige Punkte hierzu werden von auch von Uncle Bob angesprochen oder auf XING in der Scrum-Gruppe diskutiert.

Der Kern von Scrum

Scrum hat kein Problem. Das was einige für ein Problem halten, ist die Grundeigentschaft von Scrum. Scrum ist wie viele agile Prozesse schlank aufgestellt und bringt nur wenige Regeln mit. Doch wir wollen an die Hand genommen werden und in Sicherheit sein, in dem wir die Regeln befolgen, die es gibt. Gibt es diese nicht, fühlen wir uns unsicher.

Bleibt also die Frage, was Scrum ist, wenn es uns doch keine Antwort auf alle Fragen in jeder Situation ist?

Scrum kann ganz einfach auf folgendes heruntergebrochen werden:

• Scrum ist Selbstorganisation. Wir sind angehalten uns selber die Regel zu geben, die wir für richtig halten.
• Scrum ist Kommunikation. Dadurch sollen wir anfangen uns auszutauschen, gemeinsam Probleme zu lösen und Wissen zu verteilen.
• Scrum ist kontinuierliche Verbesserung. Probleme sollen nicht auf die lange Bank geschoben werden, sondern aktiv gelöst.

Dafür gibt uns Scrum ein Rahmenwerk mit ein paar Regeln und Rollen. Umsetzen müssen wir es. Das ist schwer, aber auch sehr spannend.

Ein Freund meinte einmal zu mir, daß das doch alles "gesunder Menschenverstand" sei. Sicherlich ja, aber beherzigen wir den auch immer?

Seit letzter Woche bin ich Certified ScrumMaster und damit von der Scrum Alliance berechtigt, "to transform the world of work".

How the Mighty Fall ist ein Buch von Jim Collins, der darin den Aufstieg und Fall von großen Unternehmen beschreibt und das erinnert mich gerade an Toyota.

Zur Erinnerung: Toyota hat diese Woche eine große Rückrufaktion für seine Wagen aufgrung von defekten Gaspedalen gestartet und im Rahmen der Wirtschaftskrise sich auf dem US-amerikanischen Markt übernommen.

Toyota? Die Firma, deren Management- und Produktionsmethoden nicht unberechtigt auch auf die agile Softwareentwicklungsbewegung großen Einfluß ausgeübt hat? Ich möchte hier nur einmal an Scrum und Kanban erinnern.

Wie kann das sein? Toyota wird wie soviele Unternehmen irgendwann seinem Erfolg erlegen sein und wollte in zu kurzer Zeit zu viel erreichen. Den auch in der Softwareentwicklung wissen wir, daß Zeitdruck und der Zwang zum Erfolg meist eine adversen Effekt hat und jedes System nur mit der ihm eigenen Geschwindigkeit wachsen kann.

Auch wenn manche schon vom Ende von Toyota sprechen, wird es dazu nicht so schnell kommen, denn nicht jede Krise bedeutet das Ende. Vielmehr ist die Frage immer, ob aus Krisen die richtigen Schlußfolgerungen gezogen und auch umgesetzt werden.

Alexander Kriegisch von Scrum-Master.de hat dem "Scrum on a Page" von William c. Wake aktualisiert und über seine Homepage uns allen zur Verfügung gestellt.

Scrum-On-A-Page faßt kurz für den täglichen Gebrauch die Scrum-Rollen, den Prozess und die wichtigsten Inhalte der Meetings und die Scrum-Artefakte zusammen.

Hier geht es zum Download...

Im PM Blog habe ich einen interessanten Verweis auf einen Vortrag von Jurgen Apello auf der Agile Eastern Europe conference in Kiew gefunden, der nach meiner Ansicht wunderbar die wesentlichen Prinzipien zusammenfaßt, mit der Software-Entwicklungs-Teams geführt werden sollten.

Jurgen Appelo, "So Now You’re an Agilist. What’s Next?", Agileee conference, 2009 from Alexey Krivitsky on Vimeo.

Für alle aus dem Raum Berlin und an Scrum-Interessierte dürfte interessant sein, daß die OOSE im nächsten Jahr auch ein Scrum-Master-Seminar mit der Möglichkeit zur Zertifizierung in Berlin durchführt. Für mich auf jeden Fall die Gelegenheit, mich als Scrum Master zertifizieren zu lassen, ohne nach Hamburg zu fahren. Eigentlich aber auch schade.

Hier geht es zur Anmeldung für das Berliner Seminar.

Diese Tage findet in Berlin eine Konferenz zum Thema agiles Softwaretesting statt, wodurch der Berliner Scrum-Stammtisch die Möglichkeit hatte Mary Poppendieck einzuladen und ich Marry Poppendieck kennenzulernen.

Marry Poppendieck ist durch ihre Arbeiten zu Lean Software Development mit Büchern wie Lean Development Software: An Agile Toolkit for Software Development Managers und Leading Lean Software Development: Results Are Not the Point bekannt geworden. Dementsprechend war das Thema des Abends gesetzt: Lean Software Development – What Lean Brings to Agile. Die Vortragsfolien können im Blog-Eintrag von agile.42 gefunden werden.

Inhaltlich kann ich dem an diesen Abend gesagten voll zustimmen, auch wenn es mir auf den ersten Blick schwerfällt, Lean von Agile im praktischen Leben abzugrenzen, den die Schnittmenge zwischem beiden dürfte in der Realität, dort wo Agilität wirklich gelebt wird, sehr hoch zu sein. Höchtens vielleicht so: Agile sagt uns wie wir etwas tun können, Lean sagt uns, was wir zu tun haben. Oder auch umgekehrt.

Die Ähnlichkeit zwischen Lean und Agile wird an Poppendiecks vier Lean-Merkmalen deutlich:

Lean in a Nutshell

1. System Thinking - Customers don’t want software.
2. Technical Excellence - Correctness can be proven at any time.
3. Reliable Delivery - Design the system to meet the constraints.
4. Relentless Improvement - Learn how to learn.

Wie Lean funktionieren kann, hat Marry Poppendieck sehr gut am Beispiel des Empire State Buildings dargelegt, das in weniger als eineinhalb Jahren gebaut wurde.

Insgesamt ein sehr interessanter Abend, von dem ich viele Denkanstöße mitnehmen konnte und bereits gewußtes in meinem Kopf wieder freigelegt wurde.

Hier ein kleiner Veranstaltungshinweis für alle Berliner. Marion Eickmann von agile42 hat es geschafft Mary Poppendieck für den nächsten Berliner Scrum-Stammtisch am 11. Oktober 2009 zu gewinnen.

Wer gerne am Stammtisch teilnehmen würde, erfährt auf dem agile42-Blog alles dafür notwendige.