Quelle: pixabay
Disclaimer: Vor oder nach der Lektüre des Artikels empfiehlt sich ein Blick auf das Veröffentlichungsdatum. 😉
Wir begegnen häufig Unternehmen mit einer Aneinanderreihung schmerzhafter Probleme: Die Anforderungen sind unklar, die Qualität lässt zu wünschen übrig. Eine Planbarkeit oder gar Liefertreue ist nicht möglich und die Liefergeschwindigkeit ist unberechenbar und sehr langsam.
Den meisten Unternehmen scheint von vornherein klar, dass ein Umschwung zum agilen Arbeiten das Allheilmittel ist, das all ihre Probleme lösen wird. Wenn wir aber einen Schritt zurück nehmen und das System dieser Unternehmen einzeln betrachten, finden wir auch sehr gut durchdachte und größtenteils funktionierende Prozesse, die man nicht zwangsweise und zum Selbstzweck agilisieren muss. Die Unternehmen haben sich in ihren Prozessen eingespielt und diese sind über die Jahre gereift. Eine überstürzte Transition zur Agilität könnte dieses funktionierende Uhrwerk nur aus dem Takt bringen. Wir sehen das immer wieder. Da wird dogmatisch erstmal alles auseinandergenommen und völlig neu zusammengesetzt. Die Uhr funktioniert zwar nicht mehr, aber dafür haben wir noch zwei Schrauben in der Hand, die beim Zusammenschrauben übrig geblieben sind.
Üblicherweise machen wir uns als Coaches zunächst ein Bild der Situation, was in diesen Unternehmen glücklicherweise schon oft vorbereitet für uns auf dem Tisch liegt. Ein Projektmanager kann uns anhand von Diagrammen und Gantt-Charts ausführlich erläutern, wie das System funktioniert. So können wir mit einem eigenen Gantt-Chart unseren Plan vorab und vollständig aufzeigen.
Ziele müssen wir nicht setzen, wir kennen alle Pain Points. Wir zählen die einzelnen Pain Points auf und überlegen uns losgelöste, von einander entkoppelte, lokale Lösungen. Wichtig ist zu wissen, wer jeweils von einem Problem betroffen ist und wie ihm oder ihr geholfen werden kann.
Um nicht im üblichen abstrakten und abgehobenen Coach-Sprech zu bleiben, wollen wir konkrete Beispiele und entsprechende Lösungsansätze aufzeigen:
Pain Point: Unklarheiten in der Anforderungsaufnahme
Die Anforderungsaufnahme mit dem Kunden führt oft zu unklaren Anforderungen. Auf der Kundenseite ist das Problem, dass Kunden nur vage wissen, was sie wollen. Sie haben kein ausreichendes Verständnis für das Produkt und wie ihre Anforderungen technisch umgesetzt werden müssen. Auf der Seite der Kundenbetreuer und Entwickler besteht das Problem, dass die Anforderungen nicht einheitlich und präzise genug formuliert werden.
Damit die Kundenwünsche nicht schon durch Kundenbetreuer interpretiert und wie beim Stille-Post-Verfahren verfälscht an Entwickler weitergegeben werden, haben wir einen zentralen digitalen Erfassungs-Webservice zur Einreichung der Kundenwünsche eingerichtet. Hier können Kunden jederzeit ihre vagen Ideen und Wünsche in ein Webformular eintragen. Als positiven Nebeneffekt haben wir die Wünsche automatisch mit einem Zeitstempel versehen, sodass jetzt alles in korrekter Reihenfolge abgearbeitet werden kann.
Konfigurierbarkeit und Variantenmanagement bieten eine Alternative. Der Kunde kann selbst seine eigenen Änderungen direkt einbauen, ohne ständig teure Entwicklerressourcen abzugreifen. Wenn ihm das dann um die Ohren fliegt, ist es sein Problem – er ist für seine Änderungen selbst verantwortlich.
Wichtig ist, dass Kundenwünsche von Anforderungen getrennt werden. Die Wünsche werden von Fachexperten in fachliche Anforderungen, auch Fachwünsche genannt, umformuliert. Damit die Entwickler nicht ständig neue und individuell formulierte Fachwünsche verstehen müssen, haben wir zusätzlich ein Fachwunsch-Template konzipiert. Hierdurch ist sichergestellt, dass jeder Fachwunsch einem festen und planbaren Schema folgt. Hier haben wir Konzepte aus User-Story und Requirements Engineering kombiniert. So werden aus ungenauen Überlieferungen präzises Ingenieurhandwerk.
Die Fachwünsche werden von Teamleitern konsequent in technische Aspekte zerlegt und den jeweiligen Komponenten zugeordnet. So entstehen technische Anforderungen, die fachlich zusammengehalten werden. Eine Umstellung in Feature-Teams wäre demnach schlichtweg ein grober Fehler. Die Komponenten-Teams, als eingespielte Einheiten, sind spezialisiert auf ihren Bereich und können so äußerst effizient die technischen Anforderungen abarbeiten.
Pain Point: schlechte Planbarkeit
Häufig gibt es Probleme in der Planbarkeit der Umsetzung. Es gibt hunderte von Tickets im Backlog, die nicht mehr zu überblicken sind und tagtäglich kommen neue hinzu, meist in Form von Bugs. Dass es dann schwer fällt, den Überblick zu behalten oder gar zu planen, liegt auf der Hand. Dabei ist es relativ einfach: Priorität haben Anforderungen des Kunden, der gerade eskaliert. Sollte es mal ungewöhnlicherweise keinen Kunden geben, der sich lauthals beschwert, kann man einfach auf den Eingangsstempel der Anforderung verweisen. First come first serve.
Für Umpriorisierungen und Bugs reserviert man Kapazität und Ressourcen, die bei Bedarf, der auf jeden Fall eintreten wird, einspringen können. Mit genügend Mate-Vorrat lassen sich Entwickler auch gerne überreden, die eine oder andere Überstunde zu leisten. Welcher Entwickler prahlt nicht gerne beim Afterwork mit Kollegen über verrückte Pizza-Nächte.
Häufig sind Schätzungen nicht genau genug und abhängig von der Person, die sie abgibt. Zur Lösung bedienen wir uns der statistischen Standardabweichung, indem wir das Delta von Schätzung zu tatsächlich benötigter Zeit errechnen und den Durchschnittswert bilden. Diesen können wir von nun an auf alle zukünftigen Schätzungen addieren und verbessern so die Schätzungen. Wenn dann auch nur eine dedizierte Person für Schätzungen zuständig ist, sind die Schwankungen auch nicht mehr so groß. Durch das bereits bekannte Schätzen in Personentagen, statt Story Points oder gar keinen Schätzungen, erhalten wir konkrete Zusagen der Entwickler und eine genauere Vorhersage von Lieferterminen wird möglich.
Außerdem peilen wir eine hundertprozentige Auslastung der Entwickler an. Daher werden Tickets so eingeplant, dass jeder Entwickler beschäftigt ist. Dazu weisen wir Tickets auch direkt einzelnen Entwicklern zu. Kostbare Entwicklerzeit wird somit nicht länger mit sogenannter „Slack Time“ verschwendet.
Pain Point: mangelnde Qualität
Um eine ausreichend gute Qualität zu erreichen, müssen wir für eine hundertprozentige Testabdeckung sorgen und erzwingen das auch von Anfang an durch eine automatische Prüfung.
Ab jetzt werden die Zusammenhänge der Anforderungen in Form eines Spinnennetzes in den Anforderungen selbst klar aufgezeigt. Die Tests werden durch geeignete Spezialisten, die Tester, formuliert und mit Anforderungen von technischen Teamleitern verknüpft. Es werden nur noch vollständige Integrationstests geschrieben, damit mit jedem Test auch ein echter Durchstich durch alle Systembestandteile erreicht wird. Unit-Tests werden hierdurch obsolet, sodass Entwickler ihre Zeit sinnvoller nutzen können.
Wenn vor der Auslieferung ein Projekt-Release gebaut wird, muss am Ende genügend Zeit für die Durchführung von vollständigen Regressionstests eingeräumt werden. Dazu empfehlen wir einen Code Freeze von einigen Wochen, damit die Tester Zeit haben, das Release auf Herz und Nieren zu prüfen. Außerdem werden Releases nur noch am Wochenende geliefert. Damit fällt etwaiges Fehlverhalten auch nicht so auf. Nach einem Release wird eine gewisse Zeitspanne (wir empfehlen eine bis zwei Wochen) für eine Nachlaufphase (NLP) reserviert, um Bugs zu fixen.
Im Abschnitt „Anforderungsaufnahme“ hatten wir beschrieben, dass variantenreiche und stark konfigurierbare Systeme den Vorteil bieten, dass wir damit die Verantwortung an der Kunden abtreten können. Für die hundertprozentige Testabdeckung benötigen wir dann eine vollständige Beschreibung der Software, da das System von keinem mehr beherrscht wird. Deshalb benötigt das Unternehmen ausreichend Zeit zur Umsetzung aller Tests und zum Nachziehen der Dokumentation. Wie wir uns die benötigte Zeit beim Kunden erkaufen, sehen wir im folgenden Abschnitt „Liefertermine“.
Pain Point: Liefertermine
Kunden wünschen sich Liefertermine, die eingehalten werden! Wenn wir diesen Punkt genauer betrachten, fällt auf, dass damit nicht noch mehr kleine Releases gemeint sind, die von den Agilisten immer propagiert werden. Kunden wollen nicht kleine belanglose Funktionalitätspäckchen, sondern große umfangreiche Pakete, die ihre benötigten Funktionalitäten vollständig liefern und Probleme nachhaltig lösen. Kein Kunde wünscht sich, kleckerweise beliefert zu werden, wobei jedes Päckchen wie ein Überraschungsei daherkommt. Durch langfristige Planung großer Releases höchstens einmal pro Jahr, besser alle zwei Jahre, können Kunden Einarbeitungszeiten bündeln und einplanen. Große Releases unterliegen auch deutlich höheren Qualitätsstandards. Die Entwicklung hat lange Zeit, alle Funktionalitäten vollständig und fehlerfrei zu liefern und die notwendigen Quality Gates einzuhalten. Dieser Prozess sollte unbedingt ISO-zertifiziert sein, damit er gut dokumentiert und jederzeit überprüfbar ist.
Fazit
Allzu oft wollen Unternehmen eine aufwendige und umfangreiche agile Transition durchführen, weil diese hip, modern und prestigeträchtig sind, statt mit vorhandenen Kräften und klassischem Craftsmanship ihre Probleme in den Griff zu bekommen. Dabei liegen viele Lösungen auf der Hand. Transitionen sind teuer und häufig das Geld nicht wert. Wir konnten aufzeigen, wie man mit kleinen Verbesserungen die Stimmung im Unternehmen wieder aufheitern kann. Zwar bekommt der Kunde dadurch nichts mehr geliefert, aber das hat er vorher ja auch nicht. Wir möchten das Wasserfallmodell wieder ins richtige Licht rücken. Es wird allzu oft verteufelt und als überholt oder zu starr bezeichnet für die ach so volatile technische Welt.
Auch wenn es eine unbequeme Meinung ist, sagen wir:
Finger weg von diesen agilen Transitionen. Let it flow – Wasserfall, was denn sonst!
War dieser Beitrag hilfreich?
Weitere Beiträge
von
29.3.2019 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.