Eine kurze Bemerkung meinerseits zu dem Punkt kontinuierlich vs. iterativ.
 
Der kontinuierliche Ansatz basiert meiner Meinung nach auf zwei Rahmenbedingungen. Kontinuierlicher Verfügbarkeit der relevanten Personen, also deren ausschließliche Fokussierung auf ein “Projekt” und der Annahme, dass zentrale Risiken einigermaßen im Griff sind bzw. stets klarer Prioritäten.
 
Es gibt Softwareprojekte, für die das gilt, doch gerade, wenn mehrere Fachabteilungen/Stakeholder und/oder räumliche Verteilungen ins Spiel kommen oder für einzelne Personen/Fachwissen keine Redundanz vorhanden ist (z.B. eine QS für 3 Projekte oder technische Fachexperten) sehe ich Vorteile im iterativen Ansatz mit verlässlichen, vorab planbaren Terminen.
 
Dazu kommt die notwendige Fokussierung auf Rüstzeiten, um die Flexibilität zu erreichen. Das ist für mich ein spannender Punkt, denn von dort ausgehend, kann man zu sehr originellen Lösungen kommen (vgl. Ohno: Toyota-Prozess). In der SW-Entwicklung haben wir es oft mit Rüstzeiten im Kopf einzelner Personen zu tun.
 
Ich finde es spannend darüber nachzudenken, wie von dort aus kommend, Entwicklungsprozesse aussehen können, die minimale Rüstzeiten erlauben. Wie kann man mit parallelen Tasks angemessen umgehen? Wie nehme ich Zwischenstände aussagekräftig ab? Testgetriebene Ansätze könnten vielleicht dazu interessante Ideen beisteuern oder auch eine ganz andere Form der technischen Bereitstellung von Zwischenständen für die anderen Stakeholder wie Fachbereiche oder QS in einer eher kontinuierliche Form, so dass zu jeder (passenden) Zeit an jedem Arbeitsplatz ein Zwischenergebnis abgenommen werden kann. Im klassischem, prozessorientierten Projektmanagement entspricht diese Idee der Einführung vieler und flexibel handhabbarer “Zwischen”-Gates. Anders als im klassichen Sinne, möchte ich diese allerdings nicht planen Das betrifft aber nur einen Aspekt und löst nicht die Rückkopplungsproblematik usw.
 
Uwe Vigenschow

   

Kanban ist ein fließender, kontinuierlicher Planungs- und Steuerungsprozess. Agile Verfahren wie APM, Scrum etc. setzen stattdessen auf iterationsweise Planung, also Intervalle. Die Bedeutung dieses Unterschiedes ist mir bislang nicht wirklich klar. Er erscheint mir aber zunehmend fundamentaler in dem Sinne, dass es weniger um eine Kanban-Adaption für iterative Verfahren geht, sondern um eine Alternative zu iterativen Verfahren. Die letztendlichen Konsequenzen daraus erscheinen mir sehr weitgehend.
Dann habe ich auch darüber nachgedacht, wie sich unser APM-Vorgehen in diesem Kontext darstellt und möchte, wenn auch ein wenig unstrukturiert, die Gedanken hierzu mal kurz festhalten.
Mit APM erlauben wir explizit, dass Auftragsgutachten (fertig/nicht fertig) auch während der Iteration stattfinden können, dann aber wiederum als Arbeitsauftrag einzuplanen sind. Aber dies ist in APM eher als Möglichkeit und nicht als angestrebtes Ziel gemeint und führt letztendlich auch nicht zu einem kontinuierlichen Prozess.
 
Vom Unterschied zwischen kontinuierlicher und intervallbasierter Planung, Steuerung und Kontrolle einmal abgesehen, haben wir in APM andere Mechanismen, um ähnlich teilweise Kanban-ähnliche Effekte zu erzielen, bspw. bezogen auf die Vermeidung zu großer Eingangspuffer.
 
Einer dieser Mechanismen ist der Läufer in Kombination mit der wöchentlichen Wahrscheinlichkeitsabfrage: Der Läufer sammelt einmal wöchentlich Statusinformationen über alle Arbeitsaufträge (entweder als Ampel-Status oder prozentual mit Hilfe der Frage “Wie groß ist die Wahrscheinlichkeit, dass dein Arbeitsauftrag am Iterationsende wie geplant fertig wird?”).
In APM ist dies der zentrale Mechanismus, um zusätzlich zum Feedback am Iterationsende bereits während der Iteration planungs- und steuerungsrelevante Rückmeldungen zu erhalten. Neben der Justierung von Entschwicklungsgeschwindigkeit, Schätzgüte etc. dient dies zur Vermeidung planerischer Überlastungen (zu große Eingangspuffer). Es gibt zwei Varianten dafür

1. Geht bspw. ein Arbeitsauftrag mit einem geschätzen Aufwand von 5 PT auf “rot” (Wahrscheinlichkeit < 50%, d.h. wird am Iterationsende nicht fertig sein), sind für die Folgeiteration 20 PT weniger an neuen Aufgaben zu erzeugen (bei ansonsten gleichbleibenden Prioritäten).
2. Die prozentuale Variante: geht ein Arbeitsauftrag auf 30% Erfolgswahrscheinlichkeit, liefert die wahrscheinlichkeitsgewichte Verarbeitung der Information (20 PT * 0,7 =) 14 PT Aufwand, den ich zum Iterationsende fakultativ übrig habe, d.h. in diesem Umfang reduzieren sich neu zu kreierende Aufträge für die Folgeiteration, um den Eingangspuffer minimal zu halten.

Der Läufer-/Statusmeldungsmechanismus ist sehr effizient und beruht im Wesentlichen auf direkte Kommunikation, d.h. liefert in der Praxis viel mehr als nur Zahlen. Der Läufer läuft wöchentlich, d.h. das Informationsaufnahmeintervall ist erheblich kürzer als eine Iteration, allerdings auch kein kontinuierlicher Prozess.
Ein anderer Mechanismus in APM betrifft die Frage, ob ich die Aufgaben für die nächste Iteration in den Tagen vor Ergebnisablieferung (also vor Begutachtung fertig/nicht fertig) festlege oder im Orientierungsabschnitt, d.h. zwischen Ergebnislieferung und Start der Folgeiteration. Soweit es vor Ablieferung passiert (was wir in APM tendenziell befürworten bzw. als Standardfall beschreiben), ergäben sich auch Ansätze, mehr vom iterativen zum kontinuierlichen Planen zu kommen. Zumindest ist dies eine Öffnung des streng iterativen Vorgehens zu einer zeitlich flexbleren Planung. Da ich die Unterscheidung iterativ vs. kontinuierlich jedoch als Paradigmenfrage sehe und nicht als Detail, würde ich dies für APM (oder auch für Scrum) nicht ernsthaft und ohne grundsätzliche Diskussionen verfolgen würde.
Die Wartehalle in APM ist ein Mechanismus mit gewissen Bezug zu Kanban.
Grundsätzlich ist es bei Diskussionen m.E. (im Moment) hilfreich zu unterscheiden, ob über die Mikroebene gesprochen wird (das Team mit seiner Planungswand im Zeitraum von der Sprint-Planung bis zur Ergebnisbegutachtung) oder über die Makroebene (also das was der Product-Owner oder das Product-Owner-Team leistet und was (zeitlich) iterationsübergreifend und (organisatorisch) teamübergreifend sein kann). Einen Nutzen kann Kanban einem einzelnen Team bringen (Mikroebene), um seine Selbstgesteuerung besser zu verstehen.
 
Für den Fall der Makroebene müssen die Planungsartefakte eines SW-Projektes als Fluss/Prozess begriffen werden, d.h. ein Wissen darüber, wer mit dem Ergebnis weiterarbeiten soll (so wie Material im Produktionsprozess weitergegeben wird). In Scrum, zumindest im Kontext Benutzergeschichten, existiert die Absicht oder Forderung, die Abhängigkeiten zwischen Anforderungsartefakten möglichst klein zu halten (wobei noch zu wenig praktische Hilfe/Lösungen dazu angeboten werden…). Je mehr dieses Ziel erreicht würde, desto weniger Prozesscharakter haben die Arbeitsaufträge und desto schwächer ist die Kanbanindikation.
Andererseits heißt dies aber auch, dass die Abhängigkeiten zwischen den Arbeitsaufträgen explizit sein müßten (oder?), d.h. es muss definiert sein, wer Vorgänger oder Nachfolger ist und Tokens bereitstellt oder entnimmt. Bei einem Wasserfallvorgehen habe ich am meisten (trügerisches, d.h. veraltendes und nutzloses) Wissen über diese Abhängigkeiten. Deswegen gehen agile und iterative Verfahren den Weg, die Arbeitskette immer nur mit einem kurzen Zeithorizont aufzubauen und minimal vor sich her zu schieben. Ob ein- oder zwei Iterationen im Voraus geplant wird (auch hier gibts Unterschiede zwischen APM und Scrum), ist hierbei wahrscheinlich nachrangig. Im Vergleich mit der Metapher Produktionsstrasse heißt dies: es sind die Anzahl der vorhandenen Stationen grundsätzlich bekannt und die produzierten Güter durchlaufen auch einen weitgehend festgelegten Weg durch diese Stationen. Nicht mehr so statisch wie früher die Liefer/Förderbänder in einer Autofabrik, aber vom Prinzip her schon.
Beim iterativen Vorgehen erfolgt die Planungsdetaillierung typischerweise mit sehr kurzfristigem Zeithorizont, läßt also nur wenig Aussagen, eher Vermutungen über die weitere Prozesskette zu. Je nachdem, ob bestehende Funktionalität erweitert wird, ob neue Funktionalität programmiert oder nur konfiguriert oder deklariert werden soll, inwieweit die Anforderungen stabil und klar oder volatil und vage sind, ob die Herausforderung eher technisch ist oder die Geschäftsprozesse betrifft, welche fachlichen und technischen Abhängigkeiten die Anforderung impliziert, landen die bei der Detaillierung entstehenden Arbeitsaufträge bei völlig unterschiedlichen Mitarbeitern (Ressourcen).
 
Ich bekomme eine Ahnung davon, dass APM und Kanban unterschiedliche Wege gehen, aber ähnliche Probleme addressieren bzw. Effekte erzeugen.
 
Ob kontinuierliche Systeme generell besser als iterative sind bezweifel ich weiterhin, vor allem weil ich die kulturellen, sozialen und psychologischen Effekte (z.B. Belastung der Mitarbeiter, Aspekte der Selbstorganisation) bei iterativen Systemen für attraktiv halte.
Bernd Oestereich

   

Wir befinden uns im Endspurt. Im Januar wird unser Vorbereitungsbuch zur Zertifizierung OMG-Certified Expert in Business Process Management erscheinen.

Seit einigen Jahren engagiert sich die OMG verstärkt im Bereich des Geschäftsprozessmanagements. Sie ist verantwortlich für viele Standards aus diesem Bereich. Hierzu zählen beispielsweise die Business Process Modeling Notation (BPMN), das Business Process Maturity Model (BPMM) und das Business Motivation Model (BMM).

Die OCEB-Zertifizierung orientiert sich an diesen Standards, enthält aber auch Themen, die nicht in der Verantwortung der OMG liegen, wie z.B. Balance Scorecards, allgemeine Grundlagen, Basel 2 und Six Sigma. Es ist also keine Zertifizierung der OMG-Standards, sondern eine Zertifizierung des Wissens über Geschäftsprozessmanagement.

Dieses Buch führt Sie in alle relevanten Wissensgebiete für die Fundamental-Stufe des OCEB-Zertifizierungsprogramms ein und eignet sich zum Selbststudium sowie als Begleitlektüre für Vorbereitungskurse.

   

1. Die Softwareentwicklung hat mittlerweilen begriffen, das Softwareentwicklung nicht alleine ein kreativer Prozess ist, sondern aus einer Reihe systematischer Schritte besteht (z.B. Requirements-Engineering, Testentwurf, Architktur, Realisierung). Kreative Prozesse brauchen als Rahmenbedingungen ein fundiertes Management des Prozesses sowie eine konsequente Zielorientierung (siehe z.B. John Martin, Managing Problems Creatively). Der Kanban-Ansatz biete genauso so ein Management-Ansatz zur Prozesssteuerung. Daraus ergibt sich keine Einschränkung für die Art der zu bearbeitenden Inhalte, der Ansatz trägt lediglich dem Umstand Rechung, dass die Verarbeitungsressourcen (bei der SWE sind das die Teammitglieder) eine beschränkte Ressource sind. Es geht also primär um das Management der Auslastung der Teammitarbeiter und nicht um die Frage, was genau diese tun.
2. Kanban gesteuerte Systeme unterstützen Änderungen am Produkt während des Produktionsprozess, da Entscheidungen spätmöglichst getroffen werden können, ohne, dass aufwändige Umplanungen nötig werden oder übermäßige Lager/Abfälle entstehen. Änderungen werden also wirtschaftlich möglich. Amazon kann dank Kanban noch bis kurz vor Versand Aufträge ändern lassen.
3. In der Softwareentwicklung werden zwar keine physischen Gegenstände bewegt, aber nicht in das Produkt integrierte Anforderungen, Frameworks etc. erzeugen einen hohen Aufwand in der Verwaltung. Dabei ist nicht die Verwaltung auf einem Rechnersystem relevant, sondern der Aufwand der entsteht, diese Informationen bis zum Einsatz zu bewerten sowie aktuell und konsistent zu halten. Ist im Fall physischer Artefakte in der Produktionsindustrie der gebunde Produktwert (Material + Arbeistleistung) sowie der Lagerraum teuer, ist es bei der Softwareentwicklung der gebunde Produktwert (Erstellungsaufwand, kombiniert mit relativ zügiger Alterung) sowie der Verwaltungsaufwand (Bewertung, Filtererstellung, Konsistenzsicherung). Es macht also auch in der Softwareentwicklung Sinn, möglichst nur nach Bedarf zu produzieren.
4. Auch in der Softwareentwicklung gibt es viele Aktivitäten die immer wieder und in gleichen Abläufen erfolgen (Erstellung von Dialogen, Realisierung von Datenverarbeitung etc.). Selbst in der Produktion von Autos wird die Verbindung zweier Teile nicht neu erfunden, sondern gibt es z.B. Schrauben, die das immer wieder gut lösen. Es ist ein alter Hut, das die Entwicklung von Frameworks vom Bedarf der Produktion getriggert werden sollte, in dem Moment wo das Wissen über den konkreten Bedarf da ist. Anders ausgedrückt, es braucht Kanban-Token für Frameworks.
5. Fließfertigung mit strenger Taktung ist ein merkmal heutiger agiler Vorgehensmodelle (wie z.B. APM). Kanban-geregelte Systeme berücksichtigen, dass die Entwicklungsgeschwindigeiten varieren, es Störungen gibt und daher eine Vorausplanung nur begrenzt Bestand hat. Iterative Umplanung ist da nur ein Kompromiss. Die Regelung eines Systems mit Kanban ermöglicht ein System auf unvorhergesehene Ereignisse zu reagieren ohne Ressourcen unnötig zu belegen. Projekte werden mit Kanban im wahren Sinne agil.

Auch Kanban-Systeme enthalten geplante lokale Ineffizenz. Critical-Chain scheint mir aber nützlich bei der Betrachtung von “Einmallieferungen” (sprich sowas wie komplette Teilsystemzulieferungen oder ähnliches).
Abschließend kann ich aus eigener Erfahrung sagen, dass komplexe Systeme dazu tendieren sich wie Kanban gesteuert zu verhalten. Als Regelungsansatz wird das genutzt, um diesen Mechanismus explizit zu machen. Ich denke es steckt eine Menge nützlicher Ideen in der Diskussion (insbesondere wenn ich davon ausgehe, dass ich nicht einfach Universalressourcen habe).
 
Und ich denke es braucht noch viel mehr als nur Kanban im Projekt.
Jan Gentsch

   

1. In der Produktionsindustrie handelt es sich zwar um variantenreiche aber dennoch hochstandardisierte Produkte, bspw. werden in einer Produktion nur Pkw gefertigt. Die einzelnen Teilaufgaben sind hochgradig reproduktiv und vorgeplant. Die Softwareentwicklung ist gekennzeichnet durch einen hohen Anteil kreativer und wenig planbarer Tätigkeiten. Die Einzelaufgaben sind eher Unikate.
2. In der Produktionsindustrie stehen die Anforderungen an eine Produktinstanz fast immer zu Beginn der Produktion fest. Bspw. werden die Eigenschaften eines zu produzierenden Pkws bei der Bestellung im Autohaus festgelegt; sie werden während des Produktionslaufes nicht mehr geändert. Zumindest in der agilen Softwareentwicklung bekommt der Kunde die Möglichkeit und nutzt diese auch, Anforderungen wieder zu ändern.
3. In Produktionsprozessen werden physische Gegenstände (räumliche Ausdehnung, Masse, Gewicht) zwischen den Produktionsschritten ausgetauscht bzw. weitergereicht. Die Frage der Pufferung bzw. Lager hat hier eine betriebswirtschaftlich hohe Relevanz. Einzelteile einer Software, d.h. ihre Konfigurationseinheiten und ihr Code, existieren nur elektronisch. Kopien und Verschiebungen dieser Einheiten haben betriebswirtschaftlich eine üblicherweise stark vernachlässigte Relevanz (Stromkosten, Plattenplatz etc.). Für den Bearbeiter eines SW-Arbeitsschrittes ist praktisch auch kaum zu unterscheiden, ob ein Eingangspuffer (z.B. Aufgabenliste) tatsächlich nur eine bestimmte Menge von Elementen enthält oder ob dies lediglich eine Darstellung (Filterung) ist.
4. Die Einzelgegenstände sind in Produktionsprozessen oftmals austauschbar (bspw. liegen 3 gleiche Blechwinkel in der Materialkiste). In der Softwareentwicklung wäre dies ein Merkmal für ineffiziente Programmierung, die durch Konzepte wie Frameworks, Patterns, Vererbung o.ä. üblicherweise minimiert wird.
5. Kanban ist gedacht für Fließfertigung mit strenger Taktung. Das trifft für Softwareentwicklung-Prozesse kaum zu.
6. Und da Software oft mit Hilfe von Projekten entwickelt wird: Bereits die Definition von “Projekt” sträubt sich gegen die von Takeda genannten essentiellen Voraussetzungen für Kanban.

Zu beachten ist lediglich, dass die Größe des Analyselagers (d.h. die Menge der Anforderungs- und Analyseartefakte) eher klein bleibt, da sonst eine zu hohe Menge trügerische Sicherheit produziert und schnelle Rückkopplungen verhindert würden. Das ist aber einfach die unveränderte und von Kanban völlig losgelöste Motivation, anstelle eines wasserfallgetriebenen Vorgehens agil vorzugehen, d.h. den Zeitraum vom Erkennen einer Anforderung bis zum Nachweis der korrekten Auslieferbarkeit möglichst kurz zu halten.
Hingegen scheint der Critical-Chain-Ansatz mit gezielten lokalen Ineffizienzen die Dauer eines Projektes verkürzen können (wie im APM-Buch für den Staffelholzträger beschrieben bzw. von Elias Goldratt in “Die kritische Kette”, vgl. http://www.oose.de/detail/critical_chain_projektmanagement_2007_11.html).
Bernd Oestereich

   

Am 12. und 13. November findet in Friedrichshafen der diesjährige Tag des Systems Engineerings der Gesellschaft für Systems Engineering e.V. statt. In diesem Jahr gehen die Vorträge speziell auf die Bereiche Architektur und Design sowie modellbasierten Ansatz ein.

Keynote-Speaker Prof. Ortmeier von der Universität Magdeburg trägt über Model Based Safety Analyse vor und Dr. Raatschen von der Firma Astrium gibt einen Einblick in die komplexen Herausforderungen des Themas “Leben im Weltall”.

Ein Besuch im Zeppelinmuseum macht die Veranstaltung auch abseits der Vorträge interessant.

Ich würde mich freuen, Sie vor Ort zu treffen. Anmeldung und weitere Informationen finden Sie auf den Seiten der GfSE.

Beste Grüße,
Tim Weilkiens

   

Vom 14.-15. Oktober fand in Berlin das von der GPM ausgerichtete PM-Forum statt. Mein Kollege Markus Wittwer hat über die Ergebnisse unserer Umfrage zu Erfolgsfaktoren im Projektmanagement berichtet, und ich habe einen Kurzvortrag zu agilem Software-Projektmanagement gehalten. Beide waren sehr gut besucht und wurden teilweise gleich per Twitter verbreitet.
Das führte dann wohl auch dazu, dass innerhalb von eineinhalb Stunden gleich drei Vertreter klassischer Projektmanagement-Beratungsunternehmen unabhängig voneinander zu uns an den Stand kamen: “Unsere IT-Kunden fragen uns immer häufiger nach Agilität und Scrum – wie geht denn das und was sollen wir davon halten?”. Gute Ideen setzen sich anscheinend doch durch, wenn auch in manchen Umfeldern eher langsam als schnell…
Michael Schulze-Ruhfus

   

Nach den Unklarheiten der letzten Wochen schafft die Scrum-Alliance nun endlich Klarheit, wie es genau mit der Zertifizierung für Scrum-Master weitergeht. Hier die wichtigen Informationen zusammengefasst:

• Der Online-Test ist für eine Zertifizierung zum Scrum Master (CSM) ab dem 01.10.09 notwendig.
• Der Test erfolgt in Englisch.
• Der Test wird technisch über die Scrum Alliance Webseite abgewickelt.
• Er besteht aus 60 Fragen in 60 Minuten (Multiple Choice).
• Man bekommt zufällig eine von drei Varianten des Tests, in jeder Variante werden 60 Fragen aus insgesamt 90 vorhandenen ausgewählt.
• Die Inhalte des Scrum Guide werden abgefragt.
• Die Zertifizierungskosten werden nicht gesondert berechnet, sie sind in den CSM-Seminargebühren enthalten.
• Man muss ein CSM-Training besuchen bevor man die Zertifierung durchführen kann
• Man kann den Test bis zu dreimal wiederholen. Die erste Wiederholung kann man ohne Wartezeit zwischen den Tests durchführen, bei einer zweiten und dritten Wiederholung müssen sieben Tage zwischen den Tests liegen. Ist eine vierte Wiederholung nötig, muss erst erneut ein CSM-Kurs besucht werden.
• All dies gilt momentan nur für die Zertifizierung zum Scrum-Master. Die Zertifizierung zum Scrum-Product-Owner bleibt wie bisher (d.h. eine Teilnahme an einem Seminar ist ausreichend)
• Die Rezertifizierung wird mit Hilfe von “Personal Development Units” (PDUs) durchgeführt – analog zu dem Ansatz des Project Management Institutes (PMI). Die Details werden noch ausgearbeitet.

   

Seit gut 2 Jahren arbeite ich mit drei weiteren Mitgliedern im MBSE-Projekt “Telescope Modeling” des European Southern Observatory (ESO) und der Gesellschaft für Systems Engineering (GfSE).
Die Ergebnisse haben weltweit positives Aufsehen erregt. Erstmalig gibt es ein öffentliches SysML-Modell für ein reales komplexes Projekt. Neben dem Modell haben wir eine Menge an Best Practices zur Modellierung beschrieben. Die Ergebnisse finden Sie auf den Projektseiten.
Das International Council on Systems Engineering (INCOSE) möchte das Projekt nun fördern und stellt Gelder zur Verfügung, um die Ergebnisse in einem Booklet zu veröffentlichen.
Ein weiteres SysML-Beispielmodell, welches ich unabhängig von dem MBSE-Projekt erstelle, finden Sie auf den Seiten zu meinem Buch “Systems Engineering mit SysML/UML”.
Tim Weilkiens
(MBSE = Model Based Systems Engineering)