So strukturieren Sie ein Softwareentwicklungsteam

Haben Sie ein Squad-System in Erwägung gezogen? Der immer ausgezeichnete Henrik Kniberg hat einen Artikel , den Sie vielleicht nützlich finden, wie dieses System bei Spotify verwendet wird.

Das Grundprinzip ist wie folgt:

1. Vertikale Multi-Skilled-Teams (Produkt, Entwicklung, Design) arbeiten an einem einzelnen Produkt oder Bereich der Produktentwicklung (z. B. Infrastruktur, Kundenfeedback) – diese werden als Squads bezeichnet .
2. Horizontale kompetenzbasierte Gruppierungen (z. B. PHP-Entwickler, Front-End-Entwickler) quer durch die Squads – diese werden als Chapters bezeichnet . Jeder hat einen Chapter Lead, der (normalerweise) die Linienverantwortung für jeden in seinem Chapter übernimmt.
3. Spezielle Interessengruppen (z. B. Agiles Projektmanagement, Testen) sind sowohl Chapter als auch Squads übergreifend – diese Gruppen sind als Gilden bekannt und jede hat einen Gildenleiter.

Es gibt einige Ähnlichkeiten mit einem Matrix-Management-System , die Sie vielleicht auch untersuchen möchten.

Haftungsausschluss : Ich habe das Squad-System nicht verwendet, ich denke nur, dass es ein guter Ansatz für Sie sein könnte!

TL;DR

TANSTAAFL. Wenn Sie skalieren möchten, müssen Sie weitere Teams hinzufügen. Wenn Sie jedoch weitere Teams hinzufügen, müssen Sie die zusätzliche Komplexität und den damit verbundenen Kommunikationsaufwand bewältigen.

Direkte Kommunikationskanäle skalieren schlecht. Die Formel wird allgemein als N(N-1)/2 ausgedrückt . Wenn Sie kein Projektmanagementmodell haben, das diese kritische Tatsache der Kommunikationskomplexität berücksichtigt, werden Sie große Probleme bei der Skalierung haben.

Teaming-Optionen

Scrum-Teams sind Projektteams . Während gute Teams oft zusammenbleiben, um an nachfolgenden Projekten zu arbeiten, um den Aufwand für die Bildung und Normierung mit einer neuen Gruppe zu vermeiden, ist dies keine Rahmenanforderung. Wenn Sie jedoch mehrere gleichzeitige Projekte haben, haben Sie unabhängig von Ihrer gewählten Methodik ein Kapazitätsproblem .

Aufgabenwechsel

Task Switching ist immer ein Problem. Selbst wenn Sie sich für eine andere Methodik als Scrum entscheiden, müssen Sie die Arbeit dennoch so paketieren und priorisieren, dass jede Arbeitseinheit das kognitive Umschalten minimiert. Das bedeutet, dass es weniger optimal ist, einen einzelnen Entwickler zu bitten, an verschiedenen Aufgaben für verschiedene Projekte zu arbeiten (selbst wenn die Aufgaben sequenziert und nicht pseudoparallel sind), als dem Entwickler zu erlauben, jeweils an einem Kundenprojekt zu arbeiten.

Akzeptieren Sie Arbeit basierend auf der Kapazität

Das eigentlich zugrunde liegende Problem ist, dass Sie Kundenprojekte priorisieren und Ihre Prozesse skalieren müssen, wenn Sie mehr Kapazität für mehr Kundenprojekte benötigen. Ihre Organisation sollte nicht mehr Arbeit annehmen, als verfügbare Kapazitäten haben. Die Priorisierung des Projektportfolios wird die Aufgabe der Geschäftsleitung sein, nicht die Aufgabe der Projektteams, daher betrifft Sie dieses Problem nicht direkt.

Was die Skalierung betrifft, ist ein Scrum of Scrums im Allgemeinen das richtige Werkzeug für den Job, wenn Sie ein Scrum-Shop sind. Wenn Sie eine andere Methodik verwenden, müssen Sie stattdessen die Skalierungsfunktionen dieses Frameworks verwenden. Der Punkt ist jedoch, dass die Kommunikation zwischen Teams schwieriger und komplexer wird, wenn Sie Teams hinzufügen. das ist fast axiomatisch.

Der beste Weg, den ich kenne, um das Problem des Wissensaustauschs in einer komplexen Scrum-of-Scrums-Umgebung zu lösen, besteht darin, sicherzustellen, dass die Product Owner teamübergreifende Schulungs- und Schulungsgeschichten zu ihrem Product Backlog hinzufügen. Dies bietet Möglichkeiten zur gegenseitigen Befruchtung zwischen Teams und reduziert den Siloeffekt, ohne die Natur der eng verbundenen Teams selbst zu zerstören.

Sehen Sie sich an, wie Menlo Innovations in Ann Arbor, Michigan, funktioniert. Ich denke, sie ähneln dem, was Sie zu tun versuchen.

• Ungefähr 70 Mitarbeiter, die für viele Kunden maßgeschneiderte Arbeit leisten
• Jeder paart sich, und die Paare wechseln wöchentlich - viel Wissensaustausch
• Einwöchige Sprints
• eXtreme Programming-Praktiken
• High-Tech-Anthropologie (etwas, das sie erfunden haben)
• Projekte werden aus Paaren gebildet, sodass sie nach Bedarf einfach vergrößert und verkleinert werden können

Siehe das kürzlich erschienene Buch Joy, Inc. Es wurde von Richard Sheridan, einem Mitbegründer von Menlo Innovations, geschrieben und beschreibt den Menlo Way. Sie machen auch Führungen durch ihren Laden und bieten Kurse für diejenigen an, die daran interessiert sind, die Techniken zu lernen. http://www.menloinnovations.com/

Ich habe noch nie dort gearbeitet, aber ich kenne eine Reihe von Leuten, die mit dem Unternehmen in Verbindung stehen, und ich bin ein Fan ihrer Arbeitsweise.