‑ Balanced Team

When creating a team meant to work in an agile setting, most people remember that there are supposed to be more people in it than developers. They might skim through the Scrum Guide and fill the roles of Product Owner and Scrum Master. What few do is to think about what other roles that are really needed.

The first set of questions they should ask themselves is if they already know exactly what kind of product they should build, if they know the problem statement and if there is a base solution to start iterating and incrementing from. Or, if they have a function in the company that will deal with these questions and prefer working in a waterfall way, delivering some sort of specification to the team. If there is a yes on all (or most of) those questions, then they have a delivery team and the only roles that might be needed apart from the kinds mentioned above are those concerning delivery, such as Dev Ops or similar.

But, if they actually do not know what they are going to build (and my guess would be that this is more often the case), then they would need people to help out with discovering what to build. One way of finding out what roles that would be needed is to base the team on what is required for business innovation.

A balanced team approach

This would mean that to create a good product, i.e. take good product decisions, they would need input from at least three different persons; One understanding the viability and the business case, this could be the Product Owner. One understand the technical feasibility, this could be one of the developers. And one understanding the desirability and the usability, this is most likely some sort of User Experience Designer. Together these people will bring balance to the product’s goals and possibilities. Hence, this is what is usually called a Balanced Team (or a product discovery team).

As you can see, understanding all this will most likely require more people than the three mentioned above, at least if the product they are building is bigger than a simple and independent app. My suggestion is that they should look at other roles outside of the specified in agile literature that might be good at understanding these product qualities and see them as support to the main role. For instance, Business Analysts together with Domain Experts should be really good at understanding the business case and Requirement Engineers could help combining all the different stakeholder input into something viable. This is something that could really benefit the work of the Product Owner. User Researchers should be really good at finding out what users need and get motivated by, Copywriters and User Interface Designers could help making the product be desirable in real life. They should be able to help the User Experience Designer tremendously. Also, accounting for technical feasibility when discovering what needs to be built is a must.

My suggestion to all ”they” people out there, is to draw a diagram like the one below and start adding roles or work that might be needed in the circles. This is an easy way to map out possible roles or lack of competencies. When you do this with your team, why not share the roles you find in the comments to this article for others to benefit?

Agile team roles

One reason for this not already happening in an organisation might be that collaboration between these different roles can be hard, and this is of course true for adding more people of the same role to the team as well.