oose zeigt psychologische Phänomene auf der Lean Agile Scrum-Konferenz am 14.9.

Die Lean Agile Scrum Konferenz findet dieses Jahr am 14. September in Zürich statt. Bei der dritten Veranstaltung in Folge werden Praxisberichte „Vom Pilotprojekt zur Unternehmensstrategie“ im Fokus stehen. Die Konferenz wird durch die Fachgruppe “Lean, Agile & Scrum” der SwissICT organisiert und bietet ein interessantes Programm, um den Erfahrungsaustausch innerhalb der Community zu fördern und Brücken zwischen CxO, Managern, Projektleitern, Business Analysten, Entwicklern und Testern zu bauen. Michael Hofmann von oose ist auch vor Ort und wird zum Thema „Psychologie im Gedränge“ referieren. In seinem Vortrag lernen die Teilnehmer psychologische Phänomene aus der Gruppendynamik und deren Bedeutung auf ein Scrum-Team kennen.

Eine Projektorganisation gemäß Scrum setzt stark auf Teamarbeit. Somit ist es hilfreich für eine erfolgreiche Steuerung eines Scrum-Projektes, typische Gruppen-Phänomene zu kennen und Interventionsmöglichkeiten an der Hand zu haben, um angemessen mit den sich ergebenden Situationen umgehen zu können. Arbeiten Menschen in Teams, so zeigen sich regelmäßig verschiedene gruppendynamische Phänomene wie z. B. Teambildungsphasen, eine Risikoverschiebung oder „Group Think“. Michael Hofmann von oose zeigt in seiner Session wichtige Ansatzpunkte für Interventionen in der täglichen Arbeit als Scrum Master. Er setzt aAgile Verfahren seit 2005 ein. Ein zentrales Element seiner Tätigkeit als Trainer und Berater für agiles Projektmanagement bei der oose Innovative Informatik GmbH sind Antworten auf die Fragen nach dem Wie und Warum des Funktionierens agiler Verfahren.

Mehr Informationen zur Veranstaltung sowie die Möglichkeit zur Anmeldung finden Sie hier.

   

…die berühmten “Energiebälle”

Schätzungen und realer Output der Mitarbeiter der Energieballfabrik

So, auch der zweite Tag der open-oose Tage  ist vorüber und es ist wieder eine Menge passiert. Diesmal ging es um das Thema „Lean“ und natürlich um den Bezug zur Softwareentwicklung. Dabei haben die beiden Trainer Markus Wittwer und Jan Gentsch sowohl die Theorie als auch das praktische Erleben kompetent dargestellt, bzw. begleitet. Ich persönlich fand, dass die beiden sehr gut harmoniert haben und schon alleine dadurch einen Mehrwert für diese Veranstaltung geschaffen haben. Motiviert durch eine Fabriksimulation, an der die ganze Gruppe aktiv teilgenommen hat, ging es in die Theorie, die knackig und mit vielen Beispielen aus der Praxis dargestellt wurde. Am Nachmittag kamen noch die Value Stream Maps  und eine intensive Übung an Beispielen der Teilnehmer hinzu, so dass am Abend ein rundes und vollständiges Bild der Grundideen des „Lean-Seins“ gezeichnet werden konnte. Alles in allem ein sehr informativer, spannender und auch unterhaltsamer Tag. Danke!

Björn Schneider

   

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

   

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