My journey from “Agile” to “product teams”
John Cutler: Journey to Product Teams infographic
John Cutler published an infographic he called “Journey to Product Teams” in order “to describe different team structures and approaches to collaboration”.
My immediate thought was this was an interesting way to highlight differences between teams but also that what was described as “Agile” teams didn’t match what my journey was like.
The promise of Extreme Programming
In 1999, when I first learned about Extreme Programming (XP), the pattern (as in observed, not hypothetical) was an Onsite Customer working closely with programmers. The whole point of Onsite Customer was to address hand-off with requirements activities. Instead the interaction was ongoing and on-demand. Alistair Cockburn described the User Story as a “promise for a conversation”, a conversation that would occur on-demand, not up-front.
I think it would be reasonable to say that 1999-era XP did not include Opportunity Selection nor Run.
Ideal and typical ThoughtWorks Agile custom application development engagement
I started at ThoughtWorks in 2001 and stayed there until 2015. I’d describe “ThoughtWorks Agile” as an XP-influenced but distinct style.
The first engagement I was on was around production support (aka “Run”). Subsequent engagements evolved from “build master”, to configuration management, to Java development, to process consulting/coaching/training, to organisational consulting/coaching/training.
An engagement that only included one activity (e.g., requirements, design, build, test, or production support) would be considered “body shopping” and was really only for economic down times when you needed any kind of revenue OR as a foothold activity to gain influence.
The target ideal engagement was always the entire cycle from Opportunity Selection to Release (with varying degrees of interest to expand to Run).
The typical engagement was Requirements Planning to (repeated) Release. Things like Agile Inception and Continuous Delivery came out of this.
Cross-functional in-house product teams
Spotify I think is pretty typical for technology firms with the mostly autonomous, cross-functional, “you build it, you run it”, product teams, which we call Squads.
How much each Squad is involved in Opportunity Selection and Requirements Planning varies depending on context, organisational boundaries, team maturity, etc.
Over the years, I’ve had situations where I needed to address both:
- a “do whatever you feel like” interpretation of autonomy;
- unnecessary micro-management.
As Henrik described back in 2014, the target was and still is “aligned autonomy”.
I’d say for most of the time I’ve been at Spotify, the bigger opportunity has been coordinating multiple teams (aka teams of teams) rather than improving any one team. Product strategy is more at the Tribe-level then at the Squad-level. In other words, Opportunity Selection and other activities exist within a shared coordinated context and are not fully independent. Of course, as much as activities can be decoupled, the easier it is.
