6.11.2008 von Jens Coldewey.

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

Geschrieben in Planung, Management, Agilität | Drucken | Keine Kommentare »

24.7.2008 von Jens Coldewey.

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.

Geschrieben in Werkzeuge, Planung, Management, Agilität | Drucken | 1 Kommentar »

18.3.2008 von Jens Coldewey.

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: Den Rest des Eintrags lesen »

Geschrieben in Planung, Management, Agilität | Drucken | Keine Kommentare »

21.2.2008 von Jens Coldewey.

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.

Geschrieben in Werkzeuge, Planung, Agilität | Drucken | Keine Kommentare »

21.1.2008 von Jens Coldewey.

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.

Geschrieben in Planung, Management, Agilität | Drucken | Keine Kommentare »

9.1.2008 von Jens Coldewey.

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:

• Das Team auf die wichtigen Aufgaben fokussieren
• Zusammenarbeit koordinieren
• Vorhersagen über Fertigstellungstermine ermöglichen
• Transparenz über den Projektstatus schaffen

Im agilen Bereich hat sich das aus der Toyota-Produktion stammende Kanban-Prinzip bewährt: Den Rest des Eintrags lesen »

Geschrieben in Planung, Management, Agilität | Drucken | Keine Kommentare »

4.1.2008 von Jens Coldewey.

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.
Den Rest des Eintrags lesen »

Geschrieben in Planung, Management, Agilität | Drucken | 1 Kommentar »

5.12.2007 von Jens Coldewey.

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.

Geschrieben in Planung, Management, Agilität | Drucken | Keine Kommentare »

4.12.2007 von Jens Coldewey.

Wer die Koordination der Flugbegleiter beim Service auf einem Kurzstreckenflug beobachtet, kann ein schönes Beispiel globaler Optimierung entdecken: In dem engen Mittelgang hat nur ein Servicewagen Platz, überholen ist ausgeschlossen. Oft beginnt die erste Flugbegleiterin in Reihe 1 mit ihrem Service und arbeitet sich voran. Sobald der Kollege seinen Wagen bereit hat und aufschließt, überspringt die erste Kollegin einige Reihen, in denen der Kollege dann den Service übernimmt. Das ist zwar sehr naheliegend, zeigt aber, dass hier erst globale Optimierung ein vernünftiges Ergebnis bringt: Würde die erste Kollegin einfach “schneller” bedienen, sprich ihre eigene Effizienz optimieren, wäre ihr Kollege arbeitslos, die Aufgabe, alle Passagiere zu versorgen wäre in der gebotenen Zeit nicht zu schaffen. Sie muss ihre Arbeit für zwanzig oder dreißig Sekunden einstellen - also ineffizienter werden - damit der Kollege wiederum mit seiner Arbeit beginnen kann.

Warum ich darüber schreibe? Genau das zweite Verhalten, die operative Hektik, sehe ich immer wieder in der Softwareentwicklung: Wenn Entwickler versuchen, ihre persönliche Aufgabe durch Überstunden und besonders “schnelle” Arbeit so schnell wie möglich “abzuschließen”, geht das in der Regel auf Kosten der Qualität. Nachfolgende Tester oder Entwickler, die später den Code ändern müssen, sind die Leidtragenden, weil ihre Arbeit schwieriger wird. Und vor allem sind die Kunden die Leidtragenden, die nicht selten durch irrationalen Druck gehörige Mitverantwortung tragen. Diese operative Hektik ist nicht einmal Egoismus, weil das sogar den Entwickler selbst treffen kann. Es ist simple Kurzsichtigkeit.

Das gleiche gilt für Tester, die neue Features nicht testen, sobald sie bereit stehen, sondern erst, wenn der Test “an der Reihe ist”. Und natürlich für Manager, die solches Verhalten oft nicht nur dulden, sondern sogar fördern und belohnen.

Warum sind Flugbegleiter dabei so viel besser? Sie trainieren in mehreren Iterationen täglich in ständig wechselnden Teams. Sie haben den direkten Kundenkontakt, der bei ineffizientem Service deutliches Feedback ermöglicht. Und sie haben die notwendige Prozessfreiheit, den Vorgang immer weiter zu optimieren.

Iterationen, direkter Kundenkontakt und Retrospektiven helfen bei agiler Entwicklung, global zu optimieren, anstatt die Mitarbeiter in operativer Hektik auszubrennen.

Geschrieben in Planung, Management, Agilität | Drucken | 1 Kommentar »