Problemfall: Gemeinschaftliches Schätzen mit allen Gewerken

Ein typisches Problem in Agenturen oder Web-Projekten im Allgemeinen, ist (mal wieder) die heterogene Zusammensetzung des Teams. Dieser Zustand ist von Scrum explizit so gefordert und auch für das Planungspoker-Meeting ([glossary id=’1589′ slug=’planungspoker’ /]) vorgesehen. Oft bekommt man aber von den Entwicklern zu hören, dass sie Anforderungen mit visuellem Schwerpunkt gar nicht bewerten können und Designer merken fehlendes Verständnis für technische Probleme an.

Hier ist es wichtig sich erneut vor Augen zu führen, warum gemeinsam geschätzt wird: Das Team schätzt gemeinsam, um alle nötigen Details einer Anforderung im Dialog zu entdecken und gemeinsam anschließend die Verantwortung für diese Einschätzung zu tragen. Dabei helfen Designer den Entwicklern oft wichtige Funktionalitäten im Frontend zu berücksichtigen. Weiterhin fordern die Regeln für gute Anforderungen das vertikale Schneiden von User Stories. Bei jeder [glossary id=’1577′ slug=’user-story’ /] sollten also alle Disziplinen wenigstens zu Teilen vertreten sein.

Die Aufwände der Gewerke werden auch nicht getrennt erfasst, um das Commitment auf eine gemeinsam gefundene Zahl zu erhöhen.

In Idealtagen oder in Story Points schätzen?

Mit der Schätzung in Story Points ([glossary id=’1585′ slug=’story-points’ /]) und in Idealtagen ([glossary id=’1588′ slug=’idealtag’ /]) habe ich nun zwei verschiedene Ansätze für agiles Schätzen vorgestellt. Welche sollte nun im Projekt benutzt werden? Beide haben dabei eindeutige Vor- und Nachteile. Die passende Auswahl muss, wie bei fast allen beschriebenen Techniken, im Einzelfall für das spezifische Projekt getroffen werden und zu dem geplanten Projektteam passen.

Einige der Vor- und Nachteile möchte ich an dieser Stelle etwas detaillierter hervorheben. Unter Umständen helfen diese Punkte auch bei der Argumentation der Methodik, bei der Überzeugung des Kunden oder des Teams.

Story Points forcieren gemeinsames Schätzen

Ein großer Vorteil von Story Points ist die Fokussierung auf die gemeinsame Schätzung und die Übernahme der Verantwortung für diese Schätzung durch das gesamte Team. Jeder Anforderung muss ein konkreter Schätzwert zugewiesen werden.  Damit sind sie sehr wichtig für das gedankliche Commitment zum Projekt.

Idealtage hingegen werden oft fälschlicherweise auf die einzelnen Gewerke verteilt. So schätzt der Entwickler seinen geplanten Aufwand unabhängig vom Designer und vom Konzepter und anschließend werden alle Schätzwerte aufsummiert. Hierdurch findet weniger Gedankenaustausch über die Details der Anforderung statt und jedes Teammitglied trägt lediglich die Verantwortung für seinen Anteil, nicht aber für das große Ganze.

Schätzung in Story Points ist meist schneller

Die Schätzung in Story Points geht wesentlich schneller, da lediglich die Relation zu anderen, bereits geschätzten Anforderungen betrachtet werden muss. Gerade am Anfang, bei der ersten Schätzung aller Elemente des Product Backlogs, sollte die Schätzung möglichst leichtgewichtig und schnell gehalten werden. Andernfalls wird zu viel Zeit auf Funktionen verschwendet, die hinterher eventuell gar nicht umgesetzt werden.

Idealtage hingegen fördern eine präzise Schätzung. Auch wenn theoretisch eine exponentiell steigende Wertemenge, wie bei der Verwendung abstrakter Größen, benutzt werden kann, so stellen Idealtage durch den verbleibenden Zeitbezug eine präzisere und damit aufwändigere Schätzung dar.

Story Points gleichen unterschiedliche Skill-Level aus

Das große Problem von Idealtagen ist, dass sie von Teammitglied zu Teammitglied unterschiedlich sind. Ein erfahrener Entwickler mag eine Anforderung auf drei Idealtage schätzen, während ein nicht so erfahrener Kollege vielleicht für die gleiche Anforderung fünf Tage veranschlagen würde.

Eine direkte Übertragbarkeit der Schätzung auf einen anderen Mitarbeiter ist also nicht gegeben. Leider setzt nicht immer, und in Agenturprojekten sogar recht selten, der Mitarbeiter, der die Schätzung initial erstellt hat, die Anforderung im Projektverlauf auch selber um.

Story Points sind als völlig abstrakte Größen frei von diesem Problem. Eine Anforderung bleibt doppelt so groß wie eine andere Anforderung, unabhängig davon, welcher Entwickler sie letzten Endes umsetzt. Das ein erfahrener Entwickler die Aufgabe schneller bewältigt schlägt sich dann in der Velocity, also der Entwicklungsgeschwindigkeit, nieder. Diese gleicht alle Unterschiede in der Erfahrung und dem Wissen der Mitarbeiter aus. Allein die gemeinsame Teamleistung zählt und gibt die nötige Messgröße für die Planung an.

Schätzungen in Story Points sind nachhaltiger

Ein weiteres Problem von Idealtagen ist die zeitliche Begrenztheit. Bei einem neuen System, vielleicht sogar mit einer neuen Programmiersprache, hat das Team noch wenige Erfahrungen gesammelt und schätzt eine einfache Anforderung vielleicht auf 5 Idealtage ein. Gehen wir davon aus, dass das Team in einer Iteration 5 Idealtage bewältigen kann, wird das Feature also in einer Iteration abgeschlossen. Mit zunehmender Erfahrung würde das gleiche Team die gleiche Anforderung aber vielleicht mit nur einem Idealtag bewerten. Bei gleichbleibender Velocity könnte die gleiche Anforderung also auf einmal fünfmal schneller umgesetzt werden.

Schätzungen in Story Points sind hier nachhaltiger. Die Relation zwischen verschiedenen Anforderungen bleibt gleich, lediglich über die Velocity werden zunehmende Erfahrungen mit Bibliotheken, der Programmiersprache oder benutzten Tools eingerechnet. Ändern sich die Details zu einer Anforderung, müssen bei beiden Methoden die Schätzungen angepasst werden. Jedoch sind nur bei den Idealtagen die steigenden Erfahrungen des Teams zu berücksichtigen.

Story Points sind eine reine Schätzung der Größe

Beide Ansätze trennen die Größe einer Anforderung von der zu erwartenden Umsetzungsdauer. Bei Idealtagen ist die Verbindung zur Zeitkomponente aber wesentlich stärker gegeben. In der Kommunikation ist dies nach wie vor ein Problem, da der Kunde oder auch der Projektleiter weiterhin Annahmen über den Fertigstellungstermin anhand der Schätzung in Idealtagen machen.

Story Points lassen solche Überlegungen gar nicht zu und fördern zudem noch stärker ein intuitives und schnelles Einschätzen.

Idealtage sind zuerst einfacher zu schätzen

Für viele Entwicklungsteams fühlt sich die Einschätzung von Product Backlog Elementen in Idealtagen zunächst einfacher und gewohnter an. Sie sind es gewohnt Schätzungen in Tagen abzugeben und so liegt die Verwendung von Idealtagen nahe.

Am Anfang ist die richtige Nutzung von Story Points auch sicher nicht sehr vertrauenserweckend und man muss sich erst auf diese Methode einlassen. Sehr bald, meist nach wenigen Schätzungen, hat sich das Team aber bereits an den Prozess gewöhnt und ist in der Lage sehr schnell und intuitiv zu schätzen.

Idealtage sind einfacher zu erklären, besonders dem Kunden

Als wichtigsten Vorteil der Idealtage sehe ich das einfache Verständnis dieser Methodik an. Es ist sofort einleuchtend und auch von fachfremden Stakeholdern intuitiv zu begreifen. Der Overhead, der die Diskrepanz zwischen Idealtag und einem Entwicklungstag in der Realität ausmacht ist jedem sofort verständlich.

Story Points sind dagegen sehr schwierig zu erklären und erfordern ein grundlegendes Verständnis der zugrunde liegenden Konzepte wie Velocity oder der Planung mit entkoppelten Werten für Größe und Dauer.

eXtreme Programming in a Nutshell 3/4 – XP-Prinzipien

Hier unser dritter Teil der Serie “eXtreme Programming in a Nutshell”. Die ersten Teile findet ihr hier:

XP-Prinzipien

Aus den vier grundlegenden XP-Werten ergeben sich 15 Prinzipien, die die Grundlage für das XP-Framework, festigen.

Unmittelbares Feedback

Das frühzeitige Einholen von Feedback hat gleich zwei positive Effekte. Zum einen läuft das Team dann unter Umständen nicht zu lange in die falsche Richtung. Zum anderen ist der Lerneffekt größer, wenn das Feedback möglichst unmittelbar nach dem Ereignis eintritt.

Einfachheit anstreben

Statt eine große und flexible Architektur der Software anzustreben, um für zukünftige Entwicklungen und Änderungen gewappnet zu sein, wird eine möglichst einfache Lösung bevorzugt. Diese einfache Lösung ist einfach zu verstehen, einfach zu warten und erlaubt frühzeitiges Feedback. Mit der Lösung ist das Team besser auf zukünftige Weiterentwicklungen vorbereitet als mit einer zu komplexen Basisarchitektur, die Flexibilität für zukünftige Änderungen vorgaukelt, die heute noch gar nicht absehbar sind.

Inkrementelle Veränderung

Je komplexer die Software wird, desto schwerer wird es Fehler und unerwartete Seiteneffekte bei Änderungen nachzuverfolgen. Deshalb wird in der Entwicklung auf möglichst kleine Änderungen gepaart mit direktem Testing und Bugfixing gesetzt. So bleiben die Nebeneffekte überschaubar und können in einen direkten Bezug zu der vorgenommenen Änderung gesetzt werden.

Veränderung wollen

Das Team, das Unternehmen und jeder einzelne Mitarbeiter muss die Veränderung wollen. Nur durch Veränderung kann ein Fortschritt erzielt werden.

Qualitätsarbeit

Für die Entwickler sollte klar mess- und nachvollziehbar sein, ab wann ein Stück Software den Qualitätsanspruch genügt und welche Akzeptanzkriterien damit verbunden sind. Dabei sollte der Nutzer der Software die Messlatte vorgeben, schließlich muss er die Software später tagtäglich nutzen.

Lernen lehren

XP ist ein sehr adaptives Framework. Es geht nicht darum dogmatisch die Techniken und Prinzipien einzusetzen. XP will den Entwickler lehren selber Lernfortschritte zu machen, die Techniken von Grund auf zu verstehen und aus eigenen Fehler und Erfahrungen zu lernen.

Geringe Anfangsinvestition

Da besonders in IT-Projekten das endgültige Resultat und der spätere Nutzen der geplanten Software nicht komplett bekannt ist und nur in geringem Maße antizipiert werden kann, sind XP-Entwickler und Manager dazu angehalten die Anfangsinvestition gering zu halten und sich auf das Wesentliche und die bereits bekannten Anforderungen zu konzentrieren.

Auf Sieg spielen

Auf Sieg spielen bedeutet mit einer positiven Grundeinstellung an das Projekt, an das Ziel heranzugehen. Nur mit dieser Denkweise können Fehler toleriert und aus ihnen gelernt werden. Weiterhin bedeutet es, Projekte, die nicht mehr gewonnen werden können, zu beenden.

Gezielte Experimente

Um Prozesse, Architekturen oder Benutzeroberflächen zu testen werden gezielt Experimente durchgeführt, um die Tauglichkeit einschätzen zu können. Dies können Retrospektiven im Projektverlauf, Prototypen für erste Usability-Tests oder System-Tests sein.

Offene, aufrichtige Kommunikation

Wenn viel und rege kommuniziert wird, ist das noch keine Bestätigung für eine offene und aufrichtige Kommunikation. Eine Kommunikations- und Kritikkultur, die nicht durch die Eitelkeiten und Ängste Einzelner behindert wird, ist ein essentieller Faktor für den erfolgreichen Abschluss des Projektes.

Die Instinkte des Teams nutzen, nicht dagegen arbeiten

Viele Methoden und Prinzipien von XP beruhen auf Instinkten und leuchten jedem Beteiligten direkt ein. Jedoch fallen wir oft in stressigen Situationen in gelernte Muster zurück. Dabei sollte den Instinkten des Teams getraut werden. Spricht sich das Team gemeinsam gegen eine Technik aus, dann ist dies auch sicherlich der falsche Weg und sollte nicht erzwungen werden.

Verantwortung übernehmen

Die Betonung liegt in diesem Fall auf „übernehmen“, das das Team die Verantwortung nicht vom Management zugewiesen bekommen sollte;  weder ihre Rollen im Projekt noch das Projekt als Ganzes. Hat das Team hingegen die Möglichkeit bewusst und freiwillig Verantwortung zu übernehmen, wird es diese mit höchstem Engagement und Motivation wahrnehmen.

An örtliche Gegebenheiten anpassen

XP versteht sich als Framework, als Werkzeugkasten von Techniken und Prinzipien. Über allem steht der Ansatz „learn and adopt“. Jede Anpassung von XP an die Gegebenheit des Unternehmens oder des individuellen Projektes sind völlig in Ordnung, sofern Sie dem Projektziel dienen.

Mit leichtem Gepäck reisen

„A fool with a tool is still a fool.“ Alle Werkzeuge sollten bewusst ausgewählt und eingesetzt werden. Lieber wenige einfache Tools als einen Satz komplexer Tools für jede mögliche Situation.

Ehrliches Messen

Tests und Metriken sind essentiell, um den Projektstatus richtig einschätzen zu können; ohne diese macht das Team einen Blindflug. Umso wichtiger ist es, ehrlich bei der Implementation der Tests und der Aufstellung von Statistiken zu sein.

Priorisierung von Anforderungen 5/5 – MuSCoW Priorisierung

Die verschiedenen Möglichkeiten zur Priorisierung von Anforderungen stellen wir ein einer kleinen Artikelserie dar. Bisher erschienen:

MuSCoW Priorisierung

Für die initiale Befüllung des Product Backlogs oder der einfachen Priorisierung bei kleinen Projekten ist die MuSCoW Priorisierung eine gute und einfach anzuwendende Alternative. Die einzelnen Anforderungen werden in die Kategorien Must have, Should have, Could have und Won’t have eingeteilt.

Must haves sind dabei Basisfunktionalitäten, ohne die das System nicht lauffähig wäre oder ohne die wichtige Eckpfeiler des Konzeptes nicht vorhanden wären. Anforderungen aus der Kategorie Should have sind ebenfalls wichtig und machen den eigentlich Mehrwert des Projektes aus. Sie sollten für ein erfolgreiches Release am Markt enthalten sein. Could have Funktionen sind hingegen nicht unbedingt ausschlaggebend für das Projekt. Je mehr Anforderungen dieser Kategorie enthalten sind, desto besser. Anforderungen aus der letzten Kategorie sind als Won’t have this time zu verstehen. Sie passen mit ziemlicher Sicherheit nicht ins Projektbudget und sind eher als Ideen für weitere Entwicklungen oder kleine, nicht maßgebliche Detailänderungen zu sehen.

Warum ist es so schwer agil zu werden und wieso lohnt es sich trotzdem?

Schon in der klassischen Softwareentwicklung scheiterten viele Unternehmen an der Einführung von Scrum. Die, die es erfolgreich schafften, gingen einen langen Leidensweg. Dabei bestand das Problem weniger im falschen Einsatz von Tools oder Prozessen, sondern viel mehr in mangelnder Kommunikation. Agil zu werden bedeutet zu kommunizieren. Hier fehlten oft Praxiserfahrung und eigene Bespiel-Projekte, um Kunden und noch viel wichtiger, das eigene Unternehmen zu überzeugen.

Die ersten Widerstände kommen noch in den eigenen Reihen auf. Die Geschäftsführung hat Angst vor zu wenig Planungssicherheit, zu hohe Transparenz dem Kunden gegenüber oder mit dieser innovativen Projektführung Kunden zu enttäuschen oder noch schlimmer, zu verlieren.

Das ist auch erst einmal völlig verständlich, zeigen Erfahrungen aus der Prozess-Optimierung doch, dass die Einführung und Anpassung neuer Methoden und Prozesse meist mit einem hohen finanziellen Aufwand verbunden ist und die Produktivität und Qualität der Arbeit im ersten Moment sinkt.

Neben dem Management ist auch das Team skeptisch. Was wird von Ihnen genau erwartet? Sind Sie den neuen Anforderungen gewachsen? Viele verbinden mit Agilität etwas Frisches und Modernes und haben Angst hier im Vergleich zu jüngeren Kollegen auf der Strecke zu bleiben.

Ein gern genutzter Satz in der IT ist „Never change a running system“. Läuft ein System einmal unrund, oder anders gesprochen, ist die Umsatz-Entwicklung der Agentur rückläufig, wird jedoch selten der Prozess selbst als erster Ansatzpunkt zur Optimierung herangezogen, sondern meist die Produktivität des Einzelnen. Das ist dem Team durchaus bewusst, und so verhärtet sich dieses bei dem scheinbaren Befreiungsschlag den Scrum in letzter Minute leisten soll.

Da man hier, wie oft angenommen wird, nur sehr schwer ein Projekt isoliert betrachten kann, findet man selbst im Kreis der Projektleiter häufig Widerstände. Gerade wenn hier Begriffe wie Scrum Master oder Product Owner fallen und davon gesprochen wird, keinen klassischen Projektleiter mehr zu benötigen.

Kurz gesagt, im eigenen Unternehmen sehen viele Mitarbeiter und Manager ihre Position in Gefahr.

Ist dann der erste Schritt in Richtung Agilität auf der eigenen Seite vollzogen steht man vor dem nächsten Problem, dem Kunden. Agilität klingt hier oft wie eine leere Marketing-Worthülse und verspricht das Blaue vom Himmel. Verlangt dafür aber auch Umstellungen im Prozess auf der Kundenseite, andere Vertragsformen und viel Vertrauen. Hat man bei kleinen und mittelständischen Kunden noch den Projektleiter als zentralen Ansprechpartner auf Kundenseite und kann auch Vertrags- und Angebotsverhandlungen mit diesem durchgehen, hat man bei größeren Konzernen noch die Einkaufs-Abteilung, die mit den Prinzipien der agilen Software-Entwicklung wenig vertraut ist und versuchen einen Anbieter nach objektiven Kriterien auszuwählen.

Vor dem Projektbeginn steht also meist eine Phase der Kundenaufklärung und –Beratung. Eine Phase, die beispielsweise in einem Pitch oder anderen Konkurrenz-Situationen gar nicht zum Einsatz kommt.

Versucht man Scrum idealtypisch einzusetzen, ohne jedoch den Kunden zu involvieren (oft gerne als internes Scrum bezeichnet) oder eine passende Vertragsgrundlage zu haben, ist ein Scheitern vorprogrammiert.

Fallen all diese Widerstände und Probleme schon in der klassischen Softwareentwicklung an, kommt in Agenturen noch das bereits beschriebene Problem hinzu, keine bis wenig Informationen zum Transfer der Methoden auf die spezifischen Projekte dieser Branche  zu finden.

Wieso lohnt es sich dennoch?

Ist es nicht bei all diesen Problemen und Widerständen sinnvoller, das Konzept der Agilität als nette Gedankenspielerei ad acta zu legen und sich auf eine reine Optimierung des Wasserfall-Prozesses zu konzentrieren?

Die große Chance bei Scrum und Co. liegt jedoch viel weniger in der Steigerung der Produktivität des Einzelnen und einer direkten Umsatzsteigerung. Der große Nutzen hinter all den Methoden, Tools und Prozessen liegt vor allem in einem Wandel der Mentalität.

In der Lean-Production wird dieser Zustand mit Kaizen bezeichnet. Ein Unternehmen, das dieses Prinzip und diese Mentalität lebt, wird dadurch mit loyalen, mitdenkenden und selbständigen Mitarbeitern belohnt. Mitarbeiter, die nicht nur ausgeglichener, gesünder und produktiver sind, sondern Verantwortung für das Projekt und den Prozess übernehmen. Bestrebt darin diesen Prozess kontinuierlich zu verbessern.

Das ist die treibende Kraft hinter Agilität und Methoden wie Scrum. Die Steigerung der Produkt-Qualität, der Produktivität und der Kundenzufriedenheit sind lediglich die logische Konsequenz daraus.

Sollten Sie jetzt die Befürchtung haben, hier auch nur das typische Marketing-Versprechen der agilen Bewegung zu finden, kann ich Sie beruhigen.

Die vorgestellten Methoden, Schritte und Praxisbeispiele bilden genau die Brücke, um die Widerstände zu überwinden und auch in Ihren Projekten oder Ihrer Agentur einen Kaizen-Zustand zu erreichen.

 

 

eXtreme Programming in a Nutshell 2/4 XP-Werte

Hier unser zweiter Teil der Serie “eXtreme Programming in a Nutshell”. Den ersten Teil findet ihr hier:

eXtreme Programming in a Nutshell – Einführung

XP-Werte

Ähnlich dem agilen Manifest fußt auch XP auf einem Satz von übergeordneten Werten. Diese Werte umfassen Einfachheit, Feedback, Kommunikation und Mut. Auch hier sind deutliche Parallelen zum agilen Manifest sichtbar. Und ebenso wie Scrum auf diesen Werten basiert ist auch der Einsatz von XP daran gebunden. Ein Unternehmen – und besonders das Projekt-Team – muss zunächst diese Werte verinnerlicht und etabliert haben um anschließend einen Nutzen aus den Prinzipien und Techniken ziehen zu können.

Einfachheit

XP stellt den Anspruch der Einfachheit nicht nur an sich selbst als Framework, sondern auch an die anzustrebende Lösung für das Projektergebnis. Pragmatismus in Form einer möglichst einfachen Lösung steht hier im Vordergrund. Oft erreicht eine einfache, kleine Lösung die Ziele des Kunden genauso gut, und ist dabei noch kostengünstiger und schneller zu realisieren und dem Endanwender meistens schneller zu erklären, als eine große, komplexe Architektur mit einer Vielzahl an Funktionen.

Feedback

Schnelles und regelmäßiges Feedback zur Qualität durch Tests auf Entwicklungsebene oder das frühzeitige Einbinden von Testgruppen in den Prozess ist die effektivste Form der Qualitätssicherung. Je mehr und je schneller Feedback vorliegt, desto schneller kann dies auch wieder in den Entwicklungsprozess einfließen.

Kommunikation

Effizienz und Einfachheit sind auch die treibende Kraft für die Kommunikation im Projekt. Das direkte Gespräch wird hier der digitalen oder schriftlichen Kommunikation vorgezogen und auch als wichtiger eingestuft als eine umfassende Dokumentation. Eine effiziente Kommunikationskultur ist sicher die größte Produktivitätsquelle in einem Projekt.

Mut

Alle drei anderen genannten Werte und der Einsatz einer neuen Methodik an sich erfordern eine Menge Mut; Mut sich für eine einfache Lösung zu entscheiden und bewusst Funktionen entfallen zu lassen; Mut ehrliches Feedback – egal ob negativ oder positiv – geben, aber auch vertragen und anerkennen zu können; Mut zu einer offenen und transparenten Kommunikation; Und nicht zuletzt Mut sich auf etwas Neues einzulassen und mit gewohnten Techniken und Einstellungen zu brechen.

 

Priorisierung von Anforderungen 4/5 – Nach Risiken und Abhängigkeiten

Die verschiedenen Möglichkeiten zur Priorisierung von Anforderungen stellen wir ein einer kleinen Artikelserie dar. Bisher erschienen:

Nach Risiken

Auch das mit einer Anforderung verbundene Risiko muss für die Priorisierung bedacht werden. Eine fremde, komplexe Bibliothek oder eine Vielzahl an möglichen Ziel-Architekturen stellen zum Beispiel Risiken für das Projekt dar. Dabei können Anforderungen entweder selber risikoreich sein, oder ein Risiko bewusst adressieren mit dem Ziel dieses abzuwenden, oder wenigstens genau abschätzen zu können.

Auch sollte das Wort Risiko nicht ausschließlich negativ betrachtet werden. Damit verbunden sind auch Chancen für das Projekt. Einige Anforderungen behandeln mögliche Chancen und helfen frühzeitig die richtigen Weichen zu stellen, um diese auch zu nutzen oder wenigstens zu begünstigen.

Nach Abhängigkeiten

Auch wenn die Unabhängigkeit ein Kriterium für gute Anforderungen ist, lassen sich nie alle Abhängigkeiten vermeiden oder auflösen. Sind technische Vorkehrungen oder anderen Anforderungen im Vorfeld zu lösen sollten diese in der Priorisierung eingeplant werden.

Wieso scheitern klassische und agile Methoden in Webprojekten?

Der Wasserfall-Prozess, um den Archetyp der klassischen Methoden als Beispiel zu nehmen, bietet deutlich zu wenig Flexibilität, um auf die genannten Probleme und Herausforderungen zu reagieren.

Durch die Abgrenzung der verschiedenen Disziplinen und Projekt-Phasen bekommt die Projekt-Initialisierung eine sehr hohe Gewichtung. Fehler die hier gemacht werden sind später oft irreparabel oder mit extrem hohen Kosten verbunden. Dadurch wird eine sehr detaillierte Spezifikation, üblicherweise in Form eines Pflichten- und Lastenheftes, unabdingbar.

Da dieser Bereich für die Agentur üblicherweise noch in die Phase der Projekt-Akquisition fällt, und damit unbezahlt ist, können nie wirklich alle Details und Parameter berücksichtigt werden. Diese Detail-Konzeption einzupreisen, oder die Unwägbarkeiten durch Puffer in der Kalkulation zu berücksichtigen, verdoppelt nicht selten den Projektpreis, sodass die Agentur aus finanziellen Gründen für den Kunden ausscheidet. Also bleibt nur die grobe Kalkulation über den Daumen mit einem Kompromiss-Budget. Bei den hohen Unklarheiten zum Projektziel und den Erwartungshaltungen gleicht das einem Glücksspiel.

Nicht selten sind die ursprünglich geplanten Features zu Projektende nicht mehr relevant oder schießen an dem wirklich benötigten Mehrwert vorbei. Der oft gezogene Vorteil der klassischen Methoden, die Risikominimierung durch Planungs- und Ergebnisspezifikation zu Projektbeginn, erhöht das Risiko in diesem Projekt-Umfeld also stattdessen erheblich.

Durch die klare Abgrenzung der Fachbereiche und Projekt-Phasen gehen weiterhin alle Synergie-Effekte verloren. Als Beispiel kann hier eine simple Such-Funktionalität dienen:

Der Konzepter sieht ein Suchfeld mit einem Button „Suchen“ vor. Der Grafiker hätte vielleicht eine andere Form vorgezogen, setzt aber die Spezifikation des Konzeptes exakt um. Der Programmierer könnte sich die Suche deutlich besser mit Auto-Suggest Funktionalität vorstellen, setzt aber die Suche exakt gemäß der Grafik um. Das qualitativ bessere Ergebnis wäre sicher aus einer gemeinsamen Entwicklung der Anforderung unter Einbeziehung aller Disziplinen entstanden.

Wieso scheitern agile Methoden hier?

Scrum und andere Ansätze vermeiden die Probleme der klassischen Methoden sehr gut. Durch eine starke Einbindung des Kunden in den kompletten Prozess und die Konzeption wird wesentlich weniger Planung und Spezifikation zu Beginn benötigt und eine häufige Nachjustierung erlaubt Reaktionen auf den Ziel-Markt und eine immer konkreter werdende  Vorstellung des Kunden.

Weiterhin geht Scrum von einem interdisziplinären Team aus, das im kompletten Projektverlauf gemeinsam Entscheidungen trifft und somit das Gemeinschaftswerk und die Synergie-Effekt stark fördert.

Und hier findet sich auch der größte Knackpunkt im Einsatz bei Agenturen. Während in der klassischen Software-Entwicklung interdisziplinär vorwiegend ein Zusammenspiel von Programmierung, Software-Architektur und Testing bedeutete, sind in Multimedia-Projekten Gewerke wie Konzeption, Brand Management, Grafik, Motion-Design, Frontend- und Backend-Entwicklung vertreten.

Diese verschiedenen Kompetenzen zu parallelisieren stellt die größte Herausforderung dar. Erschwert wird dies durch die Ressourcenknappheit, Bindung eines Mitarbeiters in mehrere Projekte und das Bestreben, Leerlaufzeiten zu minimieren.

Tatsächlich ist die komplette Blockung eines Teams für ein einziges Projekt über den gesamten Projektverlauf in allen vertretenen Fachbereichen eine unwirtschaftliche Entscheidung. Hier muss ein gesunder, pragmatischer Mittelweg gefunden werden.

Das zweite Problem ist die Skalierung von Scrum. Dieses Thema behandeln durchaus viele Fachbücher, allerdings nur in Bezug auf große Projekte, wo von Scrum of Scrums und ähnlichen Techniken die Rede ist. Eine Skalierung auf kleine Projekte, meist nur ein oder zwei Iterationen lang, findet man nicht.

Priorisierung von Anforderungen 3/5 – Nach Kosten

Die verschiedenen Möglichkeiten zur Priorisierung von Anforderungen stellen wir ein einer kleinen Artikelserie dar. Bisher erschienen:

Nach Kosten

Jede Anforderung hat aber auch ihren Preis. So verursacht sie Kosten in der Entwicklung, bindet Ressourcen die für die Umsetzung anderer Features benutzt werden könnte und bringt eventuell weitere Kosten für Hardware, externe Mitarbeiter, Lizenzgebühren oder einen erhöhten Aufwand in der Wartung der Software und im Support der Anwender mit sich.

Ist die Geschwindigkeit des Teams, die sogenannte Velocity, einmal bekannt, können über den Tagessatz schnell die Kosten pro Story Point und damit die Kosten für jede geschätzte Anforderung berechnet werden.

Dabei ist immer eine Gegenüberstellung mit dem finanziellen Gewinn oder der erwarteten Kostenersparnis nötig. Ein Feature, das doppelt so teuer ist wie ein anderes, aber auch den dreifachen Gewinn einfährt ist auf jeden Fall höher zu priorisieren.

Ein wenig sollte man dabei die Dynamik und die Entwicklung der Software im Auge behalten. Trotz allen Refactorings und einer sauberen Codebasis wird die Software von Sprint zu Sprint komplexer und einige Anforderungen, die tief in das System integriert werden müssen, steigen in den Entwicklungskosten. Gerade bei globalen Anforderungen, wie ein diffiziles Rechtemanagement und die Auslegung für verschiedene Benutzer und Benutzergruppen, sollte diese Problematik frühzeitig bedacht werden.

eXtreme Programming in a Nutshell 1/4

Wir fokussieren und natürlich nicht nur auf Scrum. Da dies aber die populärste der Methoden ist, stelle ich heute in in Zukunft die anderen Methoden im “Schnelldurchlauf” vor. Heute fangen wir mit eXtreme Programming an.

Die Artikelserie ist in 4 Teile gegliedert:

  1. Einführung
  2. Die XP-Werte
  3. Die XP-Prinzipien
  4. Die XP-Techniken

Einführung

XP verfolgt wie alle schlanken Methoden einen möglichst puristischen Ansatz ohne starre Prozess-Strukturen oder Formalitäten.

Ursprüngliche wurde XP im Jahre 2000 durch Kent Beck’s erstes Buch [Verweis] an das Licht der Öffentlichkeit gezogen und einer breiten Masse vorgestellt. Seitdem hat XP sehr viel Beachtung in der Software-Entwicklung erlangt, auch wenn es nicht mit dem Erfolg von Scrum mithalten kann.

XP basiert auf einem Satz von Werten, Prinzipien und Techniken die als Grundlage für das erfolgreiche Management und die Entwicklung von IT-Projekten dienen sollen. Auch XP versteht sich dabei als loses Regelwerk, als Framework, das an die individuellen Gegebenheiten angepasst werden sollte.

Navigate