Scaling a Development Team
Read the blog post by Adam Wiggins. He talked about the experience at his company on how to scale a team. TL;DR is no silver bullet development model and the model shall change as the team size scales.
Stage 1: Homebrewing
- 2-4 guy working in a garage
- easy communication and coordination
- self-directed generalist working on everything
- single chat channel and single (unclassified) mailing list
- no need for bug-tracking, a complete picture of the project is in everyone’s brain
- target for minimum viable product
Stage 2: First hires
- 5-9 person
- ad-hoc coordination: overhear everything from each other
- iteration planning: start having Monday meetings, big to-do list on whiteboard, system for task-assignment
- bureaucracy is definitely counter-productive
- single chat channel and mailing list still works
- everyone is still a generalist, but have a common focused goal
- in search of a scalable business model
Stage 2.5:
- 10-15 developers, many startups have been killed here
- people start to spend most of their time on iteration planning and meetings
- bored to go through laundry lists of details on other people’s work
- need to break down one team into smaller target teams
Stage 3: Breaking teams
- the art: Draw the fences in the right place
- need a well-defined sphere of authority and clear interfaces to other teams
- a team should have maximum autonomy and have their vision and direction
- needs no permission or information from other teams unless a feature/bug across team boundaries
- shall have a product/market fit, and have found the company’s meaning for existence
- starts to appreciate specialization and specialists