A key piece of every agile software development framework is the notion of a cross functional team that has all the skills necessary to deliver value on a regular basis.
These teams go by a variety of names, whether it’s a scrum team in the Scrum framework or an agile team in the Scaled Agile Framework (SAFe).
Regardless of the framework the focus of these teams seems to be on software development - building a solution - rather than the full collection of activities included with delivering a product, which includes a great deal of discovery and design.
Here’s an overview of the typical description of agile teams and an explanation of what needs to change on these teams to make them fully empowered product teams.
An agile team is a small group of people who work on the same product or portion of a product as their primary responsibility.
While most agile team members are on the team full time, there may be a few who provide specialized skill sets that are only needed part of the time. This is especially true when we explore the idea of empowered product teams.
The team is large enough to have all the skill sets necessary to create value with their product on an ongoing basis and small enough to stay nimble. This usually means that agile teams consist of 10 or fewer people.
If a team is too small, they aren’t able to complete valuable increments in short feedback cycles (usually less than two weeks).
If a team is too large they have difficulty communicating and keeping everyone up to speed resulting in slower delivery of value.
Agile teams are expected to be self managing, meaning they decide for themselves who does what, when and how.
Everyone on an agile team shares accountability - meaning that the entire team is responsible for their outcomes, not just specific individuals.
Because agile teams share accountability for their outcomes, they will often share responsibilities based on what the team needs to accomplish and the skill sets of the individual team members. You may see developers writing automated tests or product people and testers involved in discussions to determine the preferred implementation approach.
Scrum identified three main roles of an agile team: developers, product owner, and scrum master.
Most other agile software development frameworks adopted these roles as well so they have become nearly standard. In some respects that’s unfortunate because each of the role descriptions has it’s issues.
Developers are the people in the agile team that are committed to creating an increment of the product on a regular basis.
The specific skills needed by developers are fairly broad and will vary with the context of your product.
When you build a software product, you’ll want to make sure that your developers have the skill sets to cover the entire tech stack.
Your team may have developers that focus on back end or front end or you may staff your team with full stack developers.
You’ll also want to make sure that your developers are versed in good engineering practices such as continuous integration and continuous deployment so that your team can make the most out of short feedback cycles.
The creators of scrum intended the term “developers” to be a catch all term for all the people on the team who were contributing to creating an increment of your product including designers, testers, analysts, and engineers.
Unfortunately, many people interpreted the use of the term developers to mean that those other roles “don’t belong” on an agile team. This misunderstanding has led to many poorly formed teams that did not have the full skill set necessary to discover, design, develop, and deliver high quality solutions.
The product owner is the person on an agile team responsible for managing the product backlog in order to achieve the desired outcome that the team seeks to accomplish.
In order to do that, the product owner performs a variety of activities:
Identify and describe backlog items
Make decisions regarding the priority of backlog items
Determine whether a backlog item was satisfactorily delivered
Ensure transparency into the upcoming work of the agile team
The founders of scrum created the product owner role in order to address challenges that development teams had such as conflicting direction about what to build, or no direction at all.
Agile teams expect product owners to be readily available to answer their questions and make decisions and all the training around product ownership focus on the relationship between the product owner and developers.
The scrum master is the person on an agile team who ensures the team follows the processes and practices that the team agreed they would use.
In order to do that, the scrum master does the following:
Provides an environment where the team can be effective
Addresses team dynamics
Protects the team from outside interruptions and distractions.
The name scrum master was intended to indicate someone who is an expert at scrum in particular and agile in general. This role is intended to be a coach primarily focusing on the processes and practices the team uses and team dynamics.
Some organizations refer to this role as delivery lead to emphasize their responsibility of interacting with members of the organization outside the team in order to deliver the team’s product.
The role does not generally have any actual authority. People filling this role have to lead from a position of influence, often taking a servant-leadership stance.
A well functioning agile team provides a good foundation for a truly effective product team. In order to build upon that foundation you’ll need to:
Adopt the full breadth of product management
Complete the skill sets available to the team
Iteratively discover and deliver
Let’s take a closer look at each of these areas.
Many product owners never understand the complete picture of what it means to be a product manager The vast majority of product ownership training and guidance focuses on the relationship with developers and managing a backlog.
Those aspects are certainly important, but an effective product person also needs to be able to:
Understand the market in which their product exists
Identify the problem to solve
Determine how to measure when the team has solved that problem
Figure out how much to charge for the product
Identify the demand for their product
Help their organization market and sell their product
Establish a way to onboard new users.
As you can see, there’s a lot more to product management than backlog refinement and working with developers.
Of course the product person doesn’t do all of this additional work by themselves. In order to make your agile team into an agile product team, you have to expand the skill sets available to the team.
In addition to the roles that naturally exist on an agile team, you may need to add some or all of these additional skill sets:
User Experience - this will be an additional person that performs user research and works on relevant design aspects of the product
Product Marketing - this may be a part time member of the team or they may be a full time member.
Sales - this is a part time member of your team that provides input to pricing and guidance as to what would be helpful to sell the product
Customer Success - this is another part time member of the team who works with the team to make sure you can onboard customers to the product and help them use the product once it's launched.
The decision as to whether those additional skill sets add more full time people to your team depends a great deal on the size of your team and where in the product life cycle you are.
For example, if you’re introducing a brand new product, you are more than likely going to have much more involvement from marketing and sales. If you are enhancing an existing product you may not need as much involvement.
To finish adding product into your agile team you need to adjust the way your team approaches its work.
Alongside the development work you’d expect an agile team to do, you may want to establish a product triad consisting of a product person, designer, and developer who work a little bit ahead of the rest of the team to discover the next aspect of the solution that the team is going to deliver.
This approach is known as dual track agile and is a way to validate ideas for products as quickly and cost-effectively as a team possibly can. The advantages to a dual track agile approach include:
Streamlined, cost-effective development cycle
Higher quality products
Software that is adaptable to both market trends and user changes
This change in the way your team works means that you're not only developing a product in the right way (a benefit that agile approaches bring) but you’re also discovering and developing the right product.
Building an agile product team means extending the common structure of an agile team to position it to discover and deliver the right product, not just build software.
In order to make that shift, your team needs tools, like airfocus, that helps you prioritize what to do next, create clear roadmaps and collaborate on product strategy. Sign up for a free trial today to find out how airfocus can help you make your agile team an agile product team.