Are your agile teams product or project teams?

One of the expectations associated with the adoption of agility may be that all members of an agile team consider their team’s business goals to be their own. And because team members own these goals, they also proactively participate in achieving them. You might think, “Nice idea, but this is hardly going to work for us.” And no wonder, such a change can sometimes seem like science fiction for many beginning agile teams. 

Why is it so complicated? Because teams in a company do not live in a vacuum, even without history. Their behavior is influenced by a number of company settings and rules. And very often, starting teams stay in exactly the same setting as they were before they started to deal with agility.

If you want to change the culture, you need to start by changing the system in which your teams live. People have adapted to the system in your company, and it influences their behavior and culture in teams. With the current team setup, organizational structure and external influences, a change towards agility may sometimes seem unrealistic to people. You’ll get different results from a project team that was perfectly supportive of project work and different results from a product team that’s designed to support agility. Each of them was designed for a different way of operating. In today’s article, I assume that the properties of project teams are known to all of us, because they have been used in many companies for many years. So let’s take a further look at the product team and where the differences are.

Basic features of the product team

The product team has several basic features:

• It is long-term
• It is built end to end
• People belong to this team and feel at home here. And that’s why they own the goals of this team
• It is product focused
• Team members use team goals

These qualities are the basis for the development of an agile team culture. If you decide not to use any of the product team features, you need to realize that it will somehow be reflected in the resulting team culture you are building. 

Agility often helps you discover places where there is a problem, but it usually does not tell you how to solve it. The first solution that usually comes to mind is to hide the problem and remove what alerted you to the specific problem. Although it sometimes hurts and seems the easiest, look for the real cause of the problem instead. In doing so, it can help you answer the questions you will find below. Think about knowing these answers, what it will do to your team’s motivation to achieve the change you’re planning. Even if your team is a senior, it sometimes helps to get back to the basics about the product team. It may help you find a way to solve the problem, just as it helps us and the teams we work with in transformation.

Question	Project team	Product team
Is your team long-term or short-term?	Short-term (given by the end date of the project)	Long-term
What delivery/content is your team focused on?	They change by project, products vary by project	Long-term product focus
What deep product expertise does your team have?	We have an overview across multiple products, but after more projects we forget what was solved before. Product-specific expertise is not so deep	Deeper knowledge of the product, but we have less overlap across more products
How stable is the composition of your team?	It changes according to the needs of the project	Stable team dedicated to the product
Who takes care of your operations and small enhancement?	We pass it on to another team	What I have developed, I also support in the production environment
What type of goals do your teams use?	Individual	Team
Do you know in advance the scope on which you will be working?	Scope is known in advance	Dynamically changes
Is the team member’s allocation full or partial?	Full or partial	Full
What motivates your team?	Deliver successfully project and customer feedback	Long-term product prosperity and customer feedback
Which team do I feel at home in? How will this affect my priorities regarding the team’s goals?	In a team managed by a line manager, from which I am borrowed. The priority for me are the goals of the line.	In the product team, priority goals for me are the goals of the team where I am.

Finally

You will probably think of a lot of other differences as you read these lines. Keep in mind that every business is different and that the result of the same setup may vary from company to business. Likewise, the intent of where you want to go with your teams may differ. And if you want to help set up your teams, don’t hesitate to contact us.