Auf unserem Strategieworkshop haben wir unser open-oose-Konzept auf den Prüfstand gestellt: Einerseits freuen wir uns über die vielen positiven Rückmeldungen und wollen die Highlights beibehalten. Andererseits experimentieren wir auch gerne und möchten uns noch mehr auf die Bedürfnisse unserer Kunden und des Marktes einstellen, so dass wir das Format ab 2012 ein wenig verändern wollen.

Was bleibt?
Nach wie vor bieten wir vielfältige und spannende neue Themen jeweils auf einen Tag verdichtet an. Im Fokus steht dabei weiterhin die inhaltliche Weiterentwicklung von Menschen und Themen.  Als Teilnehmer haben Sie wie bisher die Möglichkeit jeden Tag einzeln zu buchen oder alle open-oose-Tage mitzunehmen.

Was ändert sich?
Das Tagesangebot erhöht sich, d.h. wir planen aktuell mindestens 4 parallele Angebote pro Tag. Am Ende eines jeden Tages gibt es in einen offenen Beisammensein die Möglichkeit, in kurzen Zusammenfassungen die Essenzen auch aller anderen Angebote des Tages mitzunehmen. Außerdem können Sie bei Fingerfood entspannt und konsumierend einigen Kurzvorträgen lauschen oder sich mit anderen Teilnehmern vernetzen, diskutieren und eigenes Expertenwissen austauschen.

So werden die ersten drei Tage ablaufen. Und wenn Sie in diesen  immer noch nicht genug Input erhalten haben, dann nutzen Sie den 4. separat gestalteten Tag. Während wir an den ersten drei Tagen inhaltlich und konzeptionell mehr experimentieren, bieten wir Ihnen am vierten Tag die Möglichkeit, eines unserer ausgefeilten mehrtägigen Standardangebote einmal komprimiert auf einen Workshop-Tag zu erleben und Ihnen Lust auf “Mehr” zu machen.

Auch die Preise gestalten wir etwas anders: die ersten drei Tage können Sie zu jeweils 98 Euro/Tag buchen, den 4. Tag zu 298 Euro.

Wie geht’s weiter?
Sobald alle Themen abgestimmt sind und feststehen, werden wir diese auf einer Homepage veröffentlichen. Ab dann haben Sie die Möglichkeit, sich für die einzelnen Angebote anzumelden. Ich werde versuchen, Sie weiterhin, was den Werdegang von open-oose betrifft, auf dem Laufenden zu halten.

Freuen Sie sich schon gemeinsam mit uns auf inspirierende Themen aus allen Bereichen der IT. Merken Sie sich gerne schon einmal den Termin vor:  
20. – 22. März 2012 (Dienstag bis Donnerstag).

Neugierig? Anbei ein paar Auszüge der Planung:

• Agiles BPM – Was nützt es?
• Schnupperworkshop in Design Thinking
• Visual Facilitation
• Wut & Ärger im Projekt konstruktiv nutzen
• Scrum erleben: 3 Iterationen & 1 Release an einem Tag
• …und viele Andere…

“Nach dem 2. Sprint haben wir festgestellt, dass die wichtigen Aufgaben nicht erledigt wurden, da die Kollegen immer wieder bei anderen Projekten und Aufgaben helfen mussten. Uns war klar, dass wir so nicht rechtzeitig fertig werden und haben das Projekt abgebrochen. Scrum hat uns auch nicht geholfen.”

Ich war begeistert, mein Kunde irritiert. “Aus meiner Sicht sind Sie gerade sehr erfolgreich gescheitert. Sie haben sichtbar gemacht, dass die Priorität Ihres Projektes aktuell nicht hoch genug ist und haben es dann konsequent beendet. Die Alternative wäre gewesen, weiterhin Aufwand für die Planung eines Projekts zu verschwenden, welches offensichtlich zur Zeit nicht wichtig genug ist. Ich finde Scrum hat bestens funktioniert.”

Wir haben im Coaching das Thema Scrum dann erstmal beseite gestellt und statt dessen überlegt, wie wir herausfinden, womit sich die Mitarbeitenden tatsächlich beschäftigen, wie oft sie unterbrochen werden, wie viel Entwicklungskapazität vorhanden ist und wo eigentlich die tatsächlich gelebten Unternehmensprioritäten liegen. In der nächsten Zeit werden dazu die Teams mit Hilfe von Kanban-Boards Daten sammeln und Statistiken führen. Auf dem Kanban-Board werden sämtliche Aufgaben verfolgt, wobei es Regeln gibt wieviele Aufgaben gleichzeitig bearbeitet werden dürfen und was bei Störungen geschieht. In einigen Wochen veranstalten wir eine Retrospektive, dann werden wir die ersten Daten gemeinsam auswerten.

Beim Blättern in unserem APM-Buch (manchmal ist es gut, nicht nur zu schreiben, sondern auch zu lesen) bin ich gleich beim ersten Kapitel auf ein Zitat gestoßen und ich dachte darüber nach, warum es dort steht.

Winston Churchill

„Um die Welt zu ruinieren, genügt es, wenn jeder seine Pflicht tut“, soll einmal Winston Churchill gesagt haben. Was meinte Churchill damit und warum liefert er damit das Kernargument für agile Software- und Systementwicklung?

Als britischer Premierminister und das noch zu Kriegszeiten, legte er seine Aufmerksamkeit sehr wahrscheinlich auf die Handhabung von Überraschungen. Je mehr Überraschungen auftreten, desto flexibler bzw. agiler müssen die Akteure sein, die überrascht werden. In der Softwareentwicklung hat die Häufigkeit und Schwere von Überraschungen Ende des letzten Jahrhunderts ein Maß erreicht, bei dem triviale Entwicklungsmethoden nach Wasserfall versagen.

Mit welchen Überraschungen haben wir es üblicherweise zu tun?

• Die Umwelt von Entwicklungsprojekten ändert sich:
  • Gesetzgebung
  • Neue Ideen des Auftrag- bzw.Anforderungsgebers
  • Interessen und Machtverhältnisse wichtiger externer Akteure
  • Verhalten von Mitbewerbern des Auftraggebers, beispielsweise neue Strategien, Ankündigungen, Wettbewerbsprodukte, Preis- oder Kostensituationen.
  • Neue technische Möglichkeiten oder Herstellungsverfahren
  • Der Auftraggeber ändert seine Prioritäten, seine Investitionsbereitschaft oder hat einfach nicht mehr genügend Geld für das Projekt.
• Auch innerhalb des Projektes gibt es Überraschungen aller Art:
  • Neue Erkenntnisse über das zu entwickelnde Produkt, die Anforderungen daran oder zum Entwicklungsprozess
  • Neue Ideen zur Gestaltung oder zu Eigenschaften des zu entwickelnden Produktes
  • Zweifel, Ängste, Unsicherheiten zu bestimmten Aspekten oder Anforderungen
  • Beteiligte Experten, Könner oder andere wichtige Ressourcen schwinden oder fallen nennenswert aus, bspw. durch Krankheit, Fluktuation oder wegen anderer wichtigerer Aufgaben.
  • Interessen und Machtverhältnisse innerhalb der Entwicklungsorganisation
• Annahmen erweisen sich als unzutreffend:
  • Geschätzte Aufwände, Termine o.Ä.
  • Produktivität oder Verfügbarkeit von Mitarbeitern
  • Vorhandene Risiken und Hindernisse

Überraschungen dieser Art treffen während der gesamten Projektlaufzeit immer wieder auf das Projekt. Wird jetzt ein Entwicklungsprozess wie bspw. ein Wasserfallmodell angewendet, der die Handhabung von Überraschungen nicht kennt, ist die Entwicklungsorganisation maßlos überfordert und havariert: Überraschungen und Fehler werden erst sehr spät erkannt. Bis dahin wiegen sich alle in vermeintlicher Sicherheit oder Zufriedenheit. Und wenn sie erkannt werden, verschlimmert die mangelhafte Anpassungsfähigkeit der Entwicklungsorganisation und ihrer Prozesse alles noch.

Es hilft vor allem nicht, sich über diese Überraschungen zu beklagen, selbst wenn sie ungerecht sind oder gar der Auftraggeber für sie verantwortlich ist. Es liegt in der Natur von Menschen und ihren Organisationsformen, dass sie permanent miteinander kommunizieren, dabei Informationen austauschen, Wissen und Ideen generieren und Entscheidungen (zu neuen Handlungen) treffen.Und ebenso ist es völlig normal, dass wir Menschen in der aktiven Auseinandersetzung mit einem Gegenstand (also bspw. beim Programmieren oder fachlichen Modellieren) Fragen erzeugen, Thesen bilden, Ideen entwickeln, kreativ werden, lernen. Wir können das gar nicht verhindern und es wär auch blöd, diese geistigen Entwicklungen unterbinden zu wollen.

Die Ursachen für Dynamik lassen sich nicht unterbinden oder ignorieren. Wer das trotzdem macht, und beispielsweise Festpreise, Ausschreibungssitiationen als Vorwand dafür verwendet, handelt unverantwortlich, ja sogar fahrlässig, denn dynamikrobuste Entwicklungsverfahren sind ja bekannt.

Das für mich wichtigste Merkmal agilen Vorgehens ist daher die Fähigkeit der Entwicklungsorganisation sich anzupassen und zu lernen. Hierfür werden regelmäßige Rückkopplungen auf verschiedenen Ebenen benötigt. Zum einen auf der Ebene der konkreten Arbeitsergebnisse (Was haben wir hergestellt?). Zum anderen die Selbstbeobachtung der eigenen Arbeit und Kommunikation innerhalb und mit externen des Projektes (Wie stellen wir her?). Diese Rückkopplungen lassen den Anpassungsbedarf sichtbar werden.

Wenn die Entwicklungsorganisation dann noch die Fähigkeit besitzt, darauf sinnvoll zu reagieren, also passende Entscheidungen zu treffen, ist zumindest prinzipiell bereits eine lernende und anpassungsfähige Organisation und ein dynamikrobuster Entwicklungsprozess vorhanden. Die Entscheidungsfähigkeit kann durch organisatorische Rahmenbedingungen geschaffen werden, hierzu zählen Rollen, Verantwortlichkeiten (auch Hierarchie) ebenso wie kollektive Entscheidungsmechanismen bspw. durch spezielle Arbeitstreffen.

Scrum hat genau diese Elemente: Mechanismen zur Beobachtung des Anpassungsbedarfes auf Arbeits- und auf der Metaebene und ebenso Rollen und Arbeitstreffen, um auf diesen Ebenen Entscheidungen zu treffen. Deswegen funktioniert Scrum so gut.

Ich lese immer wieder, auch von „agilen“ Autoren, das agile Verfahren nur für bestimmte Projektarten, Problemklassen oder Rahmenbedingungen die beste Wahl sind und bspw. für große Vorhaben, streng regulierte Kontexte, Festpreise, Ausschreibungen, Behörden- oder Konzernkulturen u.ä. nicht in Frage kommen – das sehe ich grundsätzlich anders. Von trivialen Problemen abgesehen haben wir es immer mit interner und externer Dynamik und mit einem stetigen Fluss von Überraschungen zu tun.

Agile Verfahren beschreiben die Rahmenbedingungen für eine lernende und anpassungsfähige Organisation. Deswegen sind sie nicht nur generell geeignet, sondern auch grundsätzlich einem Wasserfallverfahren vorzuziehen. Es gibt praktisch keinen belastbaren Grund, nicht agil vorzugehen, solange wir nicht noch bessere Verfahren gefunden haben. Und in diesem Sinne sind XP, Scrum, APM und Kanban allesamt geeignet. Und weil sie verschiedene Aspekte adressieren bzw. verschiedene Hebel ansetzen, sind sie in gewisser Weise sogar gut kombinierbar.

Es ist schon erstaunlich, wie viele Aufgaben bei uns in der IT anfallen. Kaum wird eine Aufgabe in Angriff genommen, steht wieder jemand in der Tür und kommt mit der nächsten – natürlich noch wichtigeren – Aufgabe. In Folge haben wir einen Aufgabenstau, gefühlte Überlastung und lange Laufzeiten der Aufgaben.

Seit dieser Woche haben wir ein Kanban-Board in Betrieb, um die Staus und Engpässe transparent zu machen. Ich bin gespannt…