Traditionelle Anforderungsworkshops ohne Beteiligung der Entwicklung erfüllen den heutigen Time-to-Market-Anspruch nicht mehr. Mit dem vor einigen Jahren eingeführten User Story Mapping wurde das immerhin schon einmal besser. Was ist aber, wenn das Grundverständnis der Fachdomäne im Team noch nicht hergestellt ist, sodass das Story-Schreiben schwerfällt? Hier kann Event Storming helfen, eine Workshopmethode aus der Domain-driven-Design-Familie. Fachexperten und IT-Leute verbrauchen dabei enorm viele Post-its, um ein gemeinsames Verständnis einer Fachdomäne zu bekommen.

Wenn Teams lange für dasselbe Produkt unterwegs sind, lässt die Energie nach. Die neuen Features im Backlog sind nicht mehr wirklich originell. Produktmanagement und Marketing wissen auch nicht mehr, was nach so langer Zeit jetzt Trumpf sein soll. Was alle jetzt brauchen, sind Schwung, Fokus, Selbstvertrauen und Entschlossenheit, wie in einem risikoreichen Start-up am ersten Tag. Hat Google da nicht etwas Neues für? Na klar: Design Sprints!

Softwareentwicklung ist nicht Fertigung, das wissen wir. Es geht ums Finden von Rezepten – nicht ums Kochen nach Rezept. Teams verwenden daher gerne Taskzettel auf einem Board, das in generische Spalten wie „To-Do, Doing, Done“ eingeteilt ist. Das lässt ihnen die kreative Freiheit, die sie brauchen. Doch müssen wirklich bei jeder Story, die umzusetzen ist, die Tasks neu erfunden werden? Dadurch entgehen den Entwicklungsteams Selbstreflexion und Optimierungsmöglichkeiten. Mit dem richtigen Maß an Standardisierung geht das besser!

Sagen wir, Sie sind Gründer eines erfolgreichen Start-ups. Mit drei Freunden zusammen haben Sie die erste Version Ihrer Software geschrieben. Sie haben inzwischen genügend Kunden, und das Geld kommt herein. Großartig! Doch was jetzt? Sie wollen Ihre Codebasis auf jenseits von 100 000 Zeilen skalieren, und Ihre Teams sollen auf mehr als zehn Leute wachsen, richtig? Welche Hindernisse dann zwangsläufig auftauchen und was Sie tun können, um solides Wachstum zu ermöglichen, darum geht es in diesem Artikel.

Agile Teams pochen darauf, und Manager können es schon nicht mehr hören: Selbstorganisation. Kaum ein Organisationskonzept wird so missverstanden wie dieses. Stolze agile Teams verbitten sich Mikromanagement. Führungskräfte zweifeln und sagen „Ja, schön, aber bei uns funktioniert das ja sonst nicht!“ Dabei kann mit ein paar Vereinbarungen alles so einfach sein. Der Artikel zeigt Ihnen, was Selbstorganisation ist und wann sie funktionieren kann. Leser erfahren, wie Teams und Management gemeinsam System in die Sache bringen, sodass sich die Menschen im Alltag wirklich auf die Arbeit konzentrieren und der Kreativität freien Lauf lassen können.

Nicht alle Arbeit ist gleich dringend. Dem lautesten Kunden Vorrang zu geben, kann richtig oder falsch sein. „Der Product Owner wird’s schon richtig priorisieren“, sagen manche Teams im Zweifelsfall – und machen es sich damit zu leicht. Kanban-Teams nutzen stattdessen für das Work Scheduling ein besonderes Denkmodell: Serviceklassen (Classes of Service), basierend auf Verzögerungskosten.

Der Kunde möchte schon zu Beginn einer Entwicklung wissen, wann er das Ergebnis bekommen wird: lauffähige Software, die passende Doku, entsprechende Schulungen etc. Setzen die beteiligten Teams die Kanban-Methode ein, verfügen sie bereits über eine aktuelle Basis von Messdaten bezüglich ihrer eigenen Leistungsfähigkeit. Zu den meistbenutzen Messgrößen im Kanban-Umfeld zählen Time in Process, Work in Progress, Throughput sowie Queue Sizes.

Der Projekterfolg hängt viel stärker von den am Projekt beteiligten Menschen und den Rahmenbedingungen ab als von den eingesetzten Technologien. Erfolgreiche Projektleiter und Softwarearchitekten haben ein Gespür für die Menschen, mit denen sie Projekte machen, und erreichen mit ihnen gesteckte Ziele. Was erfolgreiche Anführer gemein haben, worauf es in der Zusammenarbeit ankommt und wie man selbst so etwas erlernen kann, stellt dieser Artikel vor.