0

Der Common-Sense-Prozess

Traditionelle Prozesse mit ihrer vollständigen Rollen-, Ergebnis- und Tätigkeitsbeschreibung geraten vielerorts in Verruf, zu bürokratisch, schwerfällig und unflexibel zu sein. Agilen Methoden hingegen hängt der Makel mangelnder Systematik und hohen Chaosanteils an. Doch beide Ansätze bieten auch Vorteile, und sie lassen sich sogar optimal integrieren. Im Ergebnis steht die bestmögliche Lösung: der „Common Sense“-Prozess.

Für die Schwergewichte unter den Prozessen, die vollständig ausformulierten und lückenlos qualitätsgesicherten Modelle, sprechen gute Argumente. Eine Verfahrensdefinition, die eine hohe, durch Industriestandards gesicherte Reife aufweist, ist häufig aufgrund vertraglicher Gestaltung zwischen Kunde und Lieferant unerlässlich. Automobilhersteller etwa erwarten von ihren Zulieferern eine gewisse CMMI bzw. Automotive SPICE -Reifestufe. Darüber hinaus wird für Produzenten sicherheitskritischer Systeme eine lückenlos überprüfbare, stets reproduzierbare Arbeitsweise in Entwicklungsprojekten gesetzlich sanktioniert. Generell bringen qualitätsgesicherte Standardprozesse mehr Sicherheit in die Planung und Finanzierung von Projekten.

Zugleich gewinnen leichtere Methodiken wie Extreme Programming (XP) oder Scrum, die unter dem Begriff „agil“ zusammengefasst werden, seit einigen Jahren immer mehr Anhänger. Sie versprechen kürzere Reaktionszeiten, höhere Flexibilität, weniger Verwaltungsüberbau und eine bessere Zusammenarbeit zwischen Entwicklern und Kunden.

Agil oder nicht agil – das ist hier die Frage

In vielen Entwicklungsteams sind daher Diskussionen über den Entwicklungsprozess aufgeflammt. Nicht nur in Kaffeeküchen, sondern in Prozessverbesserungsprojekten, auf Managementebenen und in QA-Abteilungen kommt es häufig zu lebhaften Streitgesprächen: Sind „schwere“ Prozesse nun eher Dinosaurier oder vielmehr wesentliche Fundamente des Unternehmenserfolgs? Sollte man lieber auf agile Verfahren umsteigen? Ist das überhaupt möglich? Schließlich sind viele Unternehmen nach SPICE oder ISO 9001 zertifiziert und fürchten den folgenschweren Verlust ihrer Zertifikate.

Aus Sicht eines Prozessberaters müssen sich die beiden Optionen nicht ausschließen. Ganz im Gegenteil: Da es sich um Verfahren mit gleicher Zielsetzung handelt, sind sie zumindest prinzipiell miteinander kombinierbar. So kann eine pragmatische Sowohl-als-auch-Lösung das Entweder-oder-Dilemma überwinden.

Doch wie kann das gehen? Die unterschiedliche Fokussierung der beiden Konzepte legt eine Verschachtelung nahe. Ein CMMI-Level-3-Prozess deckt den kompletten Entwicklungsstrang ab, inklusive Analyse, Implementierung und Qualitätssicherung. Zusätzlich wird von einem solchen Prozess erwartet, dass er Aufgaben aus organisatorischen, verwaltungstechnischen und prozessunterstützenden Bereichen regelt, etwa Projekt- und Konfigurationsmanagement, organisatorische Policies, Prozessverbesserungsmaßnahmen, Mitarbeiterschulung etc. Die meisten dieser Aufgaben sind für agile Methodiken in der Regel zu weit von der eigentlichen Entwicklung entfernt und daher unsichtbar oder als nicht wesentlich angesehen.

Best of both Worlds

Die agil-traditionelle Prozessintegration lässt sich am besten an der Schnittstelle zwischen Entwicklung und den übergeordneten und unterstützenden Prozessen realisieren. Wenn wir uns vorstellen, dass damit Teile des „V-Modells“, des Kernstücks der meisten traditionellen Prozessmodelle, durch die agile Kette der Backlog/Sprint-Aktivitäten (Scrum) ersetzt werden, entsteht ein logisches Hybridmodell, das man symbolisch wie folgt darstellen kann:

Prozesslandschaft mit einer agilen Kernkomponente

Abbildung 1: Prozesslandschaft mit einer agilen Kernkomponente

 

Die dahinterstehende Idee ist einfach: Aus einem vollumfänglichen Anforderungsmanagementprozess, in der obigen Abbildung symbolisch als „Define Release Scope“ dargestellt, erhält man eine Release-Spezifikation. Diese wird, in Scrum-Terminologie als Backlog bezeichnet, in den Scrum-Strang „geschoben“. Natürlich läuft dies im Detail komplexer ab, es entspricht aber dem weitverbreiteten, iterativen Entwicklungsparadigma und harmonisiert daher gut mit dem V-Modell. Auf der Grundlage des Backlogs werden Sprints durchgeführt, die kurzfristig lauffähige Builds mit inkrementell wachsender Funktionalität herausbringen. Ist der Backlog, nach all seinen Aktualisierungen, nominell abgearbeitet, erfolgt die finale Qualitätssicherung und Auslieferung („Deliver the Release“).

Voraussetzungen müssen erfüllt sein

Damit das Ganze Hand und Fuß hat, müssen natürlich noch verschiedene Fragen beantwortet werden: Wie verträgt sich die agile Selbstorganisation des Entwicklerteams mit den strengen Vorschriften der CMMI- (oder SPICE-)Standards? Wie sollen die Rollen definiert werden, wenn z.B. ein Projektmanager in bestimmten agilen Methodiken gar nicht vorgesehen ist? Wie kann gesichert werden, dass der Prozess wiederholbar und sauber dokumentiert ist? Wie kann man den Prozess an verschiedene Projektarten mit wenig Aufwand anpassen (Tailoring)? Wie gut lässt sich der Prozess angesichts der agilen Liefervorschrift (lauffähige Builds in kurzen Zeitabständen) skalieren? Diese und weitere Fragen können von einem erfahrenen Prozessmanager im Detail ausgearbeitet werden.

Natürlich hat die Sache einen Haken: Der Prozessmanager (Linienrolle, es kann auch ein Prozessteam oder eine Aufgabe des Project Management Office sein) muss sowohl über umfangreiche Kenntnisse aller entwicklungsrelevanten Organisationsaspekte verfügen als auch über ein tiefgreifendes technisches Verständnis und fundiertes Wissen über agile Verfahren. Es muss eine Person – oder ein dediziertes Team, was aber wegen des Abstimmungsaufwands schwieriger wird – sein, die sowohl mit CEO als auch mit dem technischen Entwicklerteam reden kann. Mangelnde Kenntnisse in einem dieser Bereiche können zu einem ineffizienten Prozessdesign führen. Als Schnittstelle zwischen dem traditionellen Prozessrahmen und dem dynamischen (agilen) Entwicklungskern ist diese besondere Qualifikation unabdingbar. Doch wie viele „Superexperten“, also Spezialisten mit umfangreicher, glaubwürdiger Entwicklererfahrung und zugleich fundiertem Managementwissen, sind landesweit verfügbar?

Fazit

Abgesehen von diesem Qualifikationsproblem stellt die Hybridlösung für Prozessverbesserungsvorhaben eine sehr interessante progressive Variante dar. Deshalb wird dieses Modell in unserer Beraterpraxis zunehmend nachgefragt. Die Aufhebung des scheinbaren Widerspruchs „agil oder traditionell“ bildet einen besonders attraktiven Aspekt. Statt eines entweder agilen oder „Heavy Weight“-Modells erhält man einen Common-Sense-Prozess. Er enthält sowohl den kompletten traditionellen Prozessrahmen als auch die entwicklerzentrische, dynamische, agile Komponente. Durch eine geschickte Gestaltung des Prozesses wird die Kreativität der Mitarbeiter im Entwicklungsteam nicht durch übermäßige Bürokratie gebremst, zugleich ist die Prozessqualität gesichert.

Zu schön, um wahr zu sein? In unserer Beraterpraxis haben sich agile Elemente gut bewährt. Agilität ist nicht bloß ein Hype. Man könnte den Trend als Reaktion auf die mancherorts übermäßig bürokratisierte Prozessgestaltung ansehen. In der Vergangenheit zeigte sich, dass vielen Modeerscheinungen häufig wichtige Erkenntnisse zugrunde liegen. Eine pragmatische und systematische Integration dieser Erkenntnisse in die Betriebsabläufe (z. B. Entwicklungsprozesse) ist mit dem Gebot einer kontinuierlichen Prozessverbesserung nicht nur bestens vereinbar, sondern stellt seine logische Konsequenz dar.

(Ursprünglich veröffentlicht am: 08. Oktober 2009)

_____________________________________________________________

Über den Autor

Roman MildnerRoman Mildner, zertifizierter Projektmanager (PMP) und Mitglied im United Mentors Network (UMN), ist seit 1992 in der IT und seit 1998 als unabhängiger Berater und Projektmanager tätig. Zu seinen Beratungsschwerpunkten gehören IT-Strategieberatung, Projektmanagment und Prozessberatung. Weitere Details finden sich auf seiner UMN-Seite. (S. auch Google)

Kommentar hinterlassen

Loggen Sie sich ein, wenn Sie ein registrierter Benutzer sind.




*