KickOff Workshop für die Erstellung von Toolchains

Basisempfehlungen für den Startpunkt

von Alexander Weichselberger

Bei der Definition, WAS eine Toolchain leisten muss, empfiehlt sich eine strukturierte Aufnahme der Anforderungen. Wir haben in den letzten Jahren dutzende Toolchains realisiert – folgend unsere Basisempfehlungen für diesen Startpunkt zur „Toolchain als Lösung“.

(Am Start einer Prozess oder Organisationsunterstützung durch ein Tool stellt sich schnell die Frage nach dem richtigen Tool. Diese Thematik hat Alexander Vukovic bereits in seinem Vortrag zur Open Source Testautomationstool-Auswahl hervorragend beschrieben, deshalb gibt es in diesem Blog keine weiterführenden Kommentare.)

Gehen wir davon aus, dass die Toolauswahl bereits getroffen wurde und auch das Ziel der Realisierung zumindest in seinen groben Zügen vorliegt („Anforderungen“). Darüber hinaus ist auch klar, wer im Fachbereich für diese Realisierung Inputgeber ist. Letzteres ist maßgeblich für die Durchführung eines Kick-Off Workshops mit dem Ziel, folgende Vorstellungen abzustimmen:

  • Agenda
  • Timeline
  • Ziele
  • Prinzipien
  • Player & Stakeholder
  • Knowhow Transfer
  • Toolrahmenbedingungen
  • MoSCoW
  • Toolchain Projekt
  • Ideenboard – Jetzt & Später
  • Artefakte – Tickettypen und Co
  • Funktionen
  • Workflow

Sie fragen sich sicherlich, ob es für diese Vielzahl an Punkten eine spezifische Reihenfolge gibt.

Empfehlung Nr 1.: Veranstalten Sie diesen KickOff als WorldCafe ® (https://de.wikipedia.org/wiki/World-Café ) oder GridWorkshop.

Das Format GridWorkshop ist eine SEQIS Eigenentwicklung. Im Kern geht es darum, einen Raum mit unterschiedlichen Themeninseln/-ankern zu schaffen, die typische Frontal-präsentation zu vermeiden und die Teilenehmer dazu zu bringen, sich zu „bewegen“ – im Raum, durch die verstreuten Themeninseln, umfassend, dh. jeder für jedes Thema um den Knowhow-Abgleich abzusichern, inhaltlich, weil im Gesamtbild der Punkte gut erkennbar ist, wo ggf. verhärtete Positionen („ich will aber“) Alternativen brauchen. Timeboxed stellt sicher, dass der Zeitbedarf in einem Rahmen bleibt, der für alle leicht machbar ist.

Letzteres ist ein Workshop, an den für die einzelnen Punkte - vergleichbar zum Worldcafe – einzelne Flipcharts erstellt werden, die dann gleichzeitig (!) von den Teilnehmern timeboxed (!) bearbeitet werden. Es werden mehrere Zyklen je 15-20 Minuten inszeniert, die Teilnehmer schreiben ihre Überlegungen dazu auf PostIt’s und kleben sie zu den jeweiligen Themen-Flipcharts (folgend gehen wir von einem GridWorkshop aus).

Ein typischer Ablauf eines solchen Grid-Workshops könnte wie folgt sein:

  • Vorstellung (Teilnehmer)
  • Workshop Vorgehen
  • Runde 1 & 2
  • Pause
  • Runde 3 & 4
  • Diskussion einzelne Themen in der Gruppe (mit Live Korrektur + Ergänzungen)
  • Next steps

Erfahrungsgemäß braucht man für die Vorstellungsrunde und Workshop Vorgehen rd. 20 Minuten. Runden 1 – 4 plus Pause (je 15 min.) macht in Summe 75 min. Für die Diskussion und Zusammenfassung der Flipchart würde ich im Schnitt je 5 min ansetzen (macht im konkreten Beispiel 60 min.). Next Steps und Zeit-Puffer rd. 30 min à dh. in Summe kann ein GridWorkshop gut und gern in 3 bis 3,5 Stunden gemacht werden.

Empfehlung Nr. 2: Egal welchen Workshop Sie machen, gehen Sie aus „Veranstalter“ zumindest zu zweit hin. Teilen Sie die Aufgaben in Moderation und Dokumentation.

Kommen wir nun zu den einzelnen Themenbereichen, die Sie vorbereiten und im Rahmen des Workshops abarbeiten sollten:

Die Agenda

die Agenda

Für strukturierte Teilnehmer ein Muss. Es hat sich bewährt, die Agenda als PostIts zu gestalten und dann im Laufe des Workshops – wenn einzelne Punkte „done“ sind – auch visuell zu „erledigen“.

Spielregeln für den Workshop

... na klar, Spielregeln sind ein „Muss“. Bitte diese jedenfalls in der Vorstellungsrunde des Workshops vorstellen und Zustimmung durch die Teilnehmer abholen. Falls aus dem Ruder läuft – strenger Blick auf die Spielregeln, kurz innehalten... Und zumeist geht’s dann schon wieder besser weiter.

Verlassen wir nun den „Rahmen“ und kommen wir zu den inhaltlichen Punkten und Empfehlungen...

Timeline

Skizzieren Sie die Timeline (heute, zyklische Projektmeetings & Treffen, Milestones und Go Live) und tragen Sie bereits bekannte Phasen (Zeitspanne der Realisierung, erste Zyklen in Produktion, Kommunikation, Ausbildung, usw.) ein. Stellen Sie sicher, dass auch dieses Flip mit PostIt-Gedanken ergänzt und kritisiert wird. Stellen Sie z.B. die Fragen nach kritischen Phasen im Projekt, nach Störungen („Weihnachtsgeschäft“, „Jahresabschluss“, usw.)!

Ziele

... werden leider zu oft nur mit „kennen wir ja eh“ abgetan. Dahinter sind aber handfeste Kriterien für Erfolg/Misserfolg und zumeist haben die einzelnen Stakeholder-Vertreter sehr unterschiedliche Wahrnehmungen, was die Ziele sind.

Geben Sie also diesem Thema entsprechend Raum, instrumentieren Sie bereits von Ihnen als bekannt Eingestuftes und schreiben (!) Sie diese Punkte mit einer noch offenen Checkbox auf das Flip. Im Rahmen der Flip-Vorstellung sollten Sie dann diese Punkte auch noch einzeln besprechen und bei Zustimmung in der Checkbox abhaken oder durchstreichen.

Empfehlung Nr. 3: Achten Sie bei der Vorstellung der Ziele auf Rückmeldungen – gemurmel, Körperhaltung und ähnliches lassen uU auf Zielkonflikte schließen! Sie sollten diesen in diesem Rahmen zumindes

Prinzipien

Prinzipien, also die Grundsätze, für die Entwicklung einer Toolchain können sehr unterschiedlich sein. Es sind oftmals nicht funktionale Anforderungen, die nach Fertigstellung im Sinne einer Erfolgsprüfung nochmals untersucht werden soll; folgende Prinzipien habe ich in meiner Praxis sehr oft an dieser Stelle besprochen:

  • „kann mit angemessenen Zeitaufwand gepflegt werden“
  • Sprache deutsch
  • Integrierte Onlinehilfe
  • Ausbaufähig, erweiterbar
  • Selbsterklärend (= sehr geringer Schulungsbedarf)
  • So gut wie Möglich im Standard bleiben

Knowhow Transfer

Wie soll die Einführung und der Knowhow Transfer für Neulinge der Toolchain gemacht werden? Stimmen Sie an Schulungsvarianten „Train-the-Trainer“ vs „Schulungsorganisation“ bzw. Keyuser-Trainings ab. Zertifizierungen bringen auch sehr oft eine fundierte Ausbildung „im Package“ mit – falls das möglich ist.

Darüber hinaus bieten Online-Hilfe, Erklärungsvideos (mit wesentlichen Punkte aus der Anwendungspraxis) und Hotline auch gute Möglichkeiten, die Anwender auf das „Neue“ vorzubereiten bzw. sie auch laufend zu unterstützen.

Vergessen Sie jedoch bitte nicht, dass Sie ggf. neben dem Training der Anwender auch noch Ihre Systembetreuer schulen und trainieren müssen. Sichern Sie sich ggf. auch externe Unterstützung, insbesondere wenn die Toolchain von Externen entwickelt wurde.

Und auch für das „Umfeld“ sollten Sie neben dem Knowhow Transfer auch eine Information a la „Was ändert sich durch den Einsatz von XY?“ erstellen und z.B. im Intranet platzieren.

Analyse der Player

Kennen Ihre Stakeholder die Plattform, auf der Sie Ihre Lösung aufbauen? Ja?  Nein? Diese Antwort hat eine unmittelbare Auswirkung auf z.B. den Schulungsaufwand bei der Einführung. Aber auch andere Parameter sollten erhoben und beurteilt werden, starten Sie mit der Erhebung der wesentlichen Stakeholder-Gruppe und gehen Sie dann ins Detail:

  • Wie ist die Einstellung von XY (z.B. Buchhaltung) zum vorliegenden Projekt?
  • Welche Bedeutung hat die Toolchain für diese spezifische Stakeholder-Gruppe?
  • Wie war die Zusagen-Verlässlichkeit dieser Gruppe für welche Arbeiten in der Vergangenheit? Müssen wir ggf. Erinnerungsfunktionen oder vergleichbares einrichten?

Empfehlung Nr. 4: Bei dieser Analyse werden ggf. Kritiken an den „anderen“ geäußert. Achten Sie auf eine möglichst neutrale Formulierung dieser Einschätzung, damit Ressentiments gleich von Anfang an v

Toolchain @ Ihrem Unternehmen

Nehmen wir an, bei der konkreten Realisierung setzen Sie auf Atlassian Jira und Confluence. Sind diese Systeme bereits in Ihrem Unternehmen eingesetzt? Ja? Für diesen Fall sollten Sie folgende Punkte bei dem Workshop abstimmen:

  • Wie kommen wir zu Space bzw. Project ?
  • Welche Version – PlugIns – Lizenzen liegen vor?
  • Ist für die externe Unterstützung ein VPN-Zugriff einzurichten
  • Welche Umgebungen gibt es? TEST, PROD...?
  • Mit welchen Personen / Administratoren ist zu sprechen? Nun, idealerweise sind diese Über den Workshop informiert und machen sogar mit... J

Wenn Sie andere Systeme oder Lösungen einsetzen: Oben stehende Liste gibt Ihnen eine gute Ausgangsbasis für die relevanten Fragen zu Ihrer Lösung.

MoSCoW

Kaum ein seriöses Projekt kommt heute ohne einer fundierten Reihung von ToDo’s durch. Führen Sie eine Priorisierung nach MUST – SHOULD – COULD WONT (= MoSCoW) durch und erklären Sie diesen Priorisierungsansatz im Rahmen des Workshops.

Toolchain Projekt

Welche spezifischen Fragestellung sollten Sie im Rahmen Ihres Toolchain-Realisierungsprojekts abstimmen?

Für das Projekt sind Antworten – neben den unzähligen, die ganz allgemein von den Projektmanagement-Frameworks wie PRINCE 2 oder AgilePM empfohlen werden – zu folgenden Fragen erfahrungsgemäß besonders relevant:

  • Welche Reaktionszeiten brauchen wir im Rahmen der unterschiedlichen Phasen (Analyse, Implementierung, Test, Migration, Go Live, Post Go Live)?
  • Wie soll eine kontinuierliche Abstimmung stattfinden? Daily’s, JourFixes mit Statuspräsentationen, Management Reports,...?
  • Wie wollen und sollen wir Projekt-Status kommunizieren?
  • Stichwort Externe: Kann die Toolchain vor Ort realisiert werden – oder besser remote? Was immer definiert wird: Beides bedingt Infrastruktur, also eben Räume oder technische Connectivity...

Ideen für jetzt oder später

Bereits in diesem ersten Workshop werden „Ideen“ kommen, mit denen Sie nicht gerechnet haben oder die nachfolgend erst zugeteilt werden können. Versuchen Sie zumindest den Inhalt der Idee zu verstehen und diese in die Tasche für „Jetzt“ oder aber auch „Später“ zuzuteilen.

Ticket Typen

Jede Toolchain besteht aus eine Art Ticket (z.B. Issuetypes im Jira). Versuchen Sie eine erste Sammlung unterschiedlicher Tickets zusammenzustellen. Ergänzen Sie diese um spezifische Informationen (Attribute), die mit diesem Tickettyp einhergehen. Darüber hinaus sollten Sie auch erste grobe Workflows / Statusketten dieser Tickettypen abzustimmen und zu visualisieren.

Funktionen

Clustern Sie Ihre Toolchain in unterschiedliche funktionale und nicht funktionale Blöcke und sammeln Sie funktionale Anforderungen bzw. Anmerkungen und Kommentare. Diese Aufstellung dient der Visualisierung der unterschiedlichsten Anforderungen – damit sichern Sie ein gemeinsames Bild zur Aufgabenstellung ab. Aber Achtung: Erfahrungsgemäß wird diese Übersicht keine abschließende Erfassung sein sondern nur ein Startpunkt und etwas mehr Detail zur Aufgabenstellung!

Der richtige Startpunkt für eine "Definition of Done"

Auch wenn Sie diesen Punkt – genauso wie die „Funktionen“ -  nicht in diesem Workshop spontan vollständig schaffen werden: Viele Teilnehmer kommen bereits mit klaren (Teil)Zielvorstellungen. Holen Sie sich diese ab.

Zurück

Zum Seitenanfang navigieren