Kurze Antwort: Möglicherweise, wenn es nicht an anderer Stelle ein dickes Problem gibt, und wenn man es richtig macht. Eine Vergrößerung des Teams bzw. die Hereinnahme weiterer Teams in das Projekt erfordert zunächst einmal eine tiefgehende Analyse des Ist-Zustands. Bleibt diese aus, und es regiert das Prinzip Hoffnung, dann ist es möglich oder gar wahrscheinlich, dass mehr Mitarbeiter entweder garnichts bringen oder die Sache sogar noch weiter verlangsamen.
In fast jeder Publikation zum Thema Scrum oder Agile Softwareentwicklung werden Sie lesen, dass ein größeres Team oder mehr Teams keinesfalls eine schnelle Steigerung der Entwicklungsgeschwindigkeit nach sich ziehen. Ich habe ein großes Problem mit dieser äußerst allgemeinen Darstellung. Eine Verstärkung des Teams kann durchaus auch kurzfristige positive Folgen haben, aber zum einen muss das nicht der Fall sein, weil die Velocity von vielen Faktoren abhängt, zum anderen kann man dabei sehr viele Fehler machen.
Man neigt dazu, mehr Kollegen an das Projekt zu setzen, wenn es langsamer voran kommt, als man ursprünglich geplant hat, oder man möchte den Releasetermin aus wirtschaftlichen Gründen vorverlegen, weil vielleicht ein Mitbewerber ein Konkurrenzprodukt für einen bestimmten Termin angekündigt hat. Es gibt viele Dinge, die ein Management oder eine Geschäftsleitung dazu bringen können, über eine Verstärkung des Teams nachzudenken. Diese Gründe lassen sich grob in zwei Klassen einteilen:
1. Man ist langsamer als man erwartet hat
2. Eigentlich ist die Geschwindigkeit in Ordnung, aber man möchte schneller sein
Zwischen diesen beiden Dingen liegt ein erheblicher Unterschied. Der ersten Klasse von Gründen sollte keinesfalls sofort damit begegnet werden, mehr Leute ins Team zu holen. Wenn man langsamer vorankommt, als man erwartet hat, dann muss ich mir zuerst die Frage stellen, woran das liegt. Wurde die erwartete Entwicklungsgeschwindigkeit einfach zu hoch angesetzt? Wenn ja, warum? Wurden Hindernisse nicht rechtzeitig erkannt oder nicht antizipiert, die das Team aufhalten? Sind unsere Kollegen nicht so erfahren, wie wir gehofft hatten? Klappt die Zusammenarbeit zwischen Team und Product Owner? Klappt die Zusammenarbeit zwischen Product Owner und Stakeholdern? Wenn Sie Hilfe bei der Analyse brauchen, fragen Sie mich.
Ich kann und will jetzt nicht alle Möglichkeiten aufzählen. Wichtig ist lediglich, dass Sie wissen, dass es viele Gründe für ein Stocken der Entwicklung gibt, denen man mit einer Verstärkung des Teams nicht begegnen kann. Eine eingehende Untersuchung ist also unerlässlich, wenn Sie nicht wollen, dass Ihre (teuren) Bemühungen komplett verpuffen.
Gehen wir aber davon aus, die Zusammenarbeit zwischen allen Beteiligten klappt gut, die Dinge greifen vernünftig ineinander, wir haben ein Team aus fähigen Kollegen, wir haben lediglich die Entwicklungsgeschwindigkeit falsch eingeschätzt. Ich ignoriere einfach mal die Frage, warum wir so daneben gelegen haben, und komme zum Punkt: kann ich die Entwicklungsgeschwindigkeit steigern, wenn ich das Team vergrößere, und alles Andere funktioniert gut?
Im Prinzip ja, aber selbstverständlich nur bis zu einem gewissen Grad, und auch nur, wenn Sie die richtigen Kollegen finden.
Eine langfristige Steigerung der Entwicklungsgeschwindigkeit ist unter den richtigen Voraussetzungen(!) immer möglich, wenn das Team vergrößert wird. Wir wissen, dass es den Prozess der Teambildung gibt. Wir wissen, dass sich neue Kollegen erst einarbeiten müssen. Es ist zu erwarten, dass die Entwicklungsgeschwindigkeit nur langsam steigt, oder anfänglich überhaupt nicht steigt oder sogar leicht sinkt. Das ist davon abhängig, wie erfahren der oder die neuen Kollegen sind, wie gut das Team aktuell zusammenarbeitet, und wie das Projekt aufgebaut ist. Der Einstieg in ein neu zu entwickelndes Projekt mit sauberer Architektur ist selbstverständlich wesentlich einfacher als in das berühmte »natürlich gewachsene« Chaos.
Wir wissen ebenfalls, dass man ein Team nicht endlos vergrößern kann. Ab ungefähr 10 Mitgliedern fängt es an, langsam ineffizient zu werden. Die Meetings werden zäh und dauern immer länger. Es gibt immer mehr Gesprächsbedarf. Es ist ebenfalls eine Frage, ob die Architektur der Software es verträgt, wenn viele Personen gleichzeitig am Code arbeiten. Auch das muss geklärt werden. Lässt die Software es zu, wir kommen aber langsam an die »natürliche« Teamgrenze heran, kann man darüber nachdenken, die Anzahl der Teams zu erhöhen. Was dann jedoch alles zu bedenken und zu beachten ist, ist Stoff für einige weitere Blogeinträge. Ich möchte jetzt lediglich sagen, dass Sie sich diesen Schritt gut überlegen sollten.
Aber zurück zur Frage, ob man die Entwicklungsgeschwindigkeit auch kurzfristig steigern kann. Das ist, wenn die Voraussetzungen stimmen, durchaus möglich, wenn Sie die richtigen Kollegen finden. Ein junioriger Kollege birngt kurzfristig nichts. Der muss noch viel zu viel lernen. Ein sehr erfahrener Softwareentwickler kann sich schnell in ein Projekt einfügen, wenn Product Owner und Team die passenden Aktivitäten finden. Wenn das Team gut funktioniert, dann wird ein neuer Kollege, dem man nicht viel beibringen muss, die Entwicklungsgeschwindigkeit der anderen nicht stark beeinflussen. Ein gut funktionierendes Team kann neue Mitglieder (wenn die Chemie stimmt) sehr schnell integrieren. Der Effekt der Verlangsamung durch die Teambildung ist nicht so groß, wie er gelegentlich beschrieben wird, außer Acht lassen darf man ihn dennoch nicht.
Die größte Hürde ist es oftmals, dass man neue Kollegen nicht sinnvoll einsetzen kann, weil es keine passenden Anforderungen gibt, die einen schnellen Einstieg ermöglichen. Noch schwieriger ist es natürlich, wenn man an »alter« Software arbeitet. Der nächste wichtige Punkt, auf den Sie achten sollten, ist also, dass Product Owner und Team Aufgaben finden, die von einem erfahrenen Entwickler erledigt werden können, der das Projekt noch nicht gut kennt. Dazu sollten sich Product Owner und Architekt oder Lead Developer oder ein erfahrener Kollege einmal zurückziehen und im Backlog die Anforderungen für die nächsten Sprints durchgehen. Einige werden genauere Kenntnisse der Architektur erfordern, aber sehr oft gibt es auch Anforderungen in »Randbereichen«, die ein erfahrener Kollege ohne große Vorbereitung erledigen kann.
Selbstverständlich bleibt es erforderlich, dass der Architekt dem neuen Teammitglied Dinge erklären muss. Selbstverständlich bleibt es nicht aus, dass er seine Kollegen gelegentlich fragen muss. Dennoch kann ein erfahrener Softwareentwickler, wenn das Team funktioniert, wenn das Projekt es zulässt, wenn der Product Owner den richtigen Einstieg findet, nach zwei bis vier Wochen eine spürbare Steigerung bewirken.
Erwarten Sie keine Wunder, recherchieren Sie zuvor gründlich, finden Sie den richtigen Kollegen. Bei einem funktionierenden Team, bei einem funktionierenden Projekt, bei einem guten Product Owner sollte eine Steigerung der Entwicklungsgeschwindigkeit schnell möglich sein.
