The Project Team Is a Product-Development Team

You may think you have a project team or a feature team. A feature team can deliver features without depending on anyone else across the organization.

One way to make sure your team can deliver features is to think of your team as a product development team. When people think about product development instead of projects, they often realize that they need other skills and capabilities (possibly in the form of other people) on the team.

What kind of product do you have?

If you have a product with a database, you need people with database skills on your team. You might need database administration or data modeling skills. If your product includes user documentation, you might need the skills for creating that documentation.

What if your product is based on performance or reliability? You might need architecture or design leadership skills. (I prefer that the team learn how to assess performance or reliability or any other system quality by itself, without needing an external architect or designer.)

Because your product and organization are unique, I can’t tell you exactly who should be on your team. For example, all projects need project-management skills, but your team might not need a specific project manager. I do recommend your agile team have a full-time product owner with sufficient time to dedicate to the team.

Product owner is a Scrum term. And because it’s so pervasive in the industry, I’ll use it here to describe the one person who interacts with the team to create and rank the backlog.

Your team might also benefit from a coach, especially if the team is new to agile techniques. Agile approaches require people to change their mindsets and culture. Many people find a new culture a challenge: how to integrate the new thinking and the new practices?

Cross-functional teams have—at minimum—developers and testers. Think about the skills and capabilities your team needs to deliver the product often. If you don’t have all the skills and capabilities on your team to release shippable product, that’s an impediment. It might not be easy to remove that impediment. If you have cross-functional teams but not feature teams, consider measuring the time it takes for people to cycle through the features. Refer to ​Visualize Your Project’s Delays​, to understand the effects of not having feature teams.

I call everyone on the team “developers” because that helps people realize their job is product development. Some people write code that ships. Those people are software developers. Some people write code that stays. Those people are testers. Some people write documentation. Some people help the team integrate. But everyone has a single purpose: to enable the entire team to release features on a frequent basis.

If you have a nonsoftware team, you have people who develop the product (or event) and people who check to make sure the product is working properly.

Agile teams fulfill these requirements:

• The team has all the people (with their skills and capabilities) it needs to complete the work.

• The team does not change people for a given feature.

• The team has a shared goal for its project.

• The team “owns” its work. Members commit to their work and they own their artifacts, including the code and tests.

• The team does not change people inside an iteration.

• The team is stable, so the people can learn to work together and can learn their product area(s).

• If the team uses iterations, no one changes what the team commits to for that iteration.

Your feature team needs enough product developers and product testers to maintain technical excellence as it delivers working product frequently. Who you need depends on the kind of product you are working on.

Joe asks:

Do I Need to Have Stable Feature Teams?

If your organization is based on resource efficiency, you may have trouble convincing your management that you need to have stable, cross-functional teams to release features. However, the more you change team composition, the more the team will revert to forming or storming. (See ​Keep Teams Together​, for more information on forming and storming.) It takes time for people to learn to work together and trust each other. The more you change team composition, the more each feature costs.

If you have cross-functional, component teams, someone or some team still has to integrate work so that you can release features. You will incur a cost of waiting for the experts you need.

Stable, cross-functional feature teams that work through the architecture can develop and release features faster than any other team.