Bernd Schiffer hat in seinem „Klick für Klick“ Blog eine sehr schöne Geschichte, an der man gut sehen kann, wie User Stories in bearbeitbare und planbare Brocken geschnitten werden: „Horizontaler und vertikaler Schnitt von User Stories“ (einmal abgesehen von ein paar Rechenfehlern… ;-).
Auch sonst ist Bernds Blog sehr lesenswert!
Am kommenden Freitag, 28.11., werde ich auf den XPDays 2008 in Hamburg über agiles Schätzen und Planen sprechen. Nähere Informationen dazu finden Sie auf dem XPDays Blog.
Roland Berger hat in der Studie „Be flexible – How engineered products companies prepare for the downturn“ 500 Maschinen- und Anlagenbauer untersucht, wie sie mit wirtschaftlichem Abschwung umgehen und Krisen überleben. Als zyklische Branche ist gerade die Investitionsgüterindustrie besonders anfällig für konjunkturelle Schwankungen. Das Resümee: Die besten Unternehmen können so flexibel auf die Krise reagieren, dass sie Konjunktureinbrüche sogar als Chance nutzen können, ihre eigene Marktposition zu stärken.
Wie die meisten anderen Sparten steigt der Anteil der IT an der Wertschöpfung auch im Maschinen- und Anlagenbau stetig. Die von Berger postulierte Flexibilität setzt unter anderem auch entsprechende Flexibilität in Forschung und Entwicklung voraus, nicht nur, aber auch bei der IT. Verfahren und Vorgehensmodelle, die zu Laufzeiten von vielen Jahren führen, können da schnell zum Ballast werden.
Agile Verfahren erlauben hier viel größere Flexibilität. Agile Planungstechniken fügen sich elegant und nahtlos in eine szenariobasierte Unternehmensplanung ein, wie sie Berger bei den erfolgreichen Unternehmen beobachtet. Zu Beginn der Rezession könnte noch ausreichend Zeit bleiben, flexibler zu werden.
„Machen Sie Flexibilität zur Sache des Top-Managements“ zählt Roland Berger als einen der fünf strategischen Bausteine auf, um die Krise zu überleben. Diese Forderung dürfte nicht nur für den Maschinenbau gelten.
PS: Mehr über agile Planungstechniken erzähle ich u.a. auf den XPDays 2008 in Hamburg oder auf der OOP 2009 in München
Ich hatte im Januar schon einmal kurz über Jazz geschrieben („Jazz ist nun doch frei verfügbar„), damals in der Hoffnung, IBM würde bei Jazz eine ähnliche Politik verfolgen, wie bei Eclipse und die Projektmanagement-Plattform frei zur Verfügung stellen. Die erste offizielle Version ist jetzt unter dem Namen „Rational Team Concert 1.0“ verfügbar (http://www.jazz.net) und leider hat sich IBM nicht zu dem Schritt durchringen können, die Software mit einer freien Lizenz bereit zu stellen. Immerhin gibt es kostenlose Lizenzen für Open-Source Projekte und akademischen Einsatz. Und es gibt für ganz kleine Teams von höchstens drei Personen eine kostenlose Version „Express-C“ zum Herunterladen — kaum die Teamgröße, in der ein solches Werkzeug seine Stärken ausspielt.
Ich finde es schade, dass IBM nicht am Erfolg von Eclipse anknüpft und sich bei Jazz für traditionelle Lizenzpolitik entschieden hat, statt den mutigeren Schritt zu gehen. Ob sich diese Entscheidung für IBM rechnet, ist schwer abzuschätzen; ich neige dazu, das nicht zu glauben. Die Chance, den Markt für Projektmanagementwerkzeuge zu revolutionieren, dürfte IBM so aber kaum wahrnehmen können. Statt dessen nur ein weiteres Produkt unter vielen. Schade eigentlich.
Gestern hat Siemens eine Gewinnwarnung über 900 Mio Euro veröffentlicht. „In der Vergangenheit habe man sich mit Großaufträgen übernommen und mehr Aufträge angenommen, als der Konzern abarbeiten konnte“ berichtet die Süddeutsche Zeitung in ihrer heutigen Ausgabe über ein wichtige Ursache für die Warnung (SZ vom 18.3.2008, S. 19). Sich mit Aufträgen zu übernehmen gehört sicher zu den häufigsten Managementfehlern in Unternehmen jeder Größe. „Droht“ ein Kunde mit einem Auftrag und stellt auch noch Bezahlung dafür in Aussicht, ist die Versuchung groß, sich die internen Kapazitäten und ihre Auslastung schön zu rechnen. Trifft das auf eine Kultur, in der Risikobewusstsein als mangelnde Einsatzbereitschaft fehlgedeutet wird („Das müssen Sie als Chance begreifen“) und wird der Vertrieb mit Provisionen „motiviert“, die ignorieren, ob das Verkaufte auch geliefert werden kann, ist die Katastrophe schon fast vorprogrammiert.
Wer Software erstellt, kann agile Planung einsetzen, um dieses Risiko zu vermindern: Weiterlesen
Ein immer wiederkehrendes Problem bei agiler Planung ist die Menge an Karten, mit denen man jonglieren muss. In einem Monat sind vielleicht zehn, fünfzehn oder mehr Stories geplant, zu einer Story können leicht fünf oder sechs Aufgaben entstehen und der Platz auf einer Pinwand ist beschränkt.
Eine nette Lösung für das Problem hat Johannes Stark entwickelt, der in einem von mir betreuten Team mitarbeitet:
Aus transparenten Hüllen und ein wenig Klebeband werden Taschen gebastelt, in welche die Karten für die User Story und alle noch ungeplanten Aufgaben gesteckt werden. Die Taschen hängen in der Reihenfolge ihrer Priorität an der Pinwand. Zur Wochenplanung werden dann die Aufgaben nach der Reihenfolge ihrer Priorität aus den Taschen genommen und auf eine zweite Pinwand gehängt, bis die Wasserlinie erreicht ist. Überzählige Aufgaben wandern wieder zurück in die Taschen.
Fallen unter der Woche neue Aufgaben an, so werden sie in die Taschen der zugehörigen User Story gesteckt und bei der nächsten Wochenplanung berücksichtigt. Ist eine Tasche leer und die Aufgaben abgearbeitet, so ist die User Story erledigt – vorausgesetzt natürlich, die Tests laufen.
In den Frühzeiten agiler Entwicklung wurde mir einmal während einer Podiumsdiskussion über Entwicklungsprozesse aus dem Publikum die folgende Frage gestellt: „Sie propagieren die schnelle Reaktionsfähigkeit und die Anpassungsfähigkeit an den Markt. Das klingt sehr schön, aber wir müssen Produktplanungen über die nächsten fünf Jahre vorlegen. Wie können Sie das mit agiler Entwicklung tun?“ Ich war neugierig geworden, welche Branche so lange Zukunftsperspektiven nicht nur ermöglicht, sondern offensichtlich einzufordern scheint und so fragte ich erst nach, aus welcher Branche der Fragesteller denn käme. Die Antwort erregte allgemeine Heiterkeit: „Wir bauen Handys.“
Ich empfahl dem Fragesteller, die derzeitigen Prozesse unbedingt beizubehalten, sollte es ihnen tatsächlich gelungen sein, vor fünf Jahren vorherzusehen, dass der SMS-Versand von Jugendlichen die wichtigste Einnahmequelle der Mobilfunkbetreiber werden würde – zu dieser Zeit war der SMS-Service noch keine fünf Jahre alt.
Der Handyhersteller ist übrigens mittlerweile insolvent, unter anderem, weil er sich am Markt nicht schnell genug bewegt hatte.
Stefan Hagen hat in seinem „Projektmanagement Blog“ eine Folie bereitgestellt mit den „Bestandteilen eines Projektplans„. Die Folie enthält unter anderem 18 Teilpläne, einschließlich „Arbeitspaketdefinitionen“ und „Terminplan (GANTT)“.
Aus agiler Sicht erscheint das eher schwergewichtig. Anstatt festzulegen, welche Pläne gebraucht werden, diskutiere ich lieber die Ziele einer Planung:
Im agilen Bereich hat sich das aus der Toyota-Produktion stammende Kanban-Prinzip bewährt: Weiterlesen
Ein wichtiges Argument für agile Entwicklung ist, dass man flexibel auf Änderungen der Umstände reagieren kann. Viele Manager befürchten allerdings, dass sie diesen Vorteil auf Kosten der Planbarkeit erkaufen müssten. Gerade bei Produkthäusern verlangen Kunden und Investoren möglichst zuverlässige Aussagen, wann welche neuen Produktmerkmale oder Marktstrategien zur Verfügung stehen. Stört hier agile Entwicklung?
Ich meine, dass agile Planungspraktiken ganz im Gegenteil sogar helfen, solche langfristigen Planungsaussagen nicht nur zu treffen, sondern dann auch noch einzuhalten. Allerdings muss man dafür eine zusätzliche Planungsebene einführen, nennen wir sie strategische Planung (oder Roadmap, falls Ihnen Anglizismen besser gefallen). Anders als alle anderen Planungsebenen in einem agilen Vorhaben, geht der Horizont der strategischen Planung nicht nur über die anstehende Iteration, sondern über die nächsten 18 oder 24 Monate – mehr ist in der Regel nicht mehr seriös planbar.
Weiterlesen
In der traditionellen Planung wird versucht, die Auslastung der „Ressourcen“ zu optimieren: Die Idee ist, dass man dann am effizientesten arbeitet, wenn jeder voll ausgelastet ist.
Agile Planung versucht Ergebnisse zu optimieren: Das Team bemüht sich, zunächst die wichtigsten Aufgaben abzuschließen, dann die nächst-wichtigen usw. Man konzentriert sich also darauf, Aufgaben abzuschließen, anstatt darauf, Aufgaben anzufangen.
Durch die Optimierung der Ergebnisse ist die Anzahl der zugleich bearbeiteten Aufgaben niedriger, es sind weniger Abstimmungen und Kontextwechsel notwendig, das Team erledigt insgesamt mehr Aufgaben. Die Auslastung einzelner Entwickler mag zwar gelegentlich geringer sein, als bei Auslastungsorientierter Planung – wie auch die Auslastung der Flugbegleiter in meinem gestrigen Eintrag. Aber der Geschäftsnutzen ist größer. Und darauf kommt es an.