IT-Governance und Agile passen nicht zusammen; oder doch?

Crowdgovernance

Sebastian Mancke

© Shutterstock.com/hxdbzxy

IT-Governance und agiles Arbeiten in der Softwareentwicklung passen nicht zusammen – da sind sich zumindest die Vertreter der agilen Welt recht einig. Crowdgovernance vereint praktische Ideen von Scrum, Liquid Democracy und Communityprozessen miteinander. Damit unterstützt es Teams, den roten Faden zu finden und ihr Handeln an einer gemeinsamen Strategie auszurichten.

Die Spatzen pfeifen es bereits seit Langem von den Dächern: Softwareentwicklung muss agil durchgeführt werden. Alles andere bringt nichts – und kaum jemand traut sich heute noch öffentlich etwas anderes zu behaupten. Dennoch hapert es in großen Projekten und großen Organisationen oft noch sehr. Meist wird an etablierten Strukturen festgehalten und die Umstellung auf agiles Arbeiten erfolgt nur zögerlich. Der Grund hierfür ist nicht selten die Angst davor, die Kontrolle zu verlieren und die Geschehnisse nicht mehr lenken zu können. Aus dieser Angst heraus wird oft an einer klassischen und zentralistischen IT-Governance festgehalten.

Klassische IT-Governance

IT-Governance an sich ist nichts Schlechtes und verfolgt plausible Ziele:

  • Konsistenz der IT-Systeme
  • Vermeidung von Fehlentscheidungen
  • Unterstützung strategischer Ziele
  • Minimierung von Risiken
  • Effizienz
  • Homogene IT-Landschaften
  • Zukunftsfähigkeit des Unternehmens

In der Praxis führt dies jedoch oft zu einem starren Konstrukt von Regeln und dem Versuch, alles aus zentraler Hand zu steuern. Folgende „Bad Smells“ sind häufig anzutreffen:

  • Zentrale Technologie-Whitelists, die Projekt- oder sogar Konzernweit vorschreiben, welche Technologie eingesetzt werden darf.
  • Es fehlt die Möglichkeit für jedermann, einfach Einfluss auf die geltenden Vorgaben zu nehmen.
  • Zentrales Design aller Schnittstellen.
  • Ein verbindlicher „Standardstack“ oder ein Framework, das für jedes Projekt verwendet werden muss (häufig irgendeine veraltete Eigenentwicklung).
  • Trennung zwischen Architekt und Entwickler.
  • Eine zentrale Architekturabteilung, die alles absegnen oder sogar selbst entwerfen möchte.

Natürlich hängt der Nutzen oder auch Schaden immer von der konkreten Ausführung und dem Umgang damit ab. Eine gut gemachte Technologie-Whitelist kann durchaus helfen, wenn sie die Entscheidungen motiviert und den Trade-off zwischen Regelung und Freiraum richtig vermittelt. Auch kann eine zentrale Architekturabteilung eine agile Arbeit der Teams unterstützen, wenn sie mit den richtigen Mitarbeitern besetzt ist. Doch viel zu häufig führen die zentralistischen Governance-Ansätze lediglich zu einem großen Katalog von IT-Vorgaben und Richtlinien. Als Ergebnis unpassender IT-Vorgaben gibt es zwei typische Reaktionen:

  • Ein Teil der Mitarbeiter findet sich mit den unpassenden Vorgaben ab und akzeptiert, dass es in dem Unternehmen nicht möglich ist, die richtigen Entscheidungen zu treffen. Da man nur das verantworten kann, worauf man auch Einfluss hat, sinkt in der Folge meist die Identifikation und Übernahme der Verantwortung für die eigenen Ergebnisse.
  • Der andere Teil der Mitarbeiter akzeptiert die Vorgaben nicht, sondern trifft einfach die richtigen Entscheidungen. Da es nicht opportun ist, Regeln zu missachten, werden widerstrebende IT-Entscheidungen aber meist nicht offen kommuniziert, sondern als U-Boot betrieben. Im Ergebnis führt dies zu besseren Ergebnissen als die erste Variante. Es birgt aber ein ganz neues Risiko: Durch die fehlende Transparenz wird die Chance genommen, die IT-Governance an die neuen Ereignisse anzupassen und strategisch zu steuern. In der Folge wird der Graben zwischen Governance und gelebter IT immer breiter.

IT-Governance und Innovation

Das höchste Gut eines Unternehmens ist die Innovation. Innovation kann aber nur dann geschehen, wenn es ausreichenden Raum und die Motivation für freie Weiterentwicklung gibt. Jede Regel macht diesen Innovationsraum kleiner und jede Verlagerung der Verantwortung, weg von den Entwicklern, verringert deren Motivation zu gestalten. Eine zentralistisch ausgeübte IT-Governance führt damit mutmaßlich zu einer Innovationsbremse.

Steuerung und trotzdem agil?

Es gibt die Theorie, dass sich gute Ideen von alleine durchsetzen und agile Teams von selbst das Richtige entscheiden. Soll die Antwort also sein, den Anspruch an Steuerung und Governance komplett abzulegen? Nein!

Es ist nicht planbar, wie viel Zeit vergeht, bis Teams ohne Unterstützung eine klare Richtung finden. Außerdem führt der Weg dorthin oft über viele Umwege, die Zeit, Scope und Budget gefährden. Damit birgt eine ungesteuerte Entwicklungsmannschaft das Risiko unnötiger Kosten und führt oft zum Scheitern des Projekts. Governance ist also erstrebenswert. Aber wie kann sie gestaltet werden, um der Agilität und Innovation förderlich zu sein? Folgende Regeln sollten als Eckpfeiler einer agilen Governance dienen.

Grundsatz 1: Die Entscheidungshoheit liegt in den Teams!

Der oberste Grundsatz einer agilen Governance ist es, die Gestaltungsverantwortung bei den Mitarbeitern anzusiedeln, bei denen auch die Umsetzung liegt: Wer etwas tut, darf entscheiden, wie es getan wird. Entscheidungsverantwortung ist aber kein Selbstbedienungsladen: Wer etwas tut, muss auch selbst über sein Schicksal entscheiden.

Im Gegenzug muss das Team die Konsequenzen der getroffenen Entscheidungen selbst tragen. Wenn etwas nicht funktioniert, kann also nicht mit dem Zeigefinger auf falsche Vorgaben verwiesen werden.

Grundsatz 2: Befähige deine Mitarbeiter!

Die Anforderungen an Teams sind sehr hoch, wenn diese ihr Schicksal selbst in die Hand nehmen sollen. Es ist wichtig, die Teams nicht im Regen stehen zu lassen. Sie müssen dahin entwickelt werden, ihren Anforderungen auch angemessen gegenüber zu stehen. Dazu ist eine ausreichende und passende Skill-Verteilung nötig. Dies kann durch Teaming- und Schulungsmaßnahmen geschehen.

Grundsatz 3: Das Gesamtbild muss klar sein!

Damit die Teams selbst steuern können, müssen sie die Richtung kennen. Es muss klar sein, welche Ziele die Organisation oder das Projekt verfolgt, wie der grobe Plan dahin aussieht und was die eigene Rolle ist. Nur auf Basis einer ausreichenden Wissensgrundlage können die richtigen Entscheidungen abgeleitet werden.

Grundsatz 4: It’s all about Communication!

Ein guter Überblick stellt sich nicht von alleine ein. Das Wissen über die Organisation, die Ziele und die Arbeit von anderen Teams muss aktiv ausgetauscht und vermittelt werden. IT-Organisationen sind schnelllebig. Es reicht nicht, alle Informationen irgendwo zu dokumentieren und zum Lesen zur Verfügung zu stellen. Die einzige Lösung ist der Aufbau einer guten Informations- und Kommunikationskultur. Das gegenseitige Austauschen von Informationen muss Kern der täglichen Arbeit sein und von allen gelebt werden. Die Kunst hierbei ist es, den Spaß an Kommunikation zu wecken, ohne eine Informationsflut zu schaffen. Informationsmanagement hat noch einen Vorteil: Es schafft Identifikation.

Grundsatz 5: Ermögliche Heterogenität

Im Ziel einer Governance steht oft, die gesamte IT völlig einheitlich zu gestalten, oder die Heterogenität zumindest möglichst gering zu halten. Das ist falsch. Natürlich ist es praktisch, wenn alle Systeme gleich sind. Dies darf aber keine Forderung auf oberster Ebene für Technologieentscheidungen sein. Technologie entwickelt sich schnell weiter und Weiterentwicklung braucht Vielfalt. Es darf kein unkontrollierbarer Technologiezoo entstehen, vor allem aber darf nicht versucht werden, die Vielfalt zu unterbinden. Das Wichtigste ist, zu lernen, wie Systeme effizient gemanagt werden können.

Grundsatz 6: Förderung von Zielen, nicht von Verboten!

Schon bei der Kindererziehung merken wir: Verbote sind zwar manchmal unumgänglich, helfen den Kindern aber meist nicht dabei, das Richtige zu tun. Erwachsene Menschen sind genauso. Das Aussprechen von Verboten lähmt meist nur. Es führt dazu, sich mit dem zu beschäftigen, was nicht getan werden soll. Viel wichtiger ist es jedoch, die Mitarbeiter auf Alternativen zu dem Verbot zu fokussieren und deren Handlungen damit nicht zu stoppen, sondern in eine positive Richtung umzulenken.

Viel wirksamer als ein Verbot ist es häufig auch, die Konsequenzen einer Entscheidung deutlich zu machen. Wo dies möglich ist, sollte man dafür sorgen, dass die Personen, die diese Entscheidung treffen, auch selbst mit den Konsequenzen ihrer Entscheidungen konfrontiert sind. Ein gutes Beispiel hierfür ist der „you build it, you run it“-Grundsatz.

Von der Theorie zur Praxis

Es ist meist leicht, ein paar agile Grundsätze zu formulieren. Dies hat aber meist noch keine Wirkung auf eine Organisation. Im Folgenden sind eine Reihe ganz konkreter Methoden definiert, die dabei helfen sollen, die obigen Grundsätze zu leben und zu etablieren. Die Liste ist weder vollständig, noch ist es wichtig, alles darin einzuführen.

Liquid Democracy und Votings

Die Piratenpartei hat neue Maßstäbe in der toolgestützten Meinungs- und Entscheidungsbildung gesetzt. Auch wenn Projekte und Unternehmen im Kern meist nicht basisdemokratisch organisiert sind, lassen sich diese Elemente sehr effektiv nutzen. Die Mitbestimmung und kollektive Meinungsbildung bietet zwei große Vorteile: Entscheidungen, die von vielen Köpfen getroffen wurden, sind robust und geraten bei Führungswechseln nicht so schnell ins Wanken. Außerdem liefert die Mitbestimmung eine sehr hohe Identifikation mit dem Unternehmen sowie eine hohe Akzeptanz für die so getroffenen Entscheidungen. Um Mitbestimmung zu organisieren, bieten sich Votingfunktionen bestehender Tools an. Es können aber auch Softwaretools aus dem Liquid-Democracy-Umfeld verwendet werden (Abb. 1):

JM_12_13_mancke_abb1

Abb. 1: Votingtool-Beispiel

Die Kunst beim Aufbau einer internen Votingplattform liegt darin, diese mit passenden Inhalten zu beleben. Dabei muss einerseits dafür gesorgt werden, dass relevante Entscheidungen auch wirklich den Weg auf die Plattform finden und andererseits sollte vermieden werden, ständig alle Kleinigkeiten kollektiv zu diskutieren. In der Praxis hat sich gezeigt, dass es gut ist, eine wechselnde Gruppe von Moderatoren zu etablieren, die eine leichte Steuerung auf die Inhalte ausüben. Des Weiteren ist es sehr wichtig, dass das Management die getroffenen Entscheidungen anerkennt. Natürlich hat es grundsätzlich immer ein Vetorecht (Kasten: „Kontrollverlust des Managements?“). Wird jedoch oft von diesem Vetorecht Gebrauch gemacht, führt dies zu einer starken Demotivation der Mitarbeiter.

Kontrollverlust des Managements?
Den Kern der Crowdgovernance bildet die Verantwortungsübernahme durch die Mitarbeiter. Dies hat die Annahme zur Grundlage, dass nur die wirklich handelnden Personen in der Lage sind, schnell die richtigen Detailentscheidungen zu treffen. Das kann nur dann funktionieren, wenn das Management sich auch darauf einlässt, nicht mehr alle Entscheidungen selbst zu treffen oder zu kontrollieren. Oft führt dies zu starken Ängsten bei Team-Leads und Abteilungsleitern. Da sie ihre Rolle und ihre Einflussmöglichkeiten schwinden sehen. Das neue Rollenverständnis des Managements muss im Kern haben, den Raum für eine innovative Arbeit zu schaffen und gemeinsam mit den Mitarbeitern die Vision und die Strategie zu formen. Mitarbeiter in die Verantwortung zu bringen, heißt aber nicht, die Führungsverantwortung loszulassen. Die Verantwortung für das Handeln der Organisation bleibt beim Management. Damit haben auch alle demokratisch hergeleiteten Entscheidungen eine Grenze. Wenn die Dinge nicht in die richtige Richtung laufen und klare Fehlentscheidungen entstehen, ist das Management weiterhin in der Verantwortung. Es kann dezent einlenken oder im Notfall auch abrupt eingreifen.

Technologieratings

Die Idee der Technologieratings geht auf das Thoughtwork Technology Radar zurück. Die darin enthaltenen Empfehlungen betrachten die gesamte IT-Welt. Dieselben Ratings können auch intern durchgeführt werden. Dabei werden Technologien in unterschiedlichen Kategorien gesammelt und anschließend gemeinsam bewertet. Abhängig vom Organisationskontext sollten diese Kategorien individuell gewählt werden. Der Autor hat z. B. mit folgender Einteilung gute Erfahrungen gemacht:

  • Programmiersprachen und Frameworks
  • Tooling
  • Testing
  • Architektur, Paradigmen, Vorgehen

In der anschließenden Bewertung sollte es jedem Mitglied der Organisation möglich sein, die Vorschläge in folgenden Kategorien zu bewerten:

  • Einführen: Die Technologie ist in der Organisation noch nicht weit verbreitet, ihre breite Verwendung wird aber empfohlen.
  • Testweise einsetzen: Die Technologie ist sehr interessant und birgt kein großes Risiko, sodass sie bereits testweise eingesetzt werden soll (insbesondere in nicht kritischen Komponenten mit kurzer Lebensdauer).
  • Bewerten/Evaluieren: Die Technologie ist interessant. Sie sollte angeschaut, bewertet und weiter beobachtet werden. Ein Einsatz in Projekten sollte jedoch noch nicht erfolgen.
  • Beibehalten: Die Technologie wird schon in der Breite verwendet und sollte auch weiterhin beibehalten werden.
  • Vermeiden/Abschaffen: Die Technologie sollte, wenn möglich, nicht gewählt werden. Wo sie bereits im Einsatz ist, sollte erwogen werden, davon weg zu migrieren.

In einem einzelnen Team empfiehlt es sich, ein solches Rating gemeinsam mit Post-its oder an einem Whiteboard durchzuführen und die dabei entstehende Diskussion zu nutzen. Wenn jedoch ein Technologiebild für eine größere Organisation erstellt werden soll, wird ein Tooling benötigt. Hierzu hat der Autor eine einfache Webanwendung entwickelt. Sie steht unter der MPL-Lizenz und kann hier bezogen oder auch hier direkt verwendet werden. Die Anwendung unterstützt die Sammlung und Bewertung der Ideen und bietet eine grafische Darstellung der Ergebnisse (Abb. 2).

Abb. 2: Grafische Darstellung der Techrating-Ergebnisse

Abb. 2: Grafische Darstellung der Techrating-Ergebnisse

Es empfiehlt sich, ein bis zweimal pro Jahr eine Aktualisierung des Techratings vorzunehmen. Das Ergebnis kann als Orientierung und Richtlinie in der Organisation verwendet werden. Die Teams, die vor Architekturentscheidungen stehen, haben jetzt die Möglichkeit, zu erkennen, welche Entscheidungen konsensfähig sind und welche andere Teams eher nicht treffen würden. Da das Techrating Ergebnis einer kollektiven Meinungsbildung ist, besitzen die darin getroffenen Aussagen meist eine sehr hohe Akzeptanz.

Aber auch die Organisationsführung kann die Ergebnisse nutzen, um zu sehen, ob neue Strategien angenommen werden oder auch, um neue Strategien aus dem Techrating abzuleiten.

Vision und Leitsätze formulieren

Softwareentwickler, die in einem Team eingebunden sind, fokussieren meist sehr stark auf die kurzfristigen Teamziele. Das ist wichtig, aber manchmal geht dabei der Blick auf das Große und Ganze verloren. Daher ist es von großer Bedeutung, das Gesamtbild der Unternehmung klar und deutlich zu machen. Hierzu können Visionen und Leitsätze formuliert werden. Eine Vision gibt Ziel und Richtung und ist dabei die abstrakteste Ebene einer Zielbeschreibung. Leitsätze hingegen geben eine Orientierung, wie ein Ziel erreicht werden kann. Beides kann auf verschiedenen Ebenen formuliert werden.

Die Kästen zeigen jeweils ein Beispiel einer Visionen (Kasten: „Beispiel: Vision-Statement der Deutschen Post DHL“) und eines Leitsatzes (Kasten: „Beispiel eines Leitsatzes“). Weitere sind hier zu finden. Zur weiteren Beschäftigung mit der Produktvision ist weiterhin der Artikel von Roman Pichler zu empfehlen, in dem er die Produktvision als „the projects true north“ beschreibt.

Eine Vision kommt meist vom Management oder sogar dem Kunden. Leitsätze hingegen sollten aus der Mitte der handelnden Personen kommen. Eine verbreitete Form von Leitsätzen sind z. B. auch die Definions of Done von Scrum-Teams. Um ein hohes Commitment zu unternehmensweiten Leitsätzen zu bekommen, sollten diese allgemein verabschiedet oder breit abgestimmt werden. Hierbei können die oben beschriebenen Votingmechanismen zum Einsatz kommen.

Beispiel: Vision-Statement der Deutschen Post DHL
-Provider of Choice
-Investment of Choice
-Employer of Choice

Beispiel eines Leitsatzes
Wir richten die Entwicklung unserer Software am Nutzen unserer Kunden und Anwender aus! Hierzu entwickeln wir in kurzen Zyklen und legen besonderen Wert auf automatisches Deployment und Testautomatisierung sowie auf die Integration mit Open-Source-Software und der Community.
SWE-Leitsatz, tarent AG

Etablierung einer Unternehmenskommunikation

Eine Vision ist recht statisch, da sie das Ziel für einen langen Weg beschreibt. Um ständig zu wissen, wo lang der Weg gerade verläuft, ist eine regelmäßige Unternehmenskommunikation wichtig. Dies kann z. B. in Form von wöchentlichen Inforunden, Townhall-Meetings oder auch Unternehmensblogs mit allgemeinen Informationen erfolgen. Da diese Informationen nicht in direkter Verbindung mit der täglichen Arbeit stehen, werden sie oft als überflüssig empfunden. Sie sind jedoch elementare Voraussetzung dafür, dass Mitarbeiter in der Lage sind, selbst sinnvolle Entscheidungen zu treffen.

Teamreviews

Teamreviews sind ein klassisches Scrum-Element – evt. sogar das wichtigste. Im Review schließt das Team die Arbeit des Sprints ab und präsentiert dem Product Owner die Ergebnisse zur Abnahme. Die gesamte Organisation ist eingeladen, dem Review beizuwohnen und Feedback zu geben. Damit bietet das Review Raum für zwei wichtige Bestandteile einer lateralen IT-Governance: Informationsaustausch und gegenseitige Kritik. Doch vor allem Letzteres muss geübt werden.

Der Austausch von Kritik wird oft als sehr unangenehm empfunden. Daher sind die meisten Scrum-Meetings sehr „kuschelige“ Veranstaltungen, die nur an der Oberfläche kratzen. Wenn die Teams jedoch gelernt haben, ohne Scham über Erfolge und Defizite zu sprechen, ist es möglich, mit den Reviews eine sehr gute Kultur der gegenseitigen Kontrolle zu etablieren.

Um die Reviews zu beleben, sollten die Teams sich rege gegenseitig besuchen. Am besten ist bei jedem Review mindestens ein Vertreter eines jeden Teams dabei. Dies kann gerne rollieren und sollte auch dann beibehalten werden, wenn die Teams keinen direkten fachlichen Bezug haben. Sollte sich zeigen, dass es zu viele Teams sind, und das Ganze zu viel Zeit in Anspruch nimmt, ist es manchmal besser, die Reviews zu teilen und die Präsentation an die Organisation auf eine Reviewmesse zu konsolidieren, bei der alle Teams zusammen präsentieren.

Warum sind Reviews so wichtig? Durch sie ist es sehr effizient möglich, auf dem Laufenden zu bleiben, und zu wissen, was in anderen Teams gerade so passiert. Dies ist die Grundlage dafür, die Entscheidungen im eigenen Team sinnvoll an der Allgemeinheit auszurichten und zu sehen, ob gerade in dieselbe Richtung gearbeitet wird. Des Weiteren bieten die Reviews eine Plattform zur gegenseitigen Erinnerung und Ermahnung an gemeinsam getroffene Verabredungen – sie schaffen völlige Transparenz. In einer gut gelebten Reviewkultur ist es einem Team nicht möglich, die Company-DoD zu unterschreiten oder von den Empfehlungen gemeinsamer Technologieratings abzuweichen, ohne dies zu diskutieren und zu reflektieren.

Communities of Practice

Scrum setzt eine primäre Verortung der Mitarbeiter in Teams voraus. Die Zugehörigkeit zu Abteilungen der Organisation wird dadurch meist abgebaut oder verblasst. Es gibt also nicht mehr die Designer, die Architekten oder die Tester. Damit diese Gruppen eine gemeinsame Linie und Ausrichtung entwickeln können, brauchen sie jedoch einen regen Austausch. Hierzu gibt es die Communities of Practice (CoP). Das sind offene Gruppen, die sich regelmäßig zu einem definierten Themenkomplex treffen, um Erfahrungen auszutauschen und ein gemeinsames Vorgehen abzustimmen. Eine CoP ist kein beschlussfähiges Gremium, das für alle verbindliche Entscheidungen trifft. Die Entscheidungshoheit bleibt weiterhin im Team – die CoP erarbeitet jedoch den organisationsweiten Konsens und legt damit die Strategie fest, an der sich die Teams ausrichten sollen. Es ist nicht leicht, eine CoP gut zu gestalten. Folgende Aspekte helfen hier den Drive zu behalten:

  • Ein guter Moderator, der selbst für das Thema brennt und die Gruppe antreibt.
  • Ein dynamisches, aber striktes Agendamanagement. Bewährt hat sich die Vorabsammlung von Agendapunkten. Diese werden dann zu Beginn des Meetings kurz bewertet und entsprechend ihrer Priorität in Time Boxes besprochen. Die getroffenen Erkenntnisse müssen dabei natürlich dokumentiert und allen zugänglich gemacht werden.
  • Aufhören, wenn es nicht gut ist. CoPs können sehr dynamisch gestartet und wieder gestoppt werden. Wenn es gerade keine wichtigen Themen gibt, sollte es auch keine CoP geben. Es sollte aber jemand beobachten, wann der Bedarf wieder entsteht.

Für die Durchführung der CoPs eignet sich die Unterstützung durch ein Realtime Collaboration Tool. Hierbei hat sich das Etherpad bewährt (Abb. 3). Es ermöglicht das gleichzeitige Editieren von Text mit mehreren Personen und ist somit perfekt, um ad hoc eine Agenda abzustimmen und die Ergebnisse eines Meetings zu protokollieren.

Abb. 3: Etherpad: Realtime Collaborative Editing

Abb. 3: Etherpad: Realtime Collaborative Editing

Talks

Für einen regen Austausch über neue Trends und Best Practices sollten regelmäßig Talks gehalten werden. Folgende Formate haben sich in der Praxis bewährt:

  • Der Lightning Talk ist ein Kurzvortrag (z. B. 20 oder 30 min), in dem ein Thema kurz angerissen wird. Sowohl zuhören als auch Vorbereitung sind leichtgewichtig.
  • Der Tech Talk ist ein längerer Technologievortrag (1–2 Stunden), der Interessierten bereits einen guten Einblick in eine Materie gibt.

Die Knowledge Session ist ähnlich wie der Tech Talk, fokussiert aber auf fachliche und technische Themen aus der eigenen Organisation, z. B. wie funktioniert eigentlich diese oder jene Komponente in unserem Produkt?

Labs

Bevor eine neue Technologie eingesetzt wird, sollte sie erprobt werden. Hierzu gibt es das Format der Labs. Ein Lab ist ein Experiment mit einem klaren fachlichen und zeitlichen Scope und einem standardisierten Vorgehen:

  • Öffentliche Formulierung der Problemstellung und Zielerwartung
  • Definition von zeitlichem und fachlichem Scope
  • Bewerbung auf die Teilnahme an dem Lab
  • Konzentrierte gemeinsame Durchführung, z. B. in einem extra Projektraum
  • Öffentliche Dokumentation des Ergebnisses
  • Vorstellung der Erkenntnisse in einem Lightning Talk

Es sollte sich bemüht werden, die Labs teamübergreifend durchzuführen. Damit wird das Inseldenken aufgebrochen und die gewonnenen Erkenntnisse bilden direkt einen breiteren Konsens in der Organisation.

Fortbildungs- und Schulungskonzepte

Im IT-Bereich gehört die Weiterbildung eigentlich zur täglichen Arbeit. Dennoch tritt in vielen Organisationen oder lange laufenden Projekten oft eine gewisse Trägheit ein, die mit Fortbildungsmaßnahmen belebt werden sollte. Schulungsmaßnahmen bieten eine wunderbare Möglichkeit einer dezenten Steuerung. Die meisten Mitarbeiter setzen bevorzugt die Sachen ein, die sie gut beherrschen. Aus einer gemeinsamen Wissensgrundlage erfolgt damit häufig schon ohne weitere Steuerung eine recht homogene IT-Landschaft.

Um Fortbildung zu organisieren, sollte ein Fortbildungskatalog aufgebaut werden. Dieser hinterlegt für jedes Thema die geeigneten Maßnahmen. Die Themen selbst sollten sich aus unterschiedlichen Quellen speisen, wie Ergebnisse des Technologieradars, Vertriebs- oder Produktanforderungen, Fortbildungswünsche in Mitarbeitergesprächen und offensichtliche Skill-Bedarfe, die durch Team-Leads oder Scrum Master identifiziert werden.

Für unterschiedliche Themen eignen sich auch ganz unterschiedliche Fortbildungsmaßnahmen. Bei Fortbildung denken die meisten zunächst an die klassische Schulung durch einen externen Coach, die entweder in einem Schulungsunternehmen oder inhouse durchgeführt. Dies ist jedoch nur eine Möglichkeit, meist sind jedoch die Alternativen effektiver:

  • Etablierung von Subject Matter Experts (SME): Das sind ausgewiesene Experten für ein Thema. Sie bekommen das Ziel, sich in ein Thema vertieft einzuarbeiten und dieses in der Organisation nach innen und außen zu vertreten sowie an Kollegen weiterzugeben.
  • Interne Workshops und Schulungen: In größeren Organisationen hat man für viele Themen bereits fähige Personen, die das Thema auf ausreichendem Level an andere vermitteln können. Neben dem Kostenaspekt bringt die interne Schulung noch die Vorteile, dass die Kommunikation miteinander angeregt und dabei die gemeinsame Diskussion und Meinungsbildung gefördert wird.
  • Konferenzbesuche sind ein etabliertes Mittel, um den Trends und aktuellen Entwicklungen zu folgen. Die Reichweite davon erhöht sich, wenn die Konferenzbesucher angehalten sind, im Nachgang kurz über die interessantesten Themen zu berichten.
  • Für viele Mitarbeiter ist das Selbststudium die effektivste Möglichkeit, sich in neue Themen einzuarbeiten. Dies kann durch explizite Freiräume und ggf. auch durch kontrollierte Lernziele unterstützt werden.

Bei allen Fortbildungsmaßnahmen ist darauf zu achten, dass das Erlernte auch zeitnah angewendet werden kann. Wenn nicht, dann festigt es sich nicht, sondern verblasst schnell wieder. Der praktische Einsatz „Training on the Job“ hingegen ist für die meisten Personen das effektivste Mittel.

Fazit

Ich hoffe, dass Ihnen die konkreten Ideen ein paar Anregungen liefern konnten. Das Ziel sollte es nicht sein, möglichst viele Sachen parallel anzustoßen. Vielmehr ist es als Werkzeugkasten zu verstehen, aus dem gut überlegt die entsprechenden Tools genommen werden können. Wichtiger als die Anzahl der Werkzeuge ist die Etablierung und damit Schlagkraft des einzelnen Tools. Der Autor freut sich natürlich über weitere Ideen und Anregungen sowie über Erfahrungen bei der Einführung der Maßnahmen.

Die Rolle des Architekten
Der Autor vertritt die Meinung, dass es die etablierte Rolle des Architekten in einer agilen Organisation nicht geben sollte. Die Trennung zwischen Entwickler und Architekt beißt sich direkt mit dem Anspruch einer ganzheitlichen Verantwortungsübernahme des gesamten Teams für das komplette System. Dies umfasst Architektur, Code, Qualität, Systemumgebung, Sicherheit und Benutzbarkeit. Sofern die Entwickler eines Teams nicht bereits zu stark mit dem klassischen Bild des Architekten vorbelastet sind, schadet es aber nichts, den Begriff Architekt analog zu dem Begriff eines Seniorentwicklers zu verwenden. Dies kann im Rahmen der Personalentwicklung hilfreich sein, um Mitarbeitern eine klare Selbst- und Fremdeinschätzung zu ermöglichen. Auch wenn die Rolle des Architekten in agilen Teams fehl am Platz ist, sind dessen Fähigkeiten natürlich weiterhin von großer Bedeutung. Sie sollten aber von jedem Teammitglied nach seinen Möglichkeiten erbracht werden. Neben der technischen Lösungskompetenz steht hier insbesondere die Kommunikationsfähigkeit im Vordergrund.

Aufmacherbild: People with their hands together von Shutterstock / Urheberrecht: hxdbzx

Verwandte Themen:

Geschrieben von
Sebastian Mancke

Sebastian Mancke ist Head of Technology bei der tarent AG. Er hat viele Jahre Erfahrung in der Softwareentwicklung und Projektleitung innerhalb der tarent AG sowie in Großprojekten von Kunden. Mail: s.mancke@tarent.de

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: