Seite 2: Pro & Contra

Inhaltsverzeichnis

Leichtgewichte mit Kanban

Welcher Prozess für ein Projekt ideal ist, hängt von den Eigenschaften ab, die es charakterisieren. Wie hoch ist die Komplexität des Projekts? Wie viele Entwickler und Teams arbeiten an dem Produkt? Befindet es sich in der Wartungsphase oder passt man hauptsächlich für Kunden an?

Viele Softwareprodukte sind klein und unkompliziert. Es sind nur drei oder vier Entwickler beteiligt. Für die Projekte kann Kanban viel bewirken. Das Kanban-Board ist der kleinste gemeinsame Nenner, über den sich das Team synchronisiert. Wenn alle im gleichen Büro sitzen, ist es nicht notwendig, eine fest vorgegebene Besprechungsabfolge einzuhalten. Man spricht sowieso miteinander. Für zusätzliche Prozessabläufe, wie Iterationen mit fest definierten Zeitboxen, kann sich jedes Team dann gemeinsam entscheiden.

Wartungsprojekte haben eine Phase erreicht, in der das Produkt nur noch bei Bedarf weiterentwickelt wird. Es ist meist nicht möglich, einen kontinuierlichen Fluss an Tasks zu erzeugen. Die Mitarbeiter arbeiten vielleicht nur teilweise an solch einem Projekt. Kanban ist in dem Fall eine gute Lösung. Geschwindigkeit spielt bei der Konstellation normalerweise keine Rolle. Scrum erscheint für die Projekte ein überdimensionierter Prozess zu sein. Das erzeugt Muri und das ist dann wie das berühmte "mit Kanonen auf Spatzen schießen". Der Prozess selbst wäre eine Verschwendung.

Hohe Komplexität mit Scrum bewältigen

Für Projekte mit hoher Komplexität, bei denen mehr als vier Softwareentwickler beteiligt sind, eignet sich Scrum besonders gut. Das liegt daran, dass Scrum einen ganzen Satz an "Ritualen" definiert, der den Prozess strukturiert. Es ist einfacher, alle Teammitglieder davon zu überzeugen, regelmäßig Meetings abzuhalten und sich zu synchronisieren, wenn für sie ein festgelegter Satz Spielregeln im Raum steht. Softwareingenieure empfinden Meetings zu Recht oft als Zeitverschwendung. Die Treffen in Scrum sind jedoch so bemessen, das sie mit Zeitlimit versehen sind und deswegen nicht ausufern. Auch ist klar definiert, welche Aufgaben in welcher Sitzung zu bewältigen sind. Das schafft Struktur, und damit kann normalerweise jeder leben. Vor allem die kurzen täglichen Scrum-Meetings sorgen für regelmäßigen Informationsaustausch. Das fördert die Teamzusammengehörigkeit. So verwundert nicht, dass sich Teams auf solche regelmäßigen Treffen und starren Zeitfenster einlassen, wenn es heißt: "wir machen Scrum".

Besonders für die verteilte Produktentwicklung eignet sich Scrum. Bei ihr gibt es täglich ein "Scrum of Scrums", in denen sich die Teams untereinander synchronisieren. Es gibt ein gemeinsames Product-Backlog und ein gemeinsames Produkt. Die Verteilung von Teams optimiert die Skalierbarkeit von großen Projekten.

Fazit

Scrum und Kanban eignen sich gut für Projekte mit unterschiedlicher Komplexität und Anzahl beteiligter Personen. Hinzu kommen der Reifegrad eines Teams und die besonderen Vorlieben aller Beteiligten. Kanban-Fans möchten sich nicht gerne auf ein so umfangreiches Regelwerk wie Scrum einlassen und mehr selbst definieren. Für eingefleischte Scrum-Anhänger sind genau diese festen Rituale das, was Scrum ausmachen. Je mehr Personen und Teams an einem Projekt beteiligt sind, desto mehr verhelfen feste Spielregeln zu einem geordneten Prozessablauf.

Uta Kapp
ist freiberufliche IT-Beraterin und systemischer Coach. Mit einer Kombination aus Fach- und Prozessberatung für Softwareprojekte hilft sie Entwicklungsteams bei der Bewältigung der ständig steigenden Komplexität. Hier kommen agile Softwareentwicklungsmethoden wie Scrum und Kanban zum Einsatz.

Jean Pierre Berchez
ist Geschäftsführer der HLSC UG und beschäftigt sich seit mehr als 15 Jahren mit den Themen Projektmanagement, Software Engineering und objektorientierte Softwareentwicklung. In den letzten Jahren liegt sein Interesse auf den Themengebieten agile Entwicklung mit Schwerpunkt Scrum sowie "Collaborative" Software Development. Er organisiert unter anderem den Community-Event "Scrum-Day" in Deutschland.

Literatur

1. Henrik Kniberg, Mattias Skarin; Kanban and Scrum – making the most of both; C4Media Inc., 2010
2. Marion Eickmann; Geregelte Selbstbestimmung; Ein Plädoyer für agile Softwareentwickung mit Scrum; iX Special "Programmieren heute" 1/2010, S. 82
3. Markus Andrezak, Arne Roock, Henning Wolf; Gedämpfte Schritte; Evolutionäre Entwicklung mit Software-Kanban; iX 6/2010, S. 108
4. Bernd Oestereich: Gedanken zur Sprache in Scrum, Blog-Eintrag auf heise Developer

(ane)