Wieso das Management Development-Teams nicht vertraut
Wenn das Development-Team gerne mit Scrum arbeiten möchte, aber nicht darf, hat das oft mit fehlender Zuverlässigkeit zu tun. Fünf Schritte für mehr Zuverlässigkeit.
Wir haben uns ja schon im letzten Blogbeitrag «5 Praktiken, die bei der agilen Software-Entwicklung helfen» über die Arbeit im Entwicklungsteam unterhalten und darüber, was sich ändern muss, damit diese besser funktioniert. In diesem Beitrag schauen wir uns das Zusammenspiel der Development-Teams mit dem Support- und Management an.
Das Organisationsdiagramm
Wir haben selbstorganisierte Teams, die Produkte bauen. Im Bild unten habe ich das mal illustriert:
Die grünen Produkt-Teams bauen Produkte und das rosa Support-Team unterstützt die anderen Teams. Diese Produkte können alles Mögliche sein, von Software- bis Hardware-Produkten. Ein Produkt ist dadurch definiert, dass es einen Benutzer (User) gibt, der aus dem Produkt einen Gewinn für sich zieht. Sein Leben wird durch das Produkt besser, einfacher oder er kann seine Arbeit schneller erledigen.
Im Gesamtkontext sieht das dann so aus:
Die User sind Rot markiert (hoffentlich gibt es viele von ihnen, denn das ist meistens ein Zeichen für den Erfolg des Produkts).
Das Management habe grau gekennzeichnet. Darunter verstehe ich alle unterstützenden Funktionen, die es in einer Organisation typischerweise gibt: HR-/Personalabteilung, Verkauf, Vertrieb, Marketing, Controlling, Lohnbuchhaltung, interne IT, on-site Leadership, Feel-Good-Officers und Geschäftsleitung.
Wenn wir so ein Organisationsdiagramm haben, wie es oben dargestellt ist, haben wir schon viel Gutes erreicht:
- Der Kunde ist uns so wichtig, dass er auch auf unserem Organisationsdiagramm abgebildet ist. → Cool
- Das Management ist unten platziert. Das suggeriert, dass sie ihre Mitarbeitenden dabei unterstützen, einen guten Job zu machen. → Cool
Zurück zum Vertrauensbruch…
Der Vertrauensalgorithmus nach Larry Maccherone
In diesem Zusammenhang ist der Vertrauens-Algorithmus nach Larry Maccherone ein gutes Konzept. Frei übersetzt von mir, sieht das so aus:
Wobei die einzelnen Begriffe so zu verstehen sind:
- Glaubwürdigkeit = Wie gut weisst du eigentlich, wovon du sprichst?
- Zuverlässigkeit = Wie oft und wie schnell tust du, was du sagst?
- Empathie = Wie sehr zeigst du, dass du dich um die Interessen eines anderen kümmerst.
- Eigeninteresse = Wie offensichtlich ist es, dass deine Worte und Taten deinem eigenen Interesse entsprechen?
Ich möchte an dieser Stelle nicht allzu tief in das Thema Vertrauen eintauchen. Allen, die sich damit jedoch vertieft befassen möchten, kann ich z.B. den Kurs «Professional Scrum Master» empfehlen.
Warum das Management uns nicht vertraut und wie wir das ändern
Wenn wir im Development Team gerne Scrum machen würden, aber nicht so richtig dürfen…
Wenn wir gerne agil wären, aber jemand lässt uns nicht…
….dann ist das meistens unsere Schuld und das hat oft mit unserer Zuverlässigkeit zu tun.
Fragen wir uns einmal:
- Können wir kontinuierlich stabile Software in die Produktion deployen?
- Sind wir sehr wenig (<5%) mit Incidents und Bugs beschäftigt?
- Können wir alle zwei Wochen in einer Sprint Review Zahlen vom Markt, Usern, Demos und unseren Produktfeatures präsentieren?
Die Antworten auf diese Fragen, haben einen grossen Einfluss auf unsere Zuverlässigkeit. Denn wir im Development-Team sind in der Bringschuld. Auf Englisch sagt man «Walk the Talk». Das heisst, den Worten müssen auch Taten folgen.
Wir sollten uns also überlegen, wie wir mehr Zuverlässigkeit erreichen, denn durch diese können wir dem Kunden näher kommen und Empathie zeigen. Das wiederum erhöht unsere Glaubwürdigkeit, weil wir seine Sprache sprechen und auch zeigen, dass wir alle im selben Boot sitzen. Denn hey, wir sind ja eine Firma und es ist auch in unserem Eigeninteresse, dass das alles gut kommt. Oder nicht?
5 Schritte zu mehr Zuverlässigkeit
Um die Zuverlässigkeit zu erhöhen, empfehle ich folgende Massnahmen:
1. Klare Definition of «Done» pro Produkt
Wie eine Aufgabe als erledigt definiert wird, lässt sich hier nachlesen.
2. Continuous Integration pro Produkt
Continuous Integration (kontinuierliche Integration) ist eine technische Praxis, bei der jede Produktänderung (Code, Konfiguration) ein Ereignis auslösen sollte, bei dem Ihr gesamtes Produkt automatisch neu gebaut, integriert und getestet wird. » mehr zu Continuous Integration
3. Stabile Continuous Delivery pro Produkt
Continuous Delivery (kontinuierliche Lieferung) bedeutet, dass das System während der Entwicklung immer im Zustand «production-ready» gehalten wird, wartend auf die Freigabe (Release) des Product Owners, um mit Minimalaufwand das Produkt in die Hände des Benutzers zu geben. » mehr zu Continuous Delivery
4 Continuous Deployment & Technisches Monitoring in Production
Continuous Deployment (kontinuierliche Bereitstellung) heisst, zusätzlich zur kontinuierlichen Integration jede Produktänderung automatisch in die Produktion zu übernehmen bzw. zu deployed. Der Status «deployed» (verteilt) ist ein technisches Anliegen, das im Bereich des Teams gilt und bedeutet, dass das Produkt in einer ausgewählten Umgebung eingeführt wurde. Dabei haben verschiedene Umgebungen eine unterschiedliche Benutzer-Communities: Produktion, Testumgebung und Integrationsumgebung.
5 User Monitoring & Live Incident Fixing
Wo bist du auf diesen fünf Schritten? Und was fehlt dir für den nächsten Schritt? Im Kurs «Professional Scrum Developer» zeigen wir anhand eines praktischen Beispiels drei Tage lang, wie man das macht.