I'd build agile teams around outcomes and flow, not around a matching set of sticky-note rituals.
Structural choices I'd weigh
| Shape | When I'd use it |
|---|---|
| Generalists | Small surface area; need end-to-end ownership |
| Specialists | Deep domains with clear interfaces |
| Hybrid | Most real products—specialists + glue people |
Habits that matter more than labels
- Stable team membership long enough to learn
- Clear product goal per sprint/increment
- WIP limits so work finishes
- Definition of done that includes quality, not only “merged”
- Retros that change the system, not vent only
I'd avoid heroic individuals as the scaling plan. Hire for collaboration and judgment; teach the framework lightly.
A Technical PM Certification helps PMs partner on team design with eng leads.
More in the newsletter.