Transparenz durch 4 Kriterien. Schlecht sichtbare Arbeit sichtbar gemacht.

Um effizient Software und Systeme zu entwickeln und anspruchsvolle Projekte richtig steuern zu können, ist Transparenz essentiell. Es ist elementar, dass allen Beteiligten die Anforderungen transparent und verständlich sind. Die Risiken, Abhängigkeiten und zu erledigenden Arbeiten klar sind. Wie kann in Projekten schlecht Sichtbares besser sichtbar und damit greif- und begreifbar gemacht werden?

Dieser Artikel zeigt wie mit einfachen visuellen Mitteln eine solche Transparenz erreicht werden kann.

Sichtbares und Unsichtbares

Was bedeutet Sichtbares in Bezug auf Arbeit? Es geht darum den aktuellen Status einer Arbeit oder Tätigkeit zu sehen. In handwerklichen Berufen und Tätigkeiten, in welchen Handfestes geschaffen wird, ist die Sichtbarkeit meist automatisch gegeben. Zum Beispiel ein Feinbäcker, welcher ein Kuchenblech voll Törtchen macht, sieht auf einen Blick, bei welchen Törtchen welche Arbeitsschritte schon gemacht wurden respektive was noch fehlt (siehe nebenstehendes Bild).

Wie sieht das aber im Umfeld mit eher kopflastige Arbeiten aus? Vieles ist vom Handwerk zur Wissensarbeit geworden. Was ist beispielsweise der Status des folgenden Software-Codefragmentes? Ist es fertig? Was fehlt noch? Welche Schritte sind schon gemacht?

Das lässt sich nicht so ohne weiteres beantworten. Selbst wenn wir den Sourcecode genauer ansehen könnten und uns Zeit dazu nehmen würden, wäre es immer noch sehr schwierig den genauen Status dieses Artefakts zu benennen.
Ähnlich verhält es sich mit den folgenden in einem Software Projekt anfallenden Tätigkeiten:

• Kundenanforderung umsetzen
• Anforderung testen
• Code überprüfen
• Architektur erstellen und dokumentieren
• Risiken behandeln
• Use Case implementieren

Warum ist Sichtbarkeit und damit Transparenz wichtig?

Wie beim Feinbäcker ist es auch für uns als Wissensarbeiter wichtig, den Stand der  Arbeiten in einem Projekt zu kennen. Unsere Arbeiten sind vernetzt. Arbeitsergebnisse hängen voneinander ab. Es ist deshalb wichtig zu wissen wann etwas fertig wird, oder wie lange es geht um etwas fertig zu machen. Kurz es geht um Planbarkeit.

Auf Projektarbeit bezogen sollten jedoch auch Risiken, Abhängigkeiten oder sämtliche Projekterzeugnisse wie Dokumente, Funktionen, Use Cases, Anforderungen,… sichtbar gemacht werden. Denn wie Tom DeMarco sagt: «You can’t control what you can’t measure» ist es essentiell in der Projektarbeit Kontrolle sprich eine aktive Steuerungsmöglichkeit zu haben. Folgenden Fragen stellen sich: Was ist der Status der Arbeit? Was ist fertig, was noch nicht? Was läuft gut, was nicht? Wo muss ich als Projektleiter steuernd eingreifen? Wo sind Massnahmen notwendig?

Kriterien für transparente, sichtbare Arbeit

Basierend auf meinen Erfahrungen müssen für sichtbare Arbeit und damit Transparenz die folgenden 4 Kriterien erfüllt sein:

1. Der Typ der Arbeitseinheit muss eindeutig definiert sein. Das heißt, es muss klar sein für welche Arbeitseinheit Sichtbarkeit erreicht werden soll.
2. Für die definierte Arbeitseinheit muss der Workflow (Arbeitsablauf) bekannt und definiert sein. Welche Arbeitsschritte sind für die komplette Abarbeitung notwendig. In welcher Feinheit ist Sichtbarkeit gefordert?
3. Der Kontext in der sich die konkrete Arbeitseinheit befindet muss bekannt sein.
4. Für die konkrete Arbeitseinheit muss nun der Status im Workflow aufgezeigt werden. Oder anders gesagt: Es muss aufgezeigt werden, in welchem Arbeitsschritt sich die Arbeitseinheit befindet.

Im Agilen und Lean Umfeld ist es üblich sogenannte Kanban Boards zu erstellen, um Sichtbarkeit von Arbeit zu erzeugen.

Transparenz durch ein Kanban Board

Nachfolgend ein einfaches Kanban Board mit einer Visualisierung von Arbeitseinheiten (Tasks):

Aber reicht es ein Kanban Board zu erstellen und jede Arbeitseinheit als Karte (real oder digital) in der „Todo“, „In Progress“ oder „Done“ Spalte aufzuführen?

Sehen wir uns dazu nochmals die Kriterien für Sichtbarkeit an und prüfen dann, ob diese erfüllt sind:

1. Typ der Arbeitseinheit muss eindeutig definiert sein.
2. Für die Arbeitseinheit muss der Workflow bekannt und definiert sein.
3. Kontext muss bekannt sein.
4. Status im Workflow muss sichtbar sein.

Zu Kriterium 1:
Ist der Typ der Arbeitseinheit eindeutig definiert? Aus meiner Sicht nicht. Es ist nicht klar, ob das alles Implementierungsarbeiten sind. Oder vielleicht Fehleranalysen? Oder Fehlerbehebungsarbeiten? Oder gar Dokumentationsarbeiten? Wahrscheinlich haben die verschiedenen Typen auch unterschiedliche Workflows. Natürlich kann alles generalisiert als „Task“ dargestellt werden. Aber gibt das wirklich die geforderte Sichtbarkeit und damit Planbarkeit?

Zu Kriterium 2:
Ist der Workflow bekannt und definiert? Ja. Der Workflow ist „Todo“ –> „In Progress“ –> „Done“. Aber ist das wirklich der richtige Workflow, welcher uns genügend Sichtbarkeit bringt?

Zu Kriterium 3:
Ist der Kontext bekannt? Rein mit diesem Kanban Board wohl eher nicht. Zeigt das Board alle Arbeiten eines Projektes? Von welchem Team? In welchem Sprint? In welchem Teilgebiet? Es ist wichtig hier den Kontext (Scope) zu wissen und explizit zu machen.

Zu Kriterium 4:
Ja, der Status der Arbeitseinheiten ist im Workflow sichtbar – sofern alle Arbeitseinheiten den gleichen Workflow haben (wie bereits bei Kriterium 1 in Frage gestellt).

Nur mit dem Eintragen von Karten für jeden Task auf einem einfachen Kanban Board ist üblicherweise noch nicht genügend Sichtbarkeit erreicht!

Verbesserte Sichtbarkeit würden folgende Definitionen/Maßnahmen erreichen:

• Jede Karte steht für eine „Software Implementierungsarbeit“
• Der Workflow sieht wie folgt aus: „Open“ –> „Design in Progress“ –> „Coding in Progress “ –> „Testing in Progress“ –> „Reviewed“ –> „Done“
• Kontext: Teilprojekt ABC; Sprint 22Die entsprechenden Karten (vom Typ „Software Implementierungsarbeit“) sind im Kanban Board den entsprechenden Workflow Schritten zugeordnet.

Oft ergibt es Sinn nicht nur von generalisierten Tasks zu sprechen, sondern von den konkreten Artefakten, auf welche sich die Tätigkeiten und Arbeiten beziehen. Wenn es beispielsweise darum geht Use Cases umzusetzen, auch diese Use Cases als sichtbare Arbeitseinheiten visualisiert werde sollten – und nicht „Tasks“.

Transparenz für komplexe Themen?

Gerade auch komplexe Themen wie Architekturarbeit oder Erstellen einer Spezifikation lohnen sich sichtbar zu machen. Vor allem bei grösseren Systemen kann damit Planbarkeit, ein gemeinsames Verständnis und somit Effektivität und Effizienz erreicht werden. Bei einer systematischen Architekturerstellung könnte eine sinnvolle Arbeitseinheit ein „Architektur Signifikantes Requirement“ sein.

Damit ergibt sich beispielsweise die folgende Definition von Sichtbarkeit:

• Arbeitseinheit: „Architektur Signifikantes Requirement“.
• Der Workflow eines solchen „Architektur Signifikantes Requirement“ ist der Folgende: „To be addressed“, „partly addressed“, „addressed“
• .Der Kontext mit dem angedeuteten Architekturprozess ist der Folgende:

• Auf einem Kanban Board werden die einzelnen Arbeitseinheiten gemäss dem Workflow aufgeigt.

Mehr zum Thema Architekturerstellung findest Du hier: Software Architektur ist nicht komplex – Software Architektur einfach und klar

Zusammenfassung

Sichtbarkeit und damit Transparenz ist essenziell für kontrollierbare Projektarbeit. Sichtbarkeit bezieht sich nicht nur auf generalisierte „Tasks“. Bessere Sichtbarkeit ist möglich für konkretere und auch komplexere Typen von Arbeitseinheiten.

Sichtbarkeit kann durch die Definition der folgenden 4 Elemente erfüllt werden:

• Typ der Arbeitseinheit
• Workflow
• Kontext
• Sichtbarer Status der Arbeitseinheiten im Workflow.

Einfache Handskizzen als Visualisierung sowie einfaches Wallwork (Flipchart oder Whiteboard mit Post-Its) reichen oft aus um eine gute Sichtbarkeit und damit Transparenz zu erreichen. Falls Du das lernen möchtest, dann siehe hier: Komplexität beherrschen lernen – die bewährten visuellklar Trainings.

Viel Erfolg mit dem Sichtbarmachen Deiner Projekte und Vorhaben.

Matthias