What Type of Scrum Teams Do You Have?

Executive Summary

Do you find yourself in the position of having to reorient your Scrum Teams to be more feature-centric? There are three types of Scrum Teams: Backlog Teams, Component Teams and Feature Teams.  Backlog Teams predominate in today’s Agile community. I don’t believe there’s one correct team type, (as teams are people, after all), but I’ve found that teams are almost always oblivious of what’s required to transition from a Backlog team towards a Feature Team.

Scrum Team Taxonomy

In my experience, this is the standard Scrum Team maturity sequence: Backlog Team, Component Team and Feature Team. Feature Team is the most mature model and the ideal team type for product development and delivery when attainable. One excellent resource I’ve used to prepare to coach and train Scrum teams is the Extraordinary Groups/Extraordinary Teams work of Kathleen Ryan, Kevin Coray and Geoffrey Bellman. Their work and resources have been very influential in further shaping my perspective on Scrum Team types (in addition to orienting teams to evolve towards High Performing Teams.) This work has also aided me to (a) Facilitate a discussion to support team members to self-identify their team type, (b) Present options and recommendations for how to transition from one team type to the next, and (c) That a commitment to progression is a sound investment. I also frequently revisit The Nature of Software Development by Ron Jeffries. Ron’s book is a very accessible roadmap for maturing your Scrum Team type and committing to an aspirational goal of Feature Team. This is also a fun read loaded with illustrations to make Ron’s recommendations even more accessible.

Backlog Teams

One of the trends I continue to see is a bias towards “… burning down the Sprint Backlog.” without sufficient attention to product (or solution) features being delivered (or planned for delivery.) I often hear this directive from middle and senior management: “We want our teams to commit to their Sprint Backlog” even when (a) Teams are not completing their Sprint Backlogs, and (b) Feature value isn’t assessed (in the marketplace or internally, depending on what’s being developed.) These condition often lead to Mechanical Scrum during which teams iterate with a reduced Scrum lifecycle where Sprint Planning becomes an outcome of the most recent Sprint Backlog. What’s really needed is consistent use of the Product Backlog, the product or solution vision, the strategic release plan and Product Owner inputs. These teams quickly reach a steady state of delivery (e.g., Velocity Plateau) and lose the ability to innovate. Neither ideal, nor a lot of fun.

Component Teams

Technically oriented teams (especially when technically savvy Team Leads are vocal members) often focus on product (or solution) component development. These are very often teams that are focused on an internal-facing solutions and developing or enhancing capabilities based on component knowledge and expertise (too often independent of features.) While Scrum Teams should be egalitarian and leaderless (from a Command and Control perspective), there are still many engagements during which a veteran (employee) team member sets the agenda for Sprint Planning based on their vision for component development and integration needs. In these situations, a Product Owner can feel powerless as they often lack detailed technical expertise and are reluctant to challenge the Team (or Technical) Lead for fear of alienating the whole team. These conditions also often lead to Mechanical Scrum at even lower levels of Velocity, a visible lack of Enthusiasm and not much fun. The majority of team members wait on their Team Leads to define the future for them (versus feeling empowered to collaborate on defining the future in concert with their Product Owner.) Team members on these teams quickly become disillusioned about the potential Scrum offers, too

Feature Teams

The Scrum Team Type we hear about most often at Scrum Training is the Feature Team. Listening to your Scrum Trainer, it seems simple enough to enumerate the features you’re aware of and refine them sufficiently to form an initial Product Backlog heading into initial Release Planning (ideally) and Sprint Planning. Product Visioning and Strategic Release Planning are recommended preludes to forming the initial Product Backlog. What’s especially helpful when you commit to working as a Feature Team (planning, developing and delivering) is that everyone is speaking, thinking, planning and delivering (in terms of) features. Easily said (and typed…), I almost never see it even on “mature” Scrum Teams. Why? One reason is that teams are working primary in text-based tools for planning, development and delivery. It’s challenging to abstract User Stories into Epics that correspond to demonstrable features when everything is expressed in User Story Syntax (if you’re fortunate), or, most often, truncated declarative sentences and sentence fragments whose significance outside the core team is seldom clear. There’s almost always a modeling gap that could be resolved with the use of Visual Planning. The energy level of a Feature Team is visible and audible: These teams are always in motion (even when seated…) They’re always striving to see where they can add value to demonstrable features (even when a feature isn’t visible to the customer or end user.)

Recommendations

1. Use your Retrospectives to assess where you are as a Scrum Team with respect to the three Scrum Team Types. There’s a reason the word Inspect is used so frequently in Scrum.
2. Consider adopting one or more Visual Planning tools and techniques to guide your higher-level planning (e.g., Product Visioning and Strategic Release Planning, to start) and model your future visually versus textually.
3. Don’t become steady state (in any dimension: Collaboration, Delivery, Quality, etc.) Always discuss and experiment with emerging and proven methods for Continuous Improvement.
4. Speak Feature Speak: Form the habit of planning, developing, delivering and reflecting per your feature set (versus your Sprint Backlog.)

Key Resources

• Extraordinary Groups, Geoffrey Bellman and Kathleen Ryan
• Extraordinary Teams, Kathleen Ryan, Kevin Coray and Geoffrey Bellman
• The Nature of Software Development, Ron Jeffries
• The Scrum Guide, Jeff Sutherland and Ken Schwaber