Im letzten Artikel unserer Blogserie beschäftigten wir uns mit den alltäglichen „Impediments“ eines  agilen Entwicklerteams. Nachdem das Product Backlog und das Sprint Backlog kurzfristig Opfer einer Reinigungsfachkraft geworden sind, wurde der Wunsch nach einem Werkzeug unter dem Team laut, um die Ergebnisse nachhaltig zu digitalisieren.

„Der beste Prozess bringt uns wenig, wenn er sich nicht digitalisieren lässt“. „So etwas wie das letzte Mal darf uns auf keinen Fall wieder passieren“, brummte Manfred der Entwickler. „Da gebe ich dir völlig Recht!“, sagte Bernd der Product Owner. „Lasst uns doch einfach die Office Standard Tools verwenden“. „Die haben wir auch schon auf unseren Rechnern“, meinte Susi die Testerin. „Stimmt, wir haben wunderbare Textverarbeitungs- und Tabellenkalkulationsprogramme, da sollte doch für jeden etwas dabei sein“, meinte Steve, der CEO der Firma. „Ich fürchte, das reicht uns aber nicht“, murmelte Manfred. „Mir fehlt da einfach der Mehrbenutzerzugriff und eine Historienfunktion“. „Schließlich möchte ich sehen, wer etwas geändert hat“. „Wie sonst sollen wir denn die anstehenden Änderungen erfassen und verwalten?“.  „Außerdem benötigen wir die Vergabe einer eindeutigen ID für unsere Anforderungen“. „Damit meine ich nicht nur Modellelemente sondern auch unsere natürlich-sprachigen Anforderungen“, betonte Manfred weiter. „Ein neues Tool?“, fragte Jens der Administrator laut aus der letzten Reihe. „Bitte bedenkt unbedingt, dass neben den Anschaffungskosten bestimmt auch Kosten für die Wartbarkeit anfallen. Darüber hinaus benötigen wir noch Schnittstellen zu unserer bestehenden Toollandschaft. Regelmäßige Updates oder Hotfixes müssen wir definitiv auch berücksichtigen. Aktuell ist unsere IT-Struktur sehr komplex, da müssen wir unbedingt eine Evaluierung einplanen, bevor wir ein Werkzeug einführen!“, sagte Jens. „Ok, Ok“, stimmte Steve, der CEO der Firma, zu. „Ohne passendes Werkzeug werden wir langfristig nicht auskommen. Wir benötigen kurz eine Zusammenstellung der wichtigsten Kriterien, die wir berücksichtigen müssen.“, betonte Steve.

Kurze Zeit später fasste das Team folgende Punkte zusammen, die zweifelsohne jedes Unternehmen bei einer Tooleinführung berücksichtigen sollte:

  • Betriebswirtschaftliche Sicht (Folgekosten)
  • Projektsicht (Unterstützende Projektfunktion)
  • Benutzersicht (Benutzerverwaltung)
  • Produktsicht (Reports)
  • Prozesssicht (Methodische Unterstützung)
  • Anbietersicht (Marktposition des Herstellers)
  • Technische Sicht (Integrationsfähigkeit)

Nachdem das Team die unterschiedlichen Sichten eingenommen hatte, wurde recht schnell klar, dass eine Werkzeugeinführung nicht über Nacht erfolgen konnte.

„Wir benötigen unbedingt ein strukturiertes Vorgehen“, sagte Manfred. „Da stimme ich dir zu“, erwiderte Bernd.

Innerhalb kürzester Zeit legte sich das Team auf folgende Punkte fest, um ein strukturiertes Vorgehen zu ermöglichen:

  • Benötigte Ressourcen planen
  • Pilotprojekt (Um Risiken zu minimieren)
  • Evaluierung
  • Kostenanalyse
  • Benutzer schulen

„Puh, das hätten wir jetzt“, meinte Steve, „ich werde mir in den nächsten Tagen eine Übersicht aller Hersteller erarbeiten und mir die Funktionen der einzelnen Werkzeuge im Detail anschauen. Bis dahin arbeiten wir einfach an unseren Metaplanwänden“.

Fallen Ihnen ähnliche Geschichten zum Thema „Werkzeuge“ ein? Wir sind gespannt.

Series Navigation<< „Oh, die Zettelchen sind schon entsorgt!“ – Der Albtraum eines jeden Scrum Teams.