Das Teamwork-Blog

Hin und wieder treffe ich auf klagende Coach-Kollegen. „Wenn doch die Kunden nur mehr auf mich hören würden.“ „Wenn mich das Management doch nur verstehen würde.“ „Die müssen doch auch sehen, was ich sehe.“ Oder auf agile Terminatoren: „Den habe ich es aber jetzt mal richtig gezeigt, wo der agile Hammer hängt und ihren Agilisierungsansatz zerlegt.“ Häufig verbirgt sich dahinter eine große Angst: Vor einer Gefährung des eigenen Status. Vor sozialem Schmerz.

Wer nach gutem „Zeit- und Selbstmanagement“ fragt, sucht Wege zum Erfolg. Hierzu gibt es ein paar Dinge zu sagen. Der dritte Teil der kleinen Serie.

In agilen Projekten wird iterativ gearbeitet. Alle Anforderungen stehen in einem Product Backlog, werden priorisiert und in den einzelnen Sprints schrittweise umgesetzt. Dabei wird bereits geschäftlicher Nutzen erzeugt und die jeweils neu erzeugten Funktionsbausteine soweit irgend möglich schon in den Echtbetrieb genommen.  Aber kann dabei nicht auch großer Murks erzeugt werden? Kann es nicht vorkommen, dass man nach dem 25. Sprint feststellt, dass man sich in eine Sackgasse entwickelt hat? Können sich die neuen Anforderungen Nummer 94 und 95 nicht mit  den schon realisierten Funktionalitäten 1 bis 93 widersprechen? Wie sichert man eine konsistente Gesamtlogik des Projekts über all seine Sprints hinweg?  Eine Antwort darauf heißt „Domänenmodell“.

Die Kollegen von MovingImage, ein Softwareunternehmen und eine Art deutsches Youtube für Recruiting- und Image-Videos, haben in den letzten zwei Jahren ihre komplette Firma agilisiert. Im Juli 2015 habe ich sie in Berlin besucht. Ich bin beeindruckt.

Ein ungewöhnlicher Titel für das Teamworkblog... Feste feiern? Hier? Im Büro? Hallo? Aber ja! Unbedingt! Ich rede hier nicht von den allfälligen Umtrünken zu Geburtstagen, sondern das Feiern von abgeschlossenen Meilensteinen, gelungenen Projekten, eingehaltenen Zeitplänen und manchem mehr.

Projekte zur Einführung von Unternehmenssoftware sind immer eine Herausforderung für Unternehmen. Wolf und ich sind uns sicher, dass man solche IT-Projekte, die meist fast alle Mitarbeiter benutzen sollen, mit Scrum steuern kann. Scrum ist ein Framework, das nicht alle Fragen in solchen Projekten angeht. Die Begriffsarbeit ist wichtig. Und am Anfang brauchen wir eine Vision, die auf mehr Köpfe verteilt ist. Das ist die Grundidee in unserem Leitfaden.

Wie viel muss man über eine unsichere Aufgabe (z. B. ein Projekt) vorher wissen, um dafür ein Angebot abzugeben? Wie viel Puffer muss ich aufschlagen? Eigentlich wissen wir oft mehr über diese unsichere Aufgabe als uns bewusst ist. Und dieses Wissen können wir für die Schätzung benutzen.