Archiv

Eigentlich sind langlaufende Projekte etwas tolles. Als Entwickler gewinnt man Sicherheit, man versteht den Kunden und seine Anwendungsdomäne immer besser, kann sich dadurch auf technische Themen fokussieren. Die Projektrisiken sind besser einschätzbar, der Kunde muss immer weniger erklären weil die Entwickler sein Umfeld immer besser verstehen und nicht zuletzt für Dienstleister bietet ein langfristiges Projekt auch wirtschaftliche Sicherheit und planbare Auslastung für einen längeren Zeitraum. Bei der artiso haben wir einige Projekte die ohne einem definierten Ende laufen, d.h. so lange der Kunde mit unseren Leistungen zufrieden ist, können wir, zumindest auf absehbare Zeit, in dem Projekt aktiv weiterarbeiten. Wir nutzen in diesen Projekten Scrum und ich bin absolut überzeugt davon, dass die Entwicklung in kurzen Sprints mit einem klar definierten Sprint-Ziel viele Vorteile bietet gegenüber einem Projekt in dem der Planungshorizont Monate oder gar Jahre umfasst. Aber was ich in letzte Zeit beobachte, die Teammitglieder in den langlaufenden Projekten sind weniger zufrieden als die, die in Projekten mit kürzerer Laufzeit arbeiten. Und auch zwischen den langlaufenden Projekten gibt es deutliche Unterschiede. Einzelne Mitarbeiter berichten, dass sie ihr aktuelles Projekt langweilt und dass sie sich unterfordert fühlen. Der erste Erklärungsversuch war, dass in diesen Projekten ältere Technologien (z.B. .Net 3.5) eingesetzt werden. Natürlich kann man hier jetzt sagen, dass das Jammern auf hohem Niveau ist, aber die Mitarbeiterzufriedenheit ist bei uns im Unternehmen ein hohes Gut und so haben wir diesen Punkt sehr ernst genommen und begonnen den entsprechenden Mitarbeitern in anderen Teams neue Herausforderungen zu geben. Aber nach einiger Zeit konnte keine Korrelation zwischen den eingesetzten Technologien und der Unzufriedenheit der Mitarbeiter festgestellt werden. In einem Projekt wurde z.B. die neuesten Technologien genutzt und dennoch hat die Begeisterung und Motivation bei einem Mitarbeiter in kurzer Zeit in Unzufriedenheit umgeschlagen. Es musste also eine andere Ursache dafür geben. Ein paar Gespräche und Überlegungen später, habe ich nun eine neue Theorie, was zu dieser Unzufriedenheit führt: fehlende Zielvorgaben! Das hört sich vielleicht zunächst paradox an, in einem agilen Umfeld zu kritisieren, dass uns die konkreten Zielvorgaben fehlen. Aber die Projekte, in denen wir eine hohe Motivation der Mitarbeiter haben, sind durchweg dadurch gekennzeichnet, dass es in den Projekten Konkrete Ziele gibt. Dies können Messetermine sein, zu denen die neue Software vorgestellt werden soll und wir deshalb möglichst viele geniale Features haben um die Kunden von der neuen Software zu begeistern. Oder ein Termin zu dem der erste Kunde die neue Software einsetzen soll und wir dann fieberhaft daran arbeiten, dass alles was dafür notwendig ist, in der Software drin ist. Oder wir haben ein sehr begrenztes Budget und müssen in diesem Rahmen für den Kunden den maximal möglichen Nutzen realisieren. Was diese Ziele alle gemeinsam haben: Sie stellen eine Herausforderung für das Entwicklungsteam dar. Im Gegensatz dazu haben wir teilweise Projekte, wo zu Beginn des Sprint geplant wird, was am Ende fertig sein sollte und das wird dann im Sprint Review dem Product Owner vorgestellt. Wenn das Team das Ziel erreicht hat, gibt es ein kurzes Lob, wenn nicht, zeigt sich das Team zerknirscht, aber die fehlenden Features werden in den nächsten Sprint geschoben und dort dann einfach fertiggestellt. So haben wir zum Teil schon über 6 Monate und länger ausschließlich für den Product Owner entwickelt und der hat als Teil des Scrum Teams natürlich auch ein großes Verständnis für alle Probleme die dazu geführt haben, dass das Sprint-Ziel nicht erreicht wurde. Mein Fazit ist, dass Software-Entwickler Herausforderungen mögen, vor allem, wenn sie sich als Teil einer Gemeinschaft fühlen, die aus dieser Herausforderung das Beste herausholt. Also einfach unrealistisch kurze Timelines setzen ist nicht die Art von Herausforderung von der ich spreche, sondern zu einem bestimmten Termin eine überzeugende neue Version bereitzustellen, die coolste Benutzeroberfläche aller Zeiten zu bauen oder die Performance der Anwendung signifikant zu verbessern. Wichtig ist, dass das Team kontinuierlich überprüfen kann, wie der Fortschritt auf dem Weg zu diesem Ziel ist, also z.B. wie viele Elemente haben wir noch auf dem Backlog die wir unbedingt bis zur Messe umsetzen müssen, was ist die Zielvorgabe für die Performance, wie reagieren die Anwender auf unsere neue Oberfläche. Und es ist wichtig, dass gemeinsam mit dem Product Owner für die Zielerreichung “gestritten” wird, also z.B. ist dieses Feature wirklich unbedingt notwendig oder können wir nicht etwas anderes, wichtigeres implementieren, brauchen wir dieses Feature in dieser Form oder finden wir eine einfachere Lösung die zunächst auch genügt? Fazit: Diese Herausforderungen und die gemeinsame Anstrengung im Team zu Zielerreichung, das ist ein wichtiger Teil der Motivation von Software-Entwicklern. Wir sind nun daran, mit unseren Kunden abzustimmen, wie wir in den Projekten über Ziele die Herausforderungen vergrößern können. Das passt auch zum Feedback eines meiner Teams die sich bei mir als Scrum Master beklagt haben, dass sie in dieser Iteration zu wenig Arbeit haben und der Product Owner keine PBIs vorbereitet hat um sie mit weiterer Arbeit zu versorgen. Damit halte ich die These widerlegt, dass der Mensch von Haus aus faul ist und nur dann Leistung bringt, wenn er entsprechende Anreize (Geld, Druck) empfängt. Somit sehe ich durch unsere aktuelle Situation die Beschreibung im Buch Drive von Daniel Pink absolut bestätigt.