Einige sehen es als unnötigen Ballast, andere als notwendige Aufgabe und ganz andere Experten sagen, dass heute nichts mehr ohne ihn geht. Die Rede ist vom beliebten Projektmanagement.
Wir von der Ceteris können eines auf jeden Fall sagen, kein Projekt gleicht dem anderen und so verschieden unsere Kunden sind, so verschieden sind auch die umzusetzenden Anforderungen und Inhalte. Zudem füllt sich der Trog noch mit der Vielfältigkeit der internen Skills. Wir sind nicht nur zertifizierter Microsoft Partner und können Azure, SQL-(Server) und Co., sondern unser Technikportfolio erstreckt sich auf Tableau, Gapteq, Cubeware und auch Tools wie Zebra BI, NBI und Hi-Chart aus. Und all diese Technologien werden von Mitarbeitern bedient, die wissen was sie tun. Was dann schlussendlich zu der Frage führt: Wie steuern wir unser Know-How und bringen es gewinnbringend für unsere Kunden ein?
Eine Musterlösung für das Projektmanagement gibt es nicht und wird es auch wahrscheinlich nie geben. Nicht, weil wir Projektmanagement nicht können, sondern weil sich gerade im IT-Umfeld die Halbwertszeiten der Neu- und Weiterentwicklungen stetig reduzieren. Worauf wir aber Einfluss nehmen können, ist die eigene Haltung und der Umgang mit diesen äußeren Einflüssen, der sich ständig verändernden Projektwelt. Und genau dafür ist dieser Blog-Artikel gedacht.
Wie macht Ceteris Projektmanagement?
Um hier das schon fast verbrannte Stichwort „Agilität“ ins Spiel zu bringen, beschreibe ich einmal den Aufbau unseres Vorgehens. Denn das, was wir tun, trifft genau das. Wir agieren und reagieren mit agilen Methoden auf die Vielfältigkeit unserer Projekte und unserer Skills. In Anlehnung ans SCRUM haben wir Anfang 2019 damit begonnen, unsere Aufgaben und Themen in 2-wöchigen Zyklen, sogenannten Sprints, zu organisieren. Das machen wir jetzt für alle Projekte, ob interne User Group für den Wissenstransfer, eintägige Workshops oder die großen Projekte mit hoher Kapazitätsbindung der Entwickler. Alle Mitarbeiter sprinten im selben Rhythmus. Dieses Vorgehen fördert viele Vorteile zutage und bringt oft die notwendige Klarheit für die gemeinsame, projektübergreifende Zusammenarbeit.
Einige Vorteile stichpunktartig zusammengefasst:
- Gemeinsames Backlog (projektübergreifende Aufgabensammlung) für vorstehende Arbeit
- Schnelle Reaktionsfähigkeit bei Änderungen des Scopes oder neuen Kundenanforderungen
- Planungssicherheit für Kapazitätsauslastung (Einplanung der Mitarbeiter für die jeweiligen Projekte)
- Unterstützungsmöglichkeiten untereinander
- Gemeinsames Verständnis der Aufgaben und Projekte
- Priorisierung der Aufgaben
- Gemeinsame Abstimmungstermine (Sprint-Planning, Dailys, Review und Retrospektive)
- Inhaltlicher Austausch über die Projekte
- Organisatorischer Austausch und Justierung der Planung
- Schnelle Einflussnahme bei Hinderungen oder Problemen in den Projekten
- Stetige Verbesserung der Projekte, des Vorgehens und der Zusammenarbeit
- Stärkung des gemeinsamen Entwicklungsteams (niemand fühlt sich „allein gelassen“)
- Einbindung des Kunden möglich (Mitsprachrecht bei der Vor-Priorisierung)
- Schnelle Aufnahme und Einphasung neuer Kundenprojekte
Um Klarheit zu schaffen, erkläre ich die Funktionen unseres SCRUM-Teams, zeichne unseren Sprintablauf auf und erkläre euch die einzelnen Schritte.
Wer sind denn die „Protagonisten“ unseres SCRUM-Teams?
Die wichtigsten Menschen im SCRUM sind und bleiben die Entwickler des Entwicklungsteams. Sie bringen die meiste Wertschöpfung, setzen die Anforderungen und Aufgaben der Kunden um, halten die Leistungsfähigkeit durch interne Arbeiten am Laufen und beseitigen Problemfälle der Kunden. Unser Entwicklungsteam besteht aus etwa 13 Menschen. Die Skills verteilen sich breit gefächert im gesamten Team, was super für die individuellen Projekte geeignet ist, und auch für Unterstützungen untereinander oft zum Tragen kommt. Einige der Entwickler sind gleichzeitig technische Ansprechpartner (Projektleiter) für die Kunden.
Unser SCRUM-Master hat eine organisatorische Klammerfunktion. Er koordiniert die Termine und bereitet diese vor und unterstützt bei der Pflege des Backlogs. Er ist gleichzeitig Ansprechpartner für einige Kundenprojekte und unterstützt bei der Rechnungserstellung.
Die Rechnungen werden monatlich von unserer Controllerin erstellt. Bei ihr kommen die finanziellen Fäden zusammen und sie ist es auch, die spätestens am Monatsanfang dafür sorgt, dass alle Arbeiten den Kunden in Rechnung gestellt werden.
Natürlich gibt es auch noch weitere Funktionen innerhalb der Ceteris AG, die aber primär nicht Teil des SCRUM-Teams sind, außer, sie arbeiten an Kundenprojekten mit.
Innerhalb der Sprints, also zu jedem Zeitpunkt, sammeln wir externe und interne Aufgaben und Anforderungen oder auch Problemfälle von Kunden ein. Diese schreiben wir in unseren Backlog, um sie später oder aber – bei hoher Dringlichkeit – sofort zu verarbeiten. Ganz gut ist es, wenn alle bekannten Anforderungen und Aufgaben bis zum Freitag der ungeraden Wochen bekannt sind. Warum? Weil am Wochenstart der geraden Wochen unser Sprint Planning stattfindet.
Der Sprintstart/Das Sprint Planning
Da unsere Sprints in den geraden Wochen beginnen und in den ungeraden Wochen enden, haben wir sie schlichtweg auch so genannt (Bsp. Sprint KW 34-35 2019). So ist auf Anhieb klar, welche Aufgaben wann begonnen oder beendet werden müssen. Das Sprint Planning nimmt durch die gute Vorarbeit der vorpriorisierten und vorgeschätzten Aufgaben wenig Zeit in Anspruch. Es ist für die Kapazitätsplanung das wichtigste Meeting, weil für die beiden kommenden Wochen detailliert geschaut wird, wie viel Personalressourcen zur Verfügung stehen und wie viel Arbeit erledigt werden muss. Die (zeit-)geschätzten Aufgaben werden vom Projektleiter und den Entwicklern für jedes Projekt kurz durchgesprochen und auf das Entwicklungsteam verteilt. Es werden mögliche interne Unterstützungen besprochen und Aufgaben den Entwicklern zugewiesen. Am Ende des Sprint Planning Meetings ist unser SCRUM-Board mit den priorisierten und geschätzten Aufgaben gefüllt und der Sprint wird gestartet.
Jeden Morgen findet sich das Entwicklungsteam zusammen und bespricht den gestrigen und den kommenden Tag im Daily Standup. Hier wird innerhalb von 15 Minuten besprochen, ob es Probleme bei der Auftragserledigung gab oder wo zu erledigende Arbeit anders verteilt werden sollte. Durch den täglichen Austausch können Diskrepanzen und Hinderungsgründe frühzeitig erkannt und ausgeregelt werden.
Am Ende des zweiwöchigen Sprints, in der ungeraden Woche (wer aufgepasst hat J), wird der Sprint mit einem Review auf die Projekte geschlossen. Im Review werden die eingesetzten Ressourcen und die ursprüngliche Planung ausgewertet. Einzelne Projekte werden detailliert besprochen, um im nächsten Sprint eine grobe Zielrichtung für die Weiterentwicklung festzuhalten. Das Review ist auch dafür gedacht, Feedback zu den einzelnen Projekten zu erhalten und Fragen durch das Entwicklungsteam zu klären.
Im Anschluss an das Review wird in der Retrospektive das „Wie haben wir den Sprint zum Erfolg gebracht?“ ausgewertet. Die Retro dient der stetigen Verbesserung des Sprintablaufes und zum Erkennen von Barrieren. Diese können sowohl kommunikativer wie aber auch technischer oder organisatorischer Natur sein. Am Ende der Retro werden gemeinsam Maßnahmen definiert, die beim nächsten Sprint Berücksichtigung finden sollen, um die kommenden Sprints nach und nach zu verbessern. Unsere Retros leben vom vertrauensvollen und offenen Umgang miteinander und es können alle Probleme angesprochen werden, die beim Sprint und der Zusammenarbeit aufgefallen sind. Das ist wichtig und hilft sehr, gemeinsam besser zu werden.
Am Monatsende bzw. Monatsanfang (also etwa alle zwei Sprints) werden die Rechnungen erstellt. Da wir unsere geleistete Arbeit größtenteils nach Aufwand berechnen, werden die aufgekommenen IST-Stunden den Kunden in Rechnung gestellt. Sollte es inhaltliche oder buchhalterische Fragen geben, werden diese durch den SCRUM-Master oder durch den jeweiligen Projektleiter geklärt.
Und es fängt von vorne an
So arbeiten wir nun seit etwa 13 Sprints miteinander und haben viele Verbesserungen festgestellt. Die hohe Kommunikation und Transparenz haben zu einer besseren Auslastung und Verteilung der Arbeit geführt. Trotzdem nehmen wir für uns in Anspruch, noch immer nicht am Ziel angekommen zu sein und wollen uns immer weiter verbessern. Und wer weiß, vielleicht können wir auch Sie von unserem Vorgehen begeistern und bei der Einführung vom agilen Projektmanagement unterstützen!
Die Technikfrage
Für die Aufnahme der Aufgaben und Anforderungen und zur Steuerung unseres Backlogs und der Sprints nutzen wir Jira von Atlassian. Damit die Arbeitszeiten dokumentiert und den Kunden in Rechnung gestellt werden können, nutzen wir Blue Ant der Berliner Firma proventis. Hierfür gibt es eine aktive Schnittstelle zwischen Jira und Blue Ant, sodass wir genau sehen können, wie viel Entwicklungszeit auf welches Projekt verbucht wurde und wie viel Budget in welchem Projekt zur Verfügung steht.