Kultur ist ein oft gebrauchtes Schlagwort, mit dem ich mich vor einiger Zeit begonnen habe auseinanderzusetzen, als ich mich fragte, was wohl die eigentliche Grundlage für erfolgreiche Projekte ist.

Die obige Präsentation habe ich für den ersten Scrum Day 2010 in München vorbereitet, an dem ich mit dieser Präsentation auf der Reservebank für eventuell ausgefallene Redner teilgenommen habe. Gott-Sei-Dank war dies nicht der Fall und daher werde ich ihn am 17. November auf dem Scrum Day in Berlin halten. Dann aber wohl in einer überarbeiteten Form.

Was hat aber Unternehmenskultur jetzt mit agiler Entwicklung zu tun? Sehr viel! Liest man sich das agile Manifest durch, kann es nach meiner Meinung so zusammengefaßt werden, daß es für unseren Erfolg wichtiger ist, wie wir miteinander umgehen, als welche detailierten Prozesse wir versuchen einhalten. Wie wir mit einander umgehen, daß lernen wir in unserer Umgebung. Wir sehen, wie die anderen sich in unserer Umgebung verhalten, welche Strategien erfolgreich sind oder zumindest vor Schaden schützen, und passen uns daran an. Das paßt gut zur Definition von Kultur in Organisationen, wie ich sie bei Sonja Sackmann gefunden habe:

Organisationskultur ist die von einer Gruppe gemeinsam gehaltenen grundlegenden Überzeugungen, die deren Wahrnehmung, Denken, Fühlen und Handeln bestimmen und insgesamt typisch für die Gruppe sind.

Ein für uns sehr leicht nachvollziehbares Beispiel in der Softwareentwicklung ist der Umgang mit Fehlern. Defekte, das klingt doch wesentlich neutraler, gibt es in jeder Software, denn Software-Entwicklung ist zu komplex, um keine Fehler zu machen und sei es, daß es ab einem bestimmten Punkte nicht mehr wirtschaftlich vertretbar ist, eine Software gegen jeden Fehler abzusichern. Gute Projekte und Entwicklungsteams unterscheiden sich aber im Umgang mit Fehlern. Keiner macht gerne Fehler, denn das Fehlermachen wird negativ bewertet und oft in der einen oder anderen Form bestraft. Das kann ganz diffizil sein, beispielsweise wenn gleich gesagt wird: „Paß auf, nicht wieder die gleichen Fehler zu machen.“ Neulich habe ich in einem Projekt einen Softwarefehler gefunden und wollte zu dem für die Komponente verantwortlichen Entwickler gehen mit der Bitte, den Fehler zu beseitigen. Er sei im Urlaub sagten mir seine Kollegen, worauf hin ich meinte, daß das schlecht sei, denn er sei der Einzige, der den Fehler beheben könne, sagten sie, daß das vielleicht ja auch gut wäre, dann würde es vielleicht ja auch weniger Fehler geben. Ja, ja, der Truckfaktor. Aber, Wissensverteilung, Risikominimierung und Teamarbeit sind ja jetzt nicht mein Thema. Dieses Beispiel zeigt aber sehr gut, wie der Umgang mit Fehlern symptomatisch für die Kultur in einem Team ist. In einer solchen Umgebung werden Fehler bestraft, was dazu führt, Fehler zu vertuschen, zu leugnen, als nicht so wichtig hinzustellen, als sie zu beheben und daraus zu lernen.

In ihrem Buch „Soft Skills für Software-Entwickler: Fragetechniken, Konfliktmanagement, Kommunikationstypen und -modelle“ haben Uwe Vigenschow und Björn Schneider eine kleine Taxonomie von Fehlerkulturen aufgestellt, in der zwischen funktionaler und dysfunktionaler Fehlerkultur unterschieden wird.

Welche Fehlerkultur herrscht bei Ihnen?

Scrum-On-A-Page faßt kurz für den täglichen Gebrauch die Scrum-Rollen, den Prozess und die wichtigsten Inhalte der Meetings und die Scrum-Artefakte zusammen.

Hier geht es zum Download...

Jurgen Appelo, "So Now You’re an Agilist. What’s Next?", Agileee conference, 2009 from Alexey Krivitsky on Vimeo.

Hier geht es zur Anmeldung für das Berliner Seminar.

Montag ist der Tag nach dem Wochenende und das ist wichtig. Wir betreten das Büro ausgeruht und mit neuer Kraft. Probleme die am Freitag unlösbar waren sind über das Wochenende nebenbei gelöst worden. Manchmal einfach nach dem Aufstehen am Samstag und wir fragen uns, warum wir das nicht gleich so gesehen haben. Abstand und Ruhe sind oft die besten Problemlöser.

Am anderen Ende der Woche steht der Freitag. Freitag ist der Tag vor Samstag und Sonntag, also dem Wochenende und das ist wichtig für den nächsten Montag. Siehe oben. Freitags sollten keine harten Nüsse geknackt oder immens wichtige Termine angesetzt werden.

Was wir am Montag und Freitag tun, aber nicht sollten

Den Montag sollten wir uns für die Dinge vorbehalten, die wir mit ausgeruht angehen wollen, die uns vielleicht schon seit einiger Zeit unter den Nägeln brennen oder letzte Woche liegen geblieben sind. Oft wird der Montag aber gleich mit Meetings vollgekleistert, die sich damit beschäftigen, war in dieser Woche zu erledigen ist. War das nicht schon letzte Woche klar, was ansteht? Die Woche hat doch schon begonnen und über das Wochenende hat sich meistens wenig geändert.

Dafür wird am Freitag oft versucht noch das zu schaffen, was noch vor Montag umgesetzt sein muß. Das beste Beispiel hierfür sind Deployments, die noch „schnell“ am Freitag live gehen müssen. Schauen Sie an solchen Tagen mal in das Gesicht Ihrer Kollegen, die sich gerade überlegen, was alles schief gehen könnte und überlegen, wie wahrscheinlich es ist, spätestes um 18:00 Uhr das Büro verlassen zu können.

Wie wir es besser machen können

Aber wie können wir es besser machen? Hier sind meine Tipps:

• Planen Sie ihre Woche in der vorhergehenden Woche. Ideal sind Donnerstag und Mittwoch, Freitag geht auch. Wenn Sie jetzt einwenden, daß das zu früh ist, um zu planen, sollten Sie daran denken, daß wir die ganz kleinen Dinge sowieso nicht planen können.
• Lassen Sie den Montag frei und geben Sie sich die Möglichkeit Dinge anzugehen und zu lösen, die liegengeblieben sind oder zu denen Sie über das Wochenende Lösungen gefunden haben.
• Fangen Sie am Freitag keine Aufgaben an, die nicht über das Wochenende liegenbleiben können. Oder möchten Sie am Wochenende das Produktivsystem fixen?

So, Sie müssen ja nicht einverstanden sein mit meinen Ansichten zur Einteilung der Woche, aber vielleicht habe ich Ihnen ja einen Anstoß zum Nachdenken über Ihre Woche gegeben.

Im DD 99 setzt er sich mit Elite, deren Verantwortung auseinander und greift dabei bis auf Platon zurück. Er schließt mit:

Eigentum verpflichtet. Elite verpflichtet. Bildung verpflichtet. Adel verpflichtet, Stärkev erpflichtet.
Wer je das Privileg hatte, oben zu sein, hat damit eine Pflicht auf sich geladen. Elite ist nicht oben sein, sondern unten helfen und führen.

Gut, Dueck hat sein DD bezogen auf die Bundestagswahlen bezogen, aber greift das nicht auch auf Führung von Menschen in Unternehmen? Führung kommt von führen...

Um halbwegs vorbereitet in das Stück zugehen, wollte ich mir die wichtigsten Fakten zur Geschichte zusammengooglen, da der Roman mehr als nur einen Handlungsstrang hat und ich im Theater nicht in Gefahr kommen wollte, den Überblick zu verlieren.

Tolstoj leitet seinen Roman mit dem Satz ein: "Alle glücklichen Familien sind einander ähnlich; aber jede unglückliche Familie ist auf ihre besondere Art unglücklich." Daraus wird abgeleitet, daß für das gemeinsame Glück mehrere Dinge notwendig sind, die auch erfüllt sein müssen. Fehlt es an einem, kann es kein Glück geben.

Verallgemeinert bedeutet das:

• Für das Gelingen einer Sache sind immer mehrere Faktoren zu erfüllen.
• Fehlt einer der Faktoren, kann die Sache nicht gelingen.

Dieses Prinzip kennen wir aus unserere eigenen Erfahrung und es erklärt sehr einfach, warum Dinge wie zum Beispiel Projekte trotz vieler Erfolge und größter Anstrengungen an Kleinigkeiten scheitern können.

Jetzt endlich habe ich dafür einen griffigen Namen...

In diesem Video erklärt Prof. Kruse sehr gut, warum Veränderungsprozesse auch immer durch die oberste Ebene einer Organisation mitgetragen werden müssen und eine Änderung von unten nie erfolgreich ist. Und falls doch, dann nur, weil die Führung durch eine Reihe von Krisen so geschwächt ist, daß sie dem Änderungsdruck von unten nichts entgegen setzen können.

Für uns und unsere Projekte bedeutet dies, daß Veränderungen nur erfolgreich sind, wenn wir die Unterstützung der wichtigsten Stakeholder haben oder einfach der richtige Zeitpunkt dafür gekommen ist.

Starke widmet sich in seinem Vortrag dem Zusammenhang von Architektur und Kommunikation und weiß das überzeugend zu vermitteln.

Nach seiner Ansicht ist eine der wesentlichen Aufgaben eines Architekten die Kommunikation mit allen am Projekt beteiligten Stakeholdern. Richtig dachte ich nur während des ganzen Videos. Gute Architekturen zu entwerfenist das eine, sie zum Leben zu erwecken und zu halten etwas anderes. Dafür
müssen alle miteingebunden werden, die davon betroffen seien könnten. Und leider muß es muß auch immer wieder wiederholt werden.

Hier ein paar nebenbei notierte Aussagen von Starke:

• Architektur beschäftigt sich mit Strukturen und Konzepten.
• Implizite Annahmen treten immer da auf, wo etwas nicht
  dokumentiert ist, wo es notwendig gewesen war. (Alt bekannt!)
• Implizite Annahmen schaffen Mißverständnispotential. (Ich nenne
  das einfach mal heterogene Projektentwicklung. Klingt doch
  netter.)
• Architektur ist nicht das Kodieren von selbigen, da Code
  allein ab einer gewissen Größe keine Basis für Verständnis
  ist.
• Verständnis (von Architekturen) muß erst geschaffen werden und
  kann erst danach gefördert werden.
• Dokumentation muß minimalistisch sein, womit gemeint ist, daß
  nur die relevanten oder stabilen Punkte dokumentiert werden sollten,
  die für das Verständnis der Anwendung notwendig sind.
• Dokumentation muß wartbar sein.

Starke schafft es diese Punkte überzeugend zu vermitteln.

Fazit: Anschauen!