+43-676-330-4803KontaktImpressum en de

Blog

Messungen als Leistungssport

Vorige Woche durfte ich in einer Tram in Zürich (in Wien würde man Bim sagen und das deutsche Wort ist wahrscheinlich Straßenbahn) – mehr oder weniger gezwungenermaßen – eine interessante Unterhaltung mitverfolgen. Zwei ältere Herren in der Sitzreihe hinter mir führten eine angeregte Diskussion darüber, was in ihrem Unternehmen wohl als Umsatz gerechnet werden könne und was nicht. Es stellte sich heraus, dass gerade die Zielvereinbarungsgespräche für das neue Jahr liefen und anscheinend wurden die Herren mit sehr ambitionierten Umsatzzielen beglückt. In dem Gespräch versuchten sie nun herauszufinden, was man dem Vorgesetzten wohl alles als Umsatz verkaufen könnte. Unter den Ideen fanden sich Vorschläge wie “jede Anwesenheit in einer Filiale des Unternehmens wird als Umsatz gezählt” oder “Hilfestellungen für interne Kunden” usw. Mit viel Kreativität wurde versucht, den zu erreichenden Messpunkt – das Umsatzziel – zu erreichen.

A bug’s life
Ähnliches erlebe ich auch immer wieder bei Software-Teams. Kunden sind zum Beispiel mit der Qualität der gelieferten Software nicht zufrieden. Deswegen schwört der Teamleiter seine Leute darauf ein, die Anzahl der Bugs zu senken. Damit er auch weiß, ob das Team am richtigen Weg ist, werden Messungen durchgeführt. “Anzahl der Bugs im Produktivsystem” lautet dann beispielsweise die zu optimierende Maßzahl. Die Aufgabe der Entwickler ist es nun, die Anzahl der Bugs zu senken. Klingt ja sehr vernünftig! Der Plan sagt, dass sie ihre volle Aufmerksamkeit auf das Thema Qualität richten und dann wird die Kundenzufriedenheit nur so in die Höhe schnellen.

Mit dem Marschbefehl der Bug-Minimierung geht es nun ans Werk. Relativ bald lassen sich skurrile Diskussionen zwischen Entwicklern und Produktverantwortlichen verfolgen: “Das ist doch kein Bug! Ihr habt das Feature eindeutig falsch beschrieben.” Warum ist das wichtig? Naja klar, die Entwickler wollen ja die Anzahl der Bugs im Produktivsystem reduzieren und somit ist es sehr wichtig, was als Bug gezählt wird und was nicht. Jede gewonnene Diskussion bringt uns unserem Ziel scheinbar näher – weniger Bugs im Produktivsystem.

Nicht die Messung muss optimiert werden, sondern das Produkt!
Doch was war eigentlich der initiale Grund, warum die Messung eingeführt wurde? Den Kunden soll ein qualitativ hochwertiges Produkt geliefert werden. Wird die Qualität des Produkts durch die Diskussion “was ist ein Bug und was nicht” höher? Sicher nicht! Das Resultat: Es wird die Messungen und nicht die Qualität des Produkts optimiert. Ganz nebenbei entwickelt sich dadurch auch noch eine hervorragende “Finger-Zeig-Kultur” – “Du bist schuld, nicht ich!”

Ähnliches haben auch die beiden Herren in der Tram versucht: Es ging in der ganzen Diskussion nur darum, kreative Schachzüge zu entwickeln, damit der Messpunkt “Umsatzziel” am Jahresende erreicht werden kann.

Es stellt sich immer wieder heraus, dass Messungen eine wirklich gute Sache sind. Aber nur, wenn erstens das Ziel der Messung klar ist und zweitens das Ziel auch tatsächlich verfolgt wird.

Gibt es wirklich keine Reihenfolge der Arbeitsschritte in der agilen Softwareentwicklung?


Viele Verfechter von agilen Softwareentwicklungsmethoden argumentieren, dass Softwareentwicklung eine kreative Tätigkeit ist und somit keiner Reihenfolge von Arbeitsschritten folgt. Demnach ist Kanban natürlich eine Katastrophe, da es ja verlangt, die gelebten Arbeitsschritte zu visualisieren.

Wir sind uns einig: kochen und backen sind sehr kreative Tätigkeiten. Wir experimentieren mit Gewürzen, kombinieren immer wieder neue Zutaten und jedes Gericht wird dadurch einzigartig. Wir sind uns sicher auch einig, dass kochen und backen trotz des kreativen Vorganges einer gewissen Reihenfolge an Arbeitsschritten folgt. Beim Backen einer Geburtstagstorte hat sich zum Beispiel herausgestellt, dass es nicht ganz so optimal ist, die Kerzen schon mal in die Eier reinzustecken. Für eine gelungene Geburtstagstorte passieren da häufig noch ein paar Arbeitsschritte zwischen drin, bevor wir mit den Kerzen herumexperimentieren.

Auch in der Softwareentwicklung hat sich herausgestellt, dass es z.B. sinnvoll ist, eine User Story zuerst zu entwickeln/programmieren, bevor sie released wird. Es ist auch hilfreich, eine User Story zuerst zu schreiben und erst dann mit der Programmierung zu beginnen. In Scrum ist sogar eine eigene Rolle definiert, die Verantwortung über User Stories hat – der Product Owner. Es muss sogar sichergestellt werden, dass sich bei den Stories während eines Sprints nichts ändert. Es ist auch “verboten”, dass das Scrum-Team neue Stories während eines Sprints annimmt. Somit ist es sogar eine Voraussetzung, dass jede User Story eines Sprints vor dem Sprint fertig sein muss. Haben wir hier vielleicht doch eine gewisse Reihenfolge der Arbeitsschritte in der agilen Softwareentwicklung identifiziert…

Gründung des stoos Netzwerkes, STOOS, CH

Dr. Klaus Leopold war Gründungsmitglied des Management-Netzwerks STOOS. Gemeinsam mit 20 weiteren Vordenkern fand im Ort Stoos in dem Schweizer Alpen das erste Gathering statt.

Erstes Kanban-Training mit David Anderson in der Schweiz, ZÜRICH, CH

Klaus und David im Kanban-Duett. LEANability organisierte das erste Training mit David Anderson in der Schweiz. Klaus war Co-Trainer und als kleine ungeplante Show-Einlage gab es ein Feuer im Haus. Passend zum Thema Serviceklassen…