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.

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.

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?

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.

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...

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

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

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.

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