The limitations of Scrum framing and what you might use instead.
“Teams” over “Scrum Teams”
Calling teams “Scrum Teams” implies that effectiveness is defined by Scrum. Spotify shifted to “Squad”, at least partly, as a way to be clearer that teams should not limit themselves to Scrum patterns and practices. Outside of Spotify itself, I’m wary of suggesting “Squad” as an alternative to “Scrum Team”, mainly because of a general tendency to blindly copy Spotify. “Crew” is an alternative from the Cynefin community but it’s fairly niche. Instead, I’d generally suggest keeping it simple with “Team” and emphasize desired team principles instead, for example:
- Clear missions aligned to a larger strategy;
- All the capabilities and tools to fulfil the mission autonomously;
- Clear ways of working amongst themselves and with others outside the team;
- Fewest number of people to accomplish the previous
See also
- Key practice: Aligned, autonomous cross-disciplinary teams. | by Jason Yip | Apr, 2023 | Medium
- Empowered Product Teams — Silicon Valley Product Group : Silicon Valley Product Group (svpg.com)
- Team Topologies
- My journey from “Agile” to “product teams” | by Jason Yip | The Startup | Medium
“Continuous Delivery” over “Sprints”
“Sprint” combines two distinct concepts into a single timebox (typically 1–4 weeks): when changes are released, when certain planning and review meetings occur.
These days, the best software product development teams drive toward Continuous Delivery, that is releasing on-demand, not on any fixed timebox. It may still be useful to have a regular cadence for planning and review meetings, but this is somewhat decoupled from the frequency of releases.
Even with Continuous Delivery, I believe that it is still useful to do “release planning” to identify larger coherent product improvements over a period of time (e.g., 4–6 weeks). Calling these “releases” is weird with Continuous Delivery but I’m not sure what the better term is yet. At one point, Spotify called these Priorities and also Bets (distinct from larger Company Bets). Basecamp calls this a “6-week cycle”. Arguably, the original purpose of the term “Sprint” was around a larger coherent product improvement (aka the Sprint goal) but it’s now confusing to use it for this purpose as most people will assume you’re referring to a fixed timebox.
“Product Managers” over “Product Owners”
“Product Owner” is only used by Scrum while “Product Manager” is the term used by the broader product management community.
I’m willing to bet that you’ll find both more competent practitioners and better learning references using “Product Manager” rather than “Product Owner”.
Competent Agile practitioners over competent managers over “Agile Coaches” over “Scrum Masters”
“Scrum Master” both implies that effectiveness is defined by Scrum and given the dynamics of the certification industry, tends to indicate a low-level of capability.
Originally Spotify shifted from “Scrum Master” to “Agile Coach” to make it clearer that teams did not need to limit themselves to Scrum patterns and practices. However, I don’t even consider this the best approach.
For the best teams I’ve been on, every team member was highly competent and we all kind of coached each other. The next best I’ve seen, the Engineering Manager and/or Product Manager were/was highly competent and coached the team. The next best after that, I acted as an Agile Coach to help Engineering Managers and/or Product Managers more effectively coach teams. These days, I generally don’t think it’s worthwhile to have direct team coaches or “Scrum Masters” unless teams are just starting out OR the team is very high-leverage AND the direct coach is extremely capable.
Product strategy and maps over “Product Backlogs”
“The Product Backlog is an emergent, ordered list of what is needed to improve the product.”
An emergent, ordered list is a fairly poor way to reason about what’s needed to improve a product.
Instead of “Product Backlogs”, use maps (e.g., product roadmaps, User Story Maps, Impact Maps, Opportunity Solution Trees, Thoughtful Execution Framework, etc.) and have an actual product strategy (e.g., DIBB).
“Up next” over “Sprint Backlog”
“The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).”
“Sprint backlog” implies that fixed timebox Sprints are being used. If instead, you’re operating in a more of a continuous flow, then you only need enough “up next” to feed the flow, replenishing as required.
