The Importance of Core Teams in Product Development

From Marty Cagan to Mike Cohn, we have heard the differences between Scrum, Feature and Product teams. But is not that common to hear why Core teams (or Core Services teams) are also foundational to the success of any large development project.

The foundation of Core teams emerged from principles put forth by Edward Demmings in the 1950s, which are as valid today as they were then. Toyota still operates under these principles, and Alan Kay, the Popendiks, and the Agile manifesto signers all saw the relevance of those principles being translated into the way we build digital products. The principles are all about eliminating waste and maximizing throughput while aiming for streamlined value-generation.

Following that train of thought, when we create products to solve pervasive problems and for which customers are willing to pay, we need to be overly sensitive about time-to-market—as noted by the Pragmatic Institute. That’s because pervasive problem0s will evolve, mutate, or be solved by someone else, which translates into the need to increase the agility of Scrum, Feature and Product teams to hit the market at the right time.

In order to increase team agility, we need to follow Demmings on the principle of eliminating waste. Programmatically speaking, this means writing not only SOLID/OOP/OWASP based code, but also making sure we create architectures that promote reusability. Reusability is where a Core team comes into the spotlight

Maintaining Agility, Coordination and Downstream Dependencies

Any product that has two or more teams working at the same time requires collaboration and integration. If we are in the Agile world, it could be as simple as having a Scrum of Scrums, or as complex as a full Scaled Agile Framework (SAFe) implementation. The main reason for having teams communicate with each other is to avoid duplicating efforts, reduce cross-team impediments, and leverage one team’s output into the other teams’ input in relation to downstream dependencies.

Now let’s scale that into 5, 10, or 20 different teams working on the same product. How can you then continue to maintain the same level of agility, coordination and downstream dependencies?

One of the answers comes from identifying the core services, areas, and portions of a product that are consumed by multiple portions of a solution, and then assigning those to a Core team and for other teams to consume. In that way, the Core team needs to focus not only on the desired business (as would any other team), but also on the specific requirements of the Scrum, Feature, and Product teams. In other words, the user persona for a Core team might be another team or a requirement that will be executed by another team.

Examples of Core Teams in Action

The easiest example of a Core team in action would be an Authentication Service that will be consumed across the product and by most of the other teams. Given that most endpoint calls will require validation for authenticated users and their valid credentials, it makes perfect sense for the Core team to own authentication and serve the rest of the teams on their authentication requirements.

Ideally, the Core team should have its own product representative to funnel the requirements from the different stakeholders, including the Scrum, Feature, and Product teams. The representative should be a technical product manager, not a traditional product owner.

The main reason for this is that most (if not all) implementations of a Core team will end up being endpoints or services for other teams to consume. The expected outcomes, roadmap, and backlog are technical and driven by the functional requirements that other Scrum, Product and Feature teams will work on.

Other good examples of Core teams in action and their assigned services include digital content products, which could have a Core team for the video player. In the automotive sector, digital marketing products might have a Core team for the car valuation algorithm. Organizations just need to be careful about not confusing a Core team to split teams per stack or per horizontal backlogs, e.g. a back-end team vs a front-end team. That is not a Core team.

Key Core Team Attributes

A key attribute to strive for when building a Core team is to set it up as either product-focused or feature-focused. Also look to bring in the required segregated expertise to work on vertically-sliced backlogs—meaning each story represents a product backlog item that adds value by itself. The deliverables of the Core team should supplement the deliverables of a Product team while always keeping in mind the reusability for other portions of the product for other teams to consume.

It also helps to recruit Core team members that have in-depth knowledge of your product’s technical and functional requirements. This ensures their deliverables will produce an impact on several portions of the product. In addition, members should view being part of the Core team as an earned position; the team should be seen as trusted technical advisors for other teams and should be the first candidates to consider when assembling new tribes for cross-collaboration (from Spotify’s model of Squads, Tribes & Chapters).

3Pillar Global has robust experience implementing Agile development environments at scale for large product implementations. Setting up a Core team is just one of the best practices to consider among many others we also use in our daily work. Contact us to learn more.