Das Enabling Team enabled auch uns selber

Das Enabling Team enabled auch uns selber

Unser Enabling Team ist ein interdisziplinäres Team, das alle notwendigen Kompetenzen und Skills hat, um in kurzen Iterationen Prototypen zu entwickeln, die mit den Anwendern und möglichem Zielpublikum validiert sind und damit ein konkretes Bedürfnis abdecken. Dieses Team bieten wir als Angebot unseren Kunden an, verwenden dies aber auch selber intern. Und auf die interne Nutzung möchten wir in diesem Beitrag kurz eingehen.

Welches Problem wollten wir lösen?

In unseren Offerten legen wir jeweils die CV’s (Lebensläufe) der Mitarbeitenden bei, die wir für dieses Mandat einplanen würden. Die CV’s werden häufig angepasst, weil unsere Mitarbeitenden sich regelmässig weiterbilden und auch die Erfahrung regelmässig erweitert wird. Die bisherige Lösung mit Word hatte ein schwierig anzupassendes Layout und je nachdem ob es mit Mac oder Windows geöffnet wurde, sah es anders aus. Wir hatten damit zwei Probleme. Einerseits war der Aufwand sehr hoch, um die CV’s immer aktuell zu halten. Und andererseits war es schwierig, das PDF immer gleich und gemäss unseren Erwartungen an die Darstellung zu erstellen. Um diese zwei Probleme zu beheben, haben wir beschlossen, mit dem Enabling Team einen Prototypen zu erstellen.

Wie sind wir dies angegangen?

Die Zusammenstellung des Teams bestand aus einem Product Owner, einer UX- und UI-Designerin und Entwicklern. Für die Validierung nahmen wir unser Backoffice dazu, die hauptsächlichen Anwender der zukünftigen Applikation. Der Start erfolgte durch ein kleines Kick-Off und mit einem überschaubaren initialen Backlog. Schon nach kurzer Zeit konnten erste Funktionen über den webbasierten Prototypen getestet werden. Schritt für Schritt resp. Sprint für Sprint nahm der Prototyp konkretere Formen an. Die Umsetzung haben wir nach Scrum in Sprints gemacht. Die Taktung mit den Sprints half uns, dass wir auch hinsichtlich Erwartungen und Resultaten in diesem Takt planen und denken konnten. Nach einigen Sprints hatten wir dann unser MVP erreicht und wir konnten von der Word-basierten aktuellen Lösung auf die neue webbasierte Lösung umstellen. Schrittweise wurde der MVP dann weiterentwickelt und heute ist die Applikation in einer guten Reife vorhanden und unser Aufwand für die Administration der CV’s ist dadurch massiv gesunken. Der Backlog ist immer noch recht voll, an Ideen für die Weiterentwicklung mangelt es uns nicht. Die neueste Funktion ist eine Skill-Matrix, die uns erlaubt für ganz avega die Übersicht zu haben, welche Skills in welcher Seniorität und welcher Verteilung in der Firma vorhanden sind. Das hilft z.B. auch, gezielte Weiterbildungen zu planen oder Profile für das Recruiting festzulegen. Damit wir euch auch visuell etwas mitgeben können, findet ihr hier noch einige Screenshots.

Die Einstiegsseite:

Themenschwerpunkte:

Das Resultat:

Was haben wir gelernt?

Der spannende Teil dabei war für uns auch, die Arbeit mit dem Enabling Team auch aus einer Art ‘Kunden’-Sicht zu sehen. Wir konnten nicht nur dazu lernen, wie das Enabling Team arbeiten kann und soll, sondern auch was es für die Auftraggeber von einem solchen Vorhaben bedeutet. Einige Erkenntnisse welche wir euch gerne mitgeben möchten:

1. Klare Struktur: auch wenn wir dies als Coaches und Experten in den agilen Themen bei unseren Kunden immer einbringen und erzählen, wurde uns schnell klar, dass wir auch für ein internes, kleines Vorhaben eine klare Struktur und einen klaren Ablauf brauchen mit klaren, festgesetzten Rollen und Zuständigkeiten. Bei den ersten Schritten in der Umsetzung war dies zu wenig klar und die Entwicklung des Prototypen lief zu wenig zielorientiert. Mit der Umstellung hat dies schlagartig geändert.

2. Scope eines MVP’s: die Frage, was das Minimum vom Prototypen ist, um eingesetzt werden zu können wird sehr individuell beantwortet. Es braucht einen guten Product Owner, der eine klare Vorstellung hat, was das MVP ist und dieses auch entsprechend kommuniziert und stark vertritt. Damit ist auch das Erwartungsmanagement verbunden. Es wird immer mehr erwartet, als geliefert werden kann. Daher ist ein proaktives, vorausschauendes Erwartungsmanagement durch den PO sehr zentral und ist ein grosser Beitrag zur Akzeptanz des Prototyps.

3. Der Appetit kommt beim Essen: sobald der Prototyp eingesetzt wird, kommt nicht nur mehr Feedback, sondern auch mehr Ideen und Anforderungen. Deckt ein Prototyp ein wirkliches Bedürfnis ab, ist das Interesse sehr hoch. Das hat sehr schnell zu einem sehr gut gefüllten Backlog geführt. Damit kam sehr schnell auch die Notwendigkeit, eine Art Roadmap und mittel- bis langfristige Planung und einen gut gepflegten und strukturierten Backlog zu haben. Wir sind selber gespannt, wie sich diese Applikation weiterentwickeln wird. Positiv ist, dass wir die Applikation so aufbauen konnten dass sie ein klares Bedürfnis der Anwender abdeckt und damit das Interesse sehr hoch ist an einem weiteren Ausbau.

Wo kann dieses Vorgehen helfen?

In allen Bereichen/Themen/Problemen/Bedürfnissen, in welchen iterativ die richtige Lösung gefunden werden soll, kann dieser Ansatz eingesetzt werden. Es hilft, das Risiko zu minimieren dass eine Applikation gebaut wird, die das Bedürfnis der Anwender nicht richtig abdeckt. Es kann sogar sein, dass mit dem iterativen Vorgehen und der Erstellung eines Prototyps überhaupt erst das Bedürfnis aufgedeckt werden muss. Auch dafür eignet sich dieses Vorgehen. Solange wir keine Bestätigung haben, dass wir mit einer Applikation resp. einem Prototypen ein konkretes Bedürfnis adressieren und dies gemäss den Erwartungen der Anwender abdecken können, soll so schlank und kostengünstig vorgegangen werden wie möglich. Ist diese Bestätigung dann vorhanden, kann dann skaliert werden und in eine reguläre Umsetzung und Applikationsentwicklung übergegangen werden.

Wie könnt ihr dies auch für euch nutzen?

Auf unserer Webseite finden sie mehr Informationen zu unserem Enabling Team: https://www.avega.ch/enabling-team/. Gerne stehen wir natürlich auch persönlich zur Verfügung bei Fragen oder Interesse zu diesem Angebot.