Meiner Erfahrung nach funktionieren traditionel geführte Interviews nicht, denn sie beachten nicht die Begabung der Entwickler, in hochkollaborativen und dynamischen Umgebungen zu arbeiten. Résumés und ein standardisiertes Interview decken das nicht ab.

Personalentscheider müssen sich nun die Frage stellen, welche Methode die richtige ist, um herauszufinden, ob der Kandidat das Zeug für ein agiles Team hat.

Eine Variante ist ein praxiorienterter Workshop in dem mehrere Kandidaten in Zweierteams eine Herausforderung bewältigen müssen und dabei beobachtet werden, wie sie kommunizieren, kollaborieren, diskutieren und Probleme bewältigen. Die eigentliche Lösung des Problems steht nicht im Mittelpunkt. Durch die Beobachtung der Kandidaten in der Praxis können qualifizierte Entscheidungen getroffen werden. Anders als im Interview.

Während es sicherlich massive Vorteile gibt, müssen wir uns allerdings auch vor Augen führen, dass der geschilderte Prozess relativ ressourcenintensiv ist. Termine für alle Beteiligten müssen vereinbart, Räumlichkeiten bereit gestellt, ein “Test” muss entworfen und während der Ausführung beobachtet werden. Mittlere bis große Unternehmen lösen die Probleme sicherlich leichter als kleinere, jedoch sind gerade Start-Ups und Shops mit 15 bis 50 Entwicklern besonders von effektiven Recruiting-Techniken abhängig.

Ein ähnlicher Ansatz ist eine interessante Mischung aus einem klassischen Interview und einem sehr individuellen Prozess. Im Gegensatz zur ersten Variante wird das bereits existierende Team (vorausgesetzt es gibt bereits eines) intergriert und läßt sich in fünf Abschnitte gliedern:

1. Vorauswahl: Teil 1 — Es werden künstlich Barrieren für potentielle Kandidaten aufgebaut, so dass nur ernsthaft interessierte Bewerber eingeladen werden. Das kann beispielsweise dadurch erreicht werden, dass bereits in der Stellenausschreibung ein paar Fragen gestellt werden, die in einem kurzen Essay zu beantworten sind. Nachteil ist, dass einige wirklich gute Leute durch die Lappen gehen, weil sie in der Regel wissen, dass sie es nicht nötig haben, mehr zu machen als notwendig.
2. Vorauswahl: Teil 2 — Noch vor dem ersten Interview werden die Essays ausgewertet. Das wird vom Team gemacht, welches die neuen später aufnehmen wird. In einem gemeinsamen Meeting wird über die Qualität entschieden. Gibt es eine Ablehnung, ist der Kandidat ausgeschieden und wird nicht eingeladen. Nachteil: wenn es ungünstig läuft bleibt vielleicht kein geeigneter Bewerber übrig.
3. Das Interview: Teil 1 — Das Team wird den Morgen mit den BewerberInnen verbringen (ich empfehle nicht mehr als Mitglieder als Kandidaten) und sie beispielsweise beim Frühstück in der Kantine und anschliessendem Rundgang im Unternehmen besser kennen lernen. Auf diese Weise können sich alle (auch der Kandidat) einen Eindruck über die Persönlichkeit verschaffen. Nachteil: relativ zeitaufwendig.
4. Das Interview: Teil 2 — Jedem Bewerber wird ein Teammitglied zur Seite gestellt um die tatsächlichen Fähigkeiten des Kandidaten geprüft und ggf. Schwächen und Stärken, welche im ersten Teil untergegangen sind, aufgedeckt werden. Am nächsten Tag wird das Team die Egebnisse auswerten.
5. Das Angebot — Wurden geeignete Kandidaten identifiziert, kann das Angebot durch Personalentscheider unterbreitet werden.

Meiner Meinung nach liefert die zweite Methode bessere Ergebnisse, als die erste, allerdings ist der organisatorische Aufwand ebenfalls nicht zu unterschätzen.

Die letzte Methode, die ich vorstellen möchte kombiniert ebenfalls bewährte Methoden traditioneller Entscheidungsfindung mit einigen Elementen, spezifisch für Agile Umgebungen.

In einem dreiteiligen Interview werden mit jeweils zwei Teammitgliedern (in allen drei Teilen die gleichen) zunächst technische, anschließend prozessorientierte und am Schluss persönliche Aspekte beleuchtet. Der technische Teil des Interviews befasst sich mit harten Fakten, technischen Kenntnissen und Erfahrungen des Bewerbers. Im prozessorientierten Teil wird über Philosophien verschiedener Testmethoden, Qualitätsaspekte, Problemlösungsansätze und Agile Techniken, wie etwa Pair Programming diskutiert. Der Letzte Teil untersucht Aspekte aus den Bereichen Konfliktlösung, Motivationen und mentale Stabilität.

Zusätzlich kann der Vorgang von einem einfachen Fragenkatalog unterstützt werden:

1. Erzählen Sie mir über eine Erfahrung in der Sie sich einer intensiven Meinungsverschiedenheit ausgesetzt sahen.
2. Wie sind Sie mit Entscheidungen des Teams umgegangen, welche nicht in Ihrem Sinne waren?
3. Wie gehen Sie mit Situationen um, in denen Sie Informationen benötigten um eine Arbeit fertig zu stellen, sie aber nicht erhalten haben?
4. In welcher Situation haben Sie es geschafft, den Kurs eines Teams zu korrigieren, von dem Sie sicher waren, dass er falsch ist?

Unabhängig von den angewandten Methoden des Recruiting-Prozesses müssen sich Unternehmen folgendes vor Augen führen:

Jene, die Talente und nicht Fähigkeiten anheuern, eine Umgebung schaffen in der Fähigkeiten erlernt und bestärkt werden, legen den Grundstein für eine dauerhaft fruchtbare Kultur hoher Innovationskraft. In den meisten Fällen wird auf eine exakte Übereinstimmung mit dem Anforderungsprofil geachtet. Bewerbern kann ich nur raten, von diesen Unternehmen Abstand zu nehmen, denn eines ist klar: sie sind nicht willens in Dich zu investieren.

• Business System Development — Als technischer Wissensträger für das Lean Management ist das KPO verantwortlich für die Entwicklung eines Business Systems im allgemeinen, bzw. eines Produktionssystems im speziellen (denken wir beispielsweise an TPS). Darüber hinaus müssen ein Curriculum und die entsprechende Bildungseinheiten um das System entwickelt werden.
• Change Management — Das KPO betreut sämtliche Veränderungen als Berater, Trainer, Betreuer und Katalysator. Es nimmt nicht die Rolle des Initiators an. Es kann lediglich Empfehlungen aussprechen.
• Personalentwicklung — Typischerweise wird ein Unternehmen kurze Zeit nach der Transformation von einem Kaizen-Sensei begleitet, bis es auf eigenen Beinen stehen kann. Das gelingt nur, wenn Kaizen von der gesamten Belegschaft eines Unternehmens verinnerlicht wird. Das KPO beteiligt sich aktiv an der Aus- und Weiterbildung des Personals, sowohl im technischen als auch im organisatorischen Bereich.
• Daily Kaizen etablieren — Der Übergang zum täglichen Kaizen steht dem systematischen Ansatz des Kaizen-Events gegenüber. Ersterer ist eine Frage der Tiefe der Durchsetzung von Kaizen, letzterer ein organisierter Systemansatz des Lean Managements. Beides zusammen ist das ultimative Ziel und verspricht den größten Nutzen der Transformation. Das KPO ist also beim Training der Belegschaft (wichtig hier: Train-the-Trainer) und der Entwicklung von Problemlösungsqualitäten die treibende Kraft. Es ist die einzige Instanz einer Organisation, welche eine echte Kaizen-Kultur auf jeder Ebene schaffen und erhalten kann.
• Kaizen-Events organisieren — Die Organisation von Kaizen-Events ist ganz klar die Domäne des KPO. Als technischer Wissensträger kann nur das KPO die richtigen Themen (Focus Areas), Vorbereitungen und die Nachbearbeitung vollständig organisieren. Das KPO ist hier ganz klar in einer aktiven Rolle.
• Office Management — Das Office im Sinne des Kaizen ist der virtuelle und physische Wirkungskreis des Kaizen Promotion Office. Es dreht sich alles um Informationsaufbereitung und -austausch, Planung von Weiterbildungsmaßnahmen und die Aufrechterhaltung der kontinuierlichen Verbesserungsmaßnahmen durch die jeweiligen Verantwortlichen.

Was braucht’s für einen Kaizen Promotion Office?

Die oben genannten 6 Aufgaben und Ziele des KPO erfordern in weiten Teilen ganz spezifische Fachkenntnisse und Fähigkeiten. Diese unterscheiden sich selbstverständlich sehr stark von der jeweiligen Position, die ein Protagonist innerhalb des KPO einnimmt. Beispielsweise hat ein KP Officer auf Unternehmensebene (meist ein Mitglied der Geschäftsleitung oder Bereichsleitung) einen anderen Focus als der einer Business Unit.

Dennoch lässt sich ein recht gutes Bild von den allgemeinen Kompetenzen solcher Funktionsträger zeichnen. Dazu zählen:

• Fähigkeit zur strategischen Planung und Ausrichtung
• Führungsstärke im Change Management
• Ausgeprägtes Zeit- und Selbstmanagement
• Führungsstärke im Team und die Fähigkeit das Team richtig zu positionieren (im Sinne von Konsensbildung)
• Verantwortung für getroffene Maßnahmen
• Flexibilität
• Das Gespür für Talente und deren Förderung
• Hohe soziale Kompetenz und Kommunikationsstärke

Ganz ohne Zweifel sind einige der genannten Soft-Skills nur sehr schwer zu erlernen (manche haben sie einfach) jedoch können Menschen mit Hilfe intensiven und gezielten Coachings (und nicht zuletzt durch die gesammelte Erfahrung) auf diesen Gebieten große Fortschritte erzielen.

Nun, was die technischen Kenntnisse angeht, quasi all das “was” zu tun ist, so sind es primär die drei Bereiche Lean Principles, Systeme und Werkzeuge (Techniken). Erfahrung ist der beste Lehrer, noch besser ist die Instruktion durch einen erfahrenen Sensei, doch irgendwo muss der Anfang gemacht werden. So bleibt oft nicht anderes übrig, als sich dem Studium des Lean Managements zu widmen.

Es mangelt ganz und gar nicht an Zertifizierungsprogrammen, allerdings wird in den meisten Fällen ein rigoroses Programm abgespult, das einen hohen Zeitaufwand und entsprechende Hingabe abverlangt. Insgesamt sollten auf jeden Fall eine natürliche Neugierde und das Verlangen nach intellektueller Erkenntnis (beides darf ruhig leicht obsessive Züge annehmen) vorhanden sein. Letztendlich bewegen wir uns alle im Kreislauf studieren, anwenden, lernen und leeren. Wissen ist zum Teilen da!

Während es unterschiedliche Ansätze für die Organisationsentwicklung gibt, gehe ich von einem Prozessmodell aus, was bedeutet, daß ich zusammen mit meinen Kunden die Situation untersuche, Probleme identifiziere und Lösungen herbeiführe. Ziel dieses Ansatzes ist, den Kunden mit der Fähigkeit auszustatten, Probleme in Zukunft selbst diagnostizieren und lösen zu können. Statt Abhängigkeit zu fördern, verhelfe ich Unternehmen zu mehr Unabhängigkeit.

Naturgemäß ist jede Beratungstätigkeit auf dem Gebiet der Organisationsentwicklung immer wieder neu und einzigartig, wie die Unternehmen und die Märkte in denen sie sich bewegen. Wenn Du Dich für ein Engagement im Bereich OE interessierst findest Du unten eine Auswahl von Projekten, die ich typischerweise bearbeite. Durch Verbindungen zu unterschiedlichen Beratungsunternehmen kann ich jederzeit und auf Deinen Wunsch hin auf andere Experten für Domänen außerhalb meiner eigenen zurückgreifen.

Was ich als Organisationsentwickler so alles mache

• Team Development — Wie finde ich das richtige Team? Wie führe ich Teams aus der Krise? Wie motiviere ich Teams?
• Strategische Planung — Was möchte ich erreichen? Wie sehen meine Ziele aus? Wie kann ich schwierige Szenarien antizipieren?
• Change Management — Wie führe ich Mitarbeiter nach Fusionen zusammen? Wie rufe ich strategische Initiativen ins Leben? Wie kann ich die Unternehmenskultur positiv beeinflussen?
• Coaching — Der Manager als Mentor? Führungskräftetraining für das mittlere und Top-Management

Gleichzeitig können gute Prozessmanager helfen, Unternehmen aus einer ungeordneten und von Bauchentscheidungen behafteten Existenz in eine geordnete, geplante und zielgerichtete Zukunft führen.

Leistungsangebot

• Die Optimierung der Service-Landschaft durch eine 360°-Analyse der Situation. Sie ist Voraussetzung für einen auf Ihre strategischen Stärken ausgerichteten Implementierungsansatz zur Optimierung Ihrer Prozesse. Ihre Kunden und Mitarbeiter werden es Ihnen danken.
• Ressourcenplanung und Organisationsentwicklung — Mit der Veränderung von Prozessen sind oftmals auch personelle Veränderungen verbunden. Meine ganzheitliche Methodik vernachlässigt diesen Aspekt nicht.
• Die strategische Ausrichtung Ihrer IT-Landschaft auf Ihre Unternehmensziele ist unabdingbar für eine dauerhafte Wettbewerbsfähigkeit, ausgeprägte Agilität und exzellenten Service, sowohl unternehmensintern wie auch für Ihre Kunden.

Meine Aufgabe ist es mit ungetrübtem Blick und unvoreingenommenen Betrachtungen, Ihre Visionen in die Wirklichkeit umzusetzen.

Ganz ähnlich gestalten sich auch die Herausforderungen an die Führungskräfte der Organisationen, welche sich auf die zunehmende Unsicherheit und Intensivierung des Wettbewerbs einstellen müssen. In den meisten Fällen heißt das: weniger ist mehr.

Das mittlere und das Top Management sehen sich meist Problemen gegenüber, für die es keinen klaren Lösungsansatz gibt. Erfolg setzt aber voraus, dass sich Entscheidungsträger gezielt den Innovationen widmen und neue Denkansätze im Unternehmen kultivieren. Das Selbstverständnis, welches Organisationen von sich haben, muss sich den neuen Umständen anpassen.

Historisch betrachtet hat das Training von Führungskräften die Problemlösungskompetenz stark vernachlässigt. So wurde nicht selten die Theorie vertreten, dass jedes Problem mit einer einfachen Lösung zu beseitigen sei, die Kunst bestünde nur darin, die richtige Lösung innerhalb eines akzeptablen Zeitfensters zu finden. Das “Flickschusterei” das Problem nur kurzfristig oder gar nicht beseitigt ist inzwischen hinreichend bekannt.

Die betroffenen müssen sich dann oft fragen lassen: Was hast Du Dir nur dabei gedacht? Dabei müßte man vielmehr fragen: Wie hast Du dabei gedacht?

Eines meiner 10 Prinzipien des Managements ist systemisches Denken, nämlich komplexe Interaktionen auf struktureller, technischer, politischer und personeller Ebene zu erkennen und zu analysieren. Systemisches Denken etabliert eine neue Perspektive, und erlaubt es Managern und Führungskräften das große Ganze besser zu verstehen. Auf diese Weise werden kluge und dauerhafte Lösungen für Probleme gefunden.

Unsere Arbeitsplätze haben sich in den letzten dreißig Jahren enorm verändert. Sie sind schnellebig geworden, wir sind einem Informationsüberluss unterworfen und stehen ständig unter Strom (glücklich ist, wer das spätestens an der Wohnungstür ablegen kann). Gekennzeichnet ist diese Tendenz von der Tatsache, dass, dominiert von der Orientierung an Werten und Zielen, oftmals das Wichtige durch das Dringliche verdrängt wird.

Damit verbunden ist eine der größten Hindernisse systemischen Denkens, nämlich die ungebremste Geschäftigkeit. Vertieft im Sumpf der unendlich vielen Details unserer Existenz ist es nicht schwer, das große ganze aus dem Blick zu verlieren. Das Management ist gefordert, Einfachheit, Klarheit und Sicherheit in einer flüchtigen und komplexen Umgebung zu schaffen.

Vor einigen Jahren, beispielsweise, konnte ich einen Kunden helfen zu erkennen, dass die Lösung zur Bekämpfung schlechter Recruiting-Ergebnisse nicht in der Zentralisierung der internationalen Bemühungen liegt. Als er das große Bild vor sich sah, konnte eine Recruiting-Infrastruktur geschaffen werden, die es erstmals ermöglichte, lokale Talente und hochspezialisierte Fachkräfte für die jeweiligen Standorte zu gewinnen. Das wurde durch systemisches Denken erreicht, weil wir endlich begannen, Beziehungen zu betrachten. Daraus resultierten Muster für nachhaltige Veränderungen und kontinuierliche Verbesserungen.

Aufbauend auf den 7 Todsünden der Verschwendung (YouTube) brachen Produktionsleiter mit Kaizen im Rucksack auf zur Suche nach Muda und Eliminierung derselben. Wurde das richtig und gut gemacht, konnten signifikante Verbesserungen in kurzer Zeit beobachtet werden, welche heute noch anhalten.

Heutzutage wird es immer wichtiger die Verwaltungen solcher Produktionsbetriebe ebenfalls einer solchen Aktivität zu unterziehen.

Warum ist das so? Weil Kunden bessere Produkte und Dienstleistungen zu geringeren Preisen möchten, das ganze natürlich auch schneller als üblich. Aus Kundensicht beginnt die Uhr mit dem Absenden der Bestellung an zu ticken und hört erst auf, wenn das Produkt geliefert oder die Dienstleistung erbracht wurde. Somit lohnt sich ganz gewiss ein Blick über den Horizont des Produktionsalltags hinaus.

Muda im Office

In der Produktion ist Lean Management ein alter Hut und bereits sehr gut etabliert. In der Verwaltung und Administration von Organisationen ist das noch nicht der Fall. Ein Grund ist sicher, dass dieser Bereich noch nicht so viel Aufmerksamkeit erhielt wie der Produktionsbereich, nicht zuletzt weil hier die größten Potentiale lagen.

Auf Produktionsseite verarbeiten wie Material und Teilerzeugnisse zu neuen Produkten. Der Fluß ist klar umrissen, wir können mit dem einzelnen Bauteil förmlich durch die Produktionsstufen wandern. Im Büro, mit all den unterschiedlichsten Tätigkeiten, Informationen und Interaktionen ist der Arbeitsfluß ganz und gar nicht so einfach zu durchschauen. Möchten wir unser Büro also von Muda befreien müssen wir einen anderen Blick auf die Prozesses werfen. Diesen Blick kann man sich aneignen. Wie das geht beschreibe ich diesen Blog Post.

Was ist Muda?

Im weitesten Sinne, kann Muda in jeder Operation oder Aktivität gefunden werden, die dem Endprodukt oder der Dienstleistung Mehrkosten auferlegt, ohne erkennbaren Mehrwert für den Kunden zu erzeugen. Betrachten wir administrative Aufgaben und Prozesse, so könnten folgende Aktivitäten potentielle Kandidaten sein:

• die Bewegung und Sortierung von Unterlagen
• Ablage von Unterlagen
• Wiederkehrende Tätigkeiten gleicher Art
• Wiederholung aufgrund von Fehlern
• Warten auf Freigaben von Dokumenten oder Tätigkeiten
• Unnötige Überprüfung getaner Arbeit
• Ineffiziente Workflows
• Veraltete und inadequate Software

Ein strategischer Ansatz zur Beseitigung von Quellen der Verschwendung würde, ebenso wie im Produktionsbereich, zu folgenden positiven Auswirkungen führen:

• Reduzierung der Verarbeitungszeiten, schnelle Antwortzeiten auf Kundenanfragen
• Eliminierung aller unnützen Aktivitäten
• Einfache, logische und schnell zu erlernende Arbeitsprozesse
• Reduzierung von Fehlern und damit verbundener Mehrarbeit
• Ständige Verbesserung durch das Team
• Geringere Kosten
• Hohe Moral und Leistungsfähigkeit des Teams

Wo fangen wir an?

Ein guter Ausgangspunkt sind immer Kernprozesse. Typischerweise gibt es in einem Unternehmen nicht so viele. Beispiele für Kernprozesse könnten die Auftragsbearbeitung oder die Produktentwicklung sein. Diese Prozesse untersuchen wir auf die Erfüllung Deiner subjektiven Erwartungshaltung hinsichtlich Qualität, Kosten und Zeitaufwand.

Zur Unterstützung sollten stets abstrahierte Flußdiagramme zur Hilfe genommen (Du hast doch welche, oder?) und die jeweilgen Prozess Owner (auch die existieren in Deiner Firma, nicht wahr?) hinzugezogen werden. Mit Hilfe der Diagramme besteht für alle beteiligten ein gemeinsames Verständnis für den aktuellen Prozessablauf und welche funktionalen Bereiche verantwortlich für welche Teilprozesse sind.

Anschließend müssen wir nur noch ein messbares Ziel und einen Zeitplan für die Prozessoptimiertung definieren. So etwas könnte beispielsweise lauten: “Beantwortung von 95% aller Kunden anfragen innerhalb von 12 Studen bis zum Ende des zweiten Quartals”.

Techniken und Werkzeuge

Als Kenner des Kaizen möchte ich daher besonderes Augenmerk auf folgende Werkzeuge zur Identifikation von Muda legen:

1. Analyse der Wertschöpfungskette
2. Prozessmodellierung
3. Pareto-Analyse und Fischgretendiagramme
4. Theory of Constraints (von SixSigma)

Zu den empfehlenswerten Techniken zur Beseitigung von Muda gehören:

5. Value Stream Mapping
6. One Piece Flow Processing
7. Prozesse mit minimalen Fehlerquellen (Poka Yoke)
8. Das sog. Cellular Processing

Diese acht Schritte sind der Schlüssel zum Lean Office.

Extrem wichtig ist bei der Implementierung der ausgewählten Strategie, das Du stets den gesunden Menschenverstand anwendest und nicht gegen ihn arbeitest.

Fazit

Das war ein kurzer Exkurs in das Lean Office, welches immer wichtiger wird um den Kreislauf der Optimierungsbemühungen, welche in der Produktion begannen, zu schließen.

Zusätzlich ist es enorm empfehlenswert, zusätzliche Anstrengungen im Bereich der Führungsqualität, der Selbstbestimmung und der Stärkung von Partnerschaften mit Lieferanten zu unternehmen, da hier ganz enorme Verbesserungspotentiale verborgen liegen.

Ausführlicher möchte ich an dieser Stelle ausdrücklich nicht werden, da sich ganze Bücher mit diesem Thema befassen und neben dem Kaizen-Aspekt insbesondere soziale und politische Betrachtungen eine wichtige Rolle spielen.

Mehr Flexibilität, höhere Qualität, geringere Durchlaufzeiten, besserer Kundenservice, optimale Kommunikation zwischen Abteilungen und KollegInnen. All das erreichst Du mit Kaizen. In Ergänzung mit 5S (Seiri 整理, Seiton 整頓, Seisō 清掃, Seiketsu 清潔 und Shitsuke 躾) wird auch die Büroarbeit in neuer Effizienz erstrahlen.

Mein KAIZEN-Programm für Dich:

Eine typische Dienstleistung umfasst meine Präsenz vor Ort zur Evaluierung der aktuellen Umgebung uns Aufnahme der besonderen Eigenschaften Deines Unternehmens. Ich erfasse und demonstriere die Auswirkungen der Veränderungen auf alle Rollen über alle Ebenen hinweg.

Übrigens, folgende Artikel könnten für Dich interessant sein:

• Prozesse für agiles Softwareprojektmanagement
• Agilität für Projektmanager

Übrigens, folgender Artikel könnte für Dich interessant sein: Präsentieren wie die Profis

Agile Entwicklungsmethoden haben die Industrie im Sturm erobert. Das liegt hauptsächlich daran, das es einfach funktioniert: höhere Erfolgsraten, bessere Qualität, gesteigerte Kundenzufriedenheit, besseres ROI (Return On Investment) und schnellere Markteinführung (Time To Market).

In diesem Artikel beginnen wir mit einer allgemeinen Betrachtung des Agilen Prozessmodells um die unterschiedlichen Ansätze in den richtigen Kontext setzen zu können. Anschießend betrachten wir das vorgestellte dreistufige Modell genauer und erfahren wie die drei aufeinander aufsetzen. Zum Abschluß wenden wir das Modell beispielhaft auf die Entwicklung einer Software an und enden mit einigen Hinweisen für eine erfolgreiche Einführung agiler Softwareentwicklung.

Das agile Prozessmodell

Im Zusammenhang mit Softwareprojekten und damit verbundenen Prozessen wird immer wieder von Maturity gesprochen. Daß es sich dabei um einen inzwischen überladenen Begriff handelt ist nicht Verdienst der exzellenten Arbeit des Software Engineering Istitute (SEI) der Carnegie Mellon University, die das Capability Maturity Model Integrated (CMMI) entwickelt hat und eine Abwandlung speziell für die Durchführung von Softwareprojekten CMMI-DEV hervorbrachte. Vielmehr wurde der Begriff Maturity auf die Prozessoptimierung angewandt, während das hier vorgestellte Agile Process Maturity Model (APMM) vielmehr bemüht ist, einen Rahmen für die agile Softwarenentwicklung zu stellen, so daß die unterschiedlichen Methoden in den richtigen Kontext gesetzt werden können. Wir könnten auch sagen: das APMM ist das schlanke Geschwister vom CMMI.

Wie angedeutet ist APMM ein dreistufiges Modell dessen Ebenen aufeinander aufsetzen:

Abbildung 1

Die drei Stufen sind folgendermaßen zu verstehen:

Level 3: Scaling Agility

Stufe 3 konzentriert sich auf einen wichtigen Skalierungsfaktor in agilen Prozessen, beispielsweise Teamgröße oder der Grad der geographischen Verteilung des Teams. Es muß sich dabei aber nicht immer um eine quantitative Größe handeln, denn auch der Einfluß von Regulatorien oder der Grad der Einhaltung von Standards sind skalierend Faktoren in agilen Entwicklungsprozessen.

Level 2: Disciplined Agility

In Stufe 2 schauen wir über den Tellerrand hinaus und decken den gesamten Software Delivery Life Cyle (SDLC) ab. Beispiele sind Dynamic System Development Method (DSDM) und OpenUP (Open Unified Process).

Level 1: Agile Software Development

Stufe 1 betrachtet nur einen kleinen Teil des gesamten Entwicklungsprozesses, da nur die agilen Aspekte des Manifestos von Bedeutung sind. Beispiele sind Scrum oder XP.

Das Modell mag zum jetzigen Zeitpunkt noch nicht besonders einleuchtend sein. In den folgenden Abschnitten beleuchten wir jede Stufe genauer und gehen immer wieder auf die Bedeutung im APMM ein.

Stufe 1: Agile Software Development

Die agilen Methoden auf Stufe 1 decken nicht den gesamten SDLC ab, sondern orientieren sich an den Werten des Agile Manifesto und vestehen sich als eine ganzheitliche Sammlung von empfohlenen Vorgehensweisen. Beispiele für die Implementierung der Stufe 1 sind die bekannten Vertreter:

Scrum

Projekt- und Anforderungsmanagement sind die Stützpfeiler von Scrum. Mittels Iterationen (Scrum spricht von Sprints) werden Zyklen zur Produktreifung definiert. Gepaart mit diversen Praktiken wie täglichen Stand-Up Meetings, Verwendung von Product Backlogs und klaren Rollen wie beispielsweise ScrumMaster und Product Owner entsteht ein Planungsgerüst, welches ganz nach Definition durch das Manifesto auf die Erstellung lauffähiger Software ausgerichtet ist. Abbildung 2 zeigt den Scrum Life Cycle.

Extreme Programming (XP)

XP ist eine Sammlung von Praktiken für die Softwareentwicklung, mit Fokus auf Programmiertechniken. Beispielsweise sind Pair Programming (zwei Entwickler an einem Modul gleichzeitig), Test-First Design (erst der Unit Test, dann die Implementierung) und Continuous Integration einige der propagierten Techniken für die Softwareentwicklung mit XP. Darüber hinaus bekennt sich auch XP zu Dingen wie Collective Ownership um die Bedeutung selbstorganisierender Teams herauszustellen.

Agile Data

Datenlastige Anwendungen erfordern oftmals andere Herangehensweisen als beispielsweise Steuerungssysteme. Für solche Fälle eignet sich Agile Data sehr gut, da hier nicht nur die Organisation und Entwicklungstechniken betrachtet werden, sondern auch die Modellierung, Datenbanktest und Database Refactoring.

Abbildung 2

Stufe 2: Disciplined Agility

Auf Ebene zwei wird der agile Prozess von Stufe 1 erweitert und berücksichtigt den gesamten SDLC. Der wesentliche Unterschied zu Stufe 1 ist die Berücksichtigung einzelner Aspekte des Prozesses (nicht der Techniken oder Technologien), beispielsweise Testing oder Process Improvement. Ganz typisch handelt es sich bei Discplined Agility auch um einen evolutionären, iterativen Entwicklungsansatz zur Produktion hochqualitativer Software, der sich durch den Einsatz von Risiko- und Value-Driven Management { Value-driven Managment bedeutet in diesem Zusammenhang, die aktuellen Marktentwicklungen während des gesamten SDLC immer wieder zu bewerten um sicherzustellen, daß ein gewinnbringendes Produkt entsteht, welches auf dem Markt bestehen kann. } auszeichnet.

Disciplined Agility vertraut auf qualifizierte und selbstorganisierende Teams, die von einer frühzeitigen und starken Einbindung der Auftraggeber profitieren. Auf diese Weise kann das Team die Anforderungen des Auftraggebers besser verstehen und auf Veränderungen schneller reagieren. Auf der anderen Seite ist der Entwicklungsprozess transparent und kann jederzeit vom Auftraggeber durch aktive Mitwirkung, beispielsweise in Form häufigen Feedbacks, korrigiert werden.

Beispiele für agile Prozesse der Stufe 2 sind:

Open Unified Process (OpenUP)

OpenUP erweitert und kombiniert bekannte Praktiken aus Scrum, XP, AD und RUP für die Anwendung auf verteilte, virtuelle Teams. Dabei werden Methoden wie Whole Team, Stand-Up Meetings, Risikomanagement, TDD, aktive Einbindung der Auftraggeber und Continuous Integration angewandt. OpenUP ist ein Open Source Framework, das Teil des Eclipse Process Framework ist.

Rational Unified Process (RUP)

RUP ist ein umfassendes Rahmenwerk für Prozesse in der Softwareentwicklung, das unterschiedlich ausgeprägt werden kann, je nachdem wie die es die aktuelle Situation erfordert. Eignet sich für sehr agile wie auch traditionelle Ansätze gleichermaßen. Es deckt die Praktiken Risk Management, Whole Team, TDD, Business Process Sketching und Continuous Integration ab.

Dynamic System Development Method (DSDM)

DSDM eignet sich besonders für Applikationen mit komplexen Benutzeroberflächen. Es ist ein agiler Ansatz, der von Rapid Application Development abgeleitet wurde und sehr stark auf Rapid Prototyping, Testing, Machbarkeitsstudien und Reversible Changes setzt.

Feature-Driven Development (FDD)

FDD zeichnet sich durch den Einsatz von Modellierungstechniken und kurzen Iterationen aus. Zu den typischen FDD-Praktiken gehören Class Ownership (PDF), Domain Object Modeling, Development by Feature, Feature Teams und regelmäßige Übersetzungen der Software (Regular Builds). Eine ausgezeichnete Kurzbeschreibung von FDD findest Du unter The Coad Letter: Issue 70.

Eine akstrahierte Darstellung eines vollständigen SDLC wird in Abbildung 3 dargestellt. Als Beispiel erweitern wir Scrum um wichtige Aspekte des SDLC, denn zum ersten wird eine explizite Projektgründungsphase (Project Inception) allen anderen Aktivitäten vorangestellt, in der wir erste Modelle konstruieren, das Team bilden und die finanzielle wie auch institutionelle Unterstützung des Auftraggebers sichern. Zum zweiten integrieren wir unabhängige Tests, um sicherzustellen, daß Fehler nicht durchs Raster fallen, was insbesondere auf nicht-funktionale Merkmale und Integrationstest zutreffen kann. Die nächste Erweiterung von Scrum betrifft das Product Backlog, das nicht nur priorisierte Aufgabenelemente berücksichtigt, sondern auch Tätigkeiten wie die Teilnahme an Trainings (auch zu fachfremden Disziplinen), Feedback zu Arbeiten anderer Teams und die Bewertung von Fehlern sowie deren Einordnung in das Backlog. Das letzte Merkmal des beschriebenen agilen SDLC ist die ausdrückliche Einführung einer Übergangs- und Produktionsphase (Release to Manufacturing).

Abbildung 3

Stufe 3: Berücksichtigung von spezifischen Faktoren

Zu Beginn der agilen Bewegung wurden die Praktiken zunächst auf kleinere überschaubare Projekte angewandt und relativ pragmatisch angegangen. Heutzutage wenden Organisationen agile Methoden auf ein weitaus größeres Wirkungsspektrum an. Agilität der Stufe 3 berücksichtigt die Komplexität der Projekts in Bezug auf bestimmte Faktoren, die wie Skalierungen angewandt werden können. Folgende Tabelle faßt einige Faktoren zusammen, die Auswirkung auf die Komplexität eines Projekts haben.

Jedem Faktor ist eine Komplexitätsskala zugeordnet und jedes Team wird eine andere Kombination aufweisen, so daß der Prozess, die Teamstruktur und die Werkzeuge den Rahmenbedingungen angepaßt werden müssen. Agile Prozesse der Stufe 1 im APMM funktionieren am besten wenn alle Faktoren in der Skala auf der linken Seite liegen (eine geringe Komplexität aufweisen.) Prozesse der Stufe 2 zeichnen sich durch einen oder mehrere Faktoren aus, deren Komplexität entweder in der Mitte oder auf der rechten Seite der Skala liegen. Liegen fast alle Faktoren auf der rechten Seite wird der Entwicklungsprozess extrem komplex und bedarf spezieller Werkzeuge zur Koordinierung verteilter Teams, Metriken zur Überwachung der Compliance und Berater, die auf beispielsweise auf Risikomangement und andere geschäftsspezifische Disziplinen spezialisert sind.

Während Stufe 1 und Stufe 2 tatsächlich als eigenständige Prozesse charakterisiert werden können, ist die Stufe 3 als Leitfaden für die Bewertung der Projektkomplexität mittels einer einfachen Skala gedacht. Letzendlich wirken sich die Erkenntnisse aus Stufe 3 auf den Prozess der Stufe 2 dahingehend aus, daß bestimmte Schritte/Abläufe unterschiedlich gewichtet sind und einer eigenen internen Analyse unterzogen werden, um dem identifizierten Komplexitätsgrad in diesem Bereich gerecht zu werden.

Was bedeutet das für die Praxis?

In der Praxis wird in fast allen agilen Methoden aus Stufe 1 eine Projektinitiierung durchgeführt, allerdings nicht immer explizit mit der klaren Zielsetzung, die Finanzierung des Projekts zu sichern und ausführlich Zeit für eine Definition der initialen Anforderungen und der gewünschten Vorgehensweise einzuplanen (Länge der Iterationen, Zusammenstellung des/der Teams, Wahl des Prozessmodells, etc.). Es ist nicht unüblich zwischen ein bis zwei Wochen dafür anzusetzen.

Im Idealfall nehmen daran Teil:

• die Auftraggeber: Product Manager/Owner, Business Owner und Process Owner
• die Auftragnehmer: Key Account Manager und Business Consultant, Senior Developers, CTO

An der Zusammensetzung sehen wir schon, daß wir nicht nur das Ziel haben, die Anforderungen zu verstehen, sondern auch Risiken zu minimieren, was primär durch die Vertreter der Auftraggeber garantiert wird, die in diesem Beispiel teilweise redundant sind, dadurch aber jeweils eine eigene Sicht auf mögliche Risiken ermöglichen.

Parallel dazu entwerfen CTO und die Senior Developers eine vorläufige, grobe Architekture, identifizieren Subsysteme und Schnittstellen und tragen wichtige Informationen zur Aufteilung der Arbeit auf das oder die Teams zusammen. Je nach Schwerpunkt des Produkts sind die Business Consultant beispielsweise auf Compliance in regulierten Umgebungen spezialisiert oder sind externe Berater zum Thema Baurecht, weil das Endprodukt eine Software für Ausschreibungen in der Baubranche ist.

Der Product Owner (erfahrungsgemäß oftmals Product Manager des Auftraggebers) priorisiert die Anforderungen und versorgt die Teammitglieder mit Details über Geschäftsprozesse. Er/Sie wird dabei von den Business Ownern und/oder Process Ownern unterstützt.

Nachdem die erste Iteration (Inception) vorbei ist, wird in der zweiten der Fokus auf die Entwicklung eines Proof of Concepts gelegt um zu zeigen, daß die gewählte Architektur tatsächlich funktioniert. Am Ende der Iteration wird dem Auftraggeber das Ergebnis präsentiert, wobei sich das Team hier ausschließlich auf die Demonstration der kritischen Systemeigenschaften konzentriert. Beispielsweise könnte eine kritische Anforderung sein, daß eine Anwendung 5.000 Transaktionen pro Minute bei durchschnittlich zehn angemeldeten Benutzern für mindestens 24 Stunden verarbeiten können muß.

Durch die richtige Wahl der Teammitglieder und einer ausführlichen Projektgründungsphase konnte das Gesamtrisiko des Projekts drastisch reduziert werden, weil zum einen die Anforderungen richtig verstanden wurden und demonstriert werden konnte, daß die kritischste Komponente den ersten Test bestanden hat.

Was die Projektkommunikation betrifft, ist es stets empfehlenswerte eine Single Point of Communication Strategie zu verfolgen. In Bezug auf Projektkoordination, Ressourcenplanung usw. kommunizieren zwischen Auftragnehmer und Auftraggeber lediglich Key Account Manager (Auftragnehmer) und Product Manger (Auftraggeber). Fachspezifische Themen koordiniert die Teamleitung mit den Business Consultants auf Auftragnehmerseite und den Business und Process Ownern auf Auftraggeberseite. Idealerweise, aber praktisch leider kaum durchführbar, sind die Business und Process Owner stets verfügbar und nehmen an täglichen Meetings teil. Besonders in komplexen Projekten mit hohem Risiko ist dieser Punkt obligatorisch.

Technische Fragen beantwortet die Senior Developer und der CTO in täglichen Meetings.

Abschließende Gedanken

Viele Organisationen konnten ihre agilen Prozesse erfolgreich skalieren (Stufe 3) und Du kannst es auch. Wenn Du Dir treu bleibst und nicht der Rhetorik der Vertreter aus Stufe 1 erliegst ist das schon ein wichtiger Schritt. Du solltest versuchen, mindestens einen agilen Prozess der Stufe 2 zu etablieren, da der gesamte SDLC berücksichtigt wird und nicht nur ein Teil davon (nur die Konstruktionsphase). Sei darauf vorbereitet, daß Du Dich über kurz oder lang in einer Situation befinden wirst, in der Dein Prozess skalieren muß (Stufe 3) und das viele Teams unterschiedlich skaliert werden müssen. Mit einem realistischen, maßgeschneiderten Ansatz kann der ROI gesteigert, die Qualität erhöht und die Kundenzufriedenheit maximiert werden.