Agile talks a lot about self-organized teams, where people work intensively together to deliver software. But what really is an agile team? In this article, I’ll explore how agile teams look and what makes them differ from a group or any other format in which people work together.
How do agile teams look
My definition of an agile team is:
An agile team consists of people working intensively together to deliver value to the users and customers of their products or services and the stakeholders.
I explicitly use the word people in this definition. I don’t like the term “resources” when referring to people, as I explained in my article don’t call people resources. Terms guide our mindset, they influence how we think. Agile teams are multidisciplinary, they have people with different experiences, skills, and qualities. This is why I propose that we no longer use the term “resources”, but call them team members people, and treat them accordingly
The first statement of the agile manifesto tells us to value individuals and interactions over processes and tools. Working together matters! Teams can do great stuff when people work intensively together in a way that suits their needs and fits with the personalities of the team members.
To deliver value, teams have to know what value is. Value is in the eyes of the beholder, the users, customers, and stakeholders. So teams need to understand what they need and why they need is. They need to have a shared meaning about value. If only the product owners know what value is, that doesn’t work, literally.
I distinct between users and customers, and stakeholders, because the kind of needs that they have will be different. For users and customers, it is about the product or service that is delivered and how they use it When it comes to stakeholders, the needs will be driven by the company goals. Think about things like governance, company goals, strategies, and procedures.
Misunderstandings about agile teams
Many people say that agile teams need to have a goal and team members have to commit to attaining it. I have mixed feelings about that.
First, I don’t believe that there is ever only one goal. Not even one sprint goal. It’s plural, there are always multiple things that need to be realized. Grouping things into one goal to be reached at a specific time isn’t helpful nor feasible. Value is continuous and incrementally.
Second, while I expect people in a team to do the best they can, my experience is that commitment can backfire. If a team needs to deliver a feature at the end of the sprint, it not only about committing to the on-time delivery of it. You also expect the feature to have sufficient quality: Quality as perceived by the user and internal (design/code) quality. Note that in the 2011 version of the Scrum guide commitment was replaced by forecast, but unfortunately many still talk about teams having to commit.
Third, the team has to monitor how they are doing and adjust where needed. The agile manifesto promotes sustainable development. If that implies that things take longer (or shorter) then we should be willing to accept that, and don’t put pressure on teams by telling them that they missed their goal or didn’t live up to their commitment.
Another thing that I think is important is that a group is not an agile team. If you group people together and make then responsible for delivering, that doesn’t automatically turn them into a team. If you want to learn more about this, I’d recommend exploring Tuckman’s model: it represents the stages that people working together go through to become a team (“norming, forming, storming, performing”).
There is no recipe for teams, no one best way to do it. How people work together will be different from team to team, and that’s ok. Actually, I prefer that. When I coach people in teams then I help them to reflect on how they work together, identify problems, and think about how to solve them.
Scrum states that teams need to have one product owner who sets priorities and defines what is needed. As I mentioned earlier, agile teams have to work together with users, customers, and stakeholders. Preferably their needs are aligned, that will make it easier for an agile team to serve all parties. But there will always be subtle but important differences, and teams have to be able to deal with that. Note that if there’s a major misalignment, then I suggest to make it visible and discuss it with those involved how to handle it.
Increasing awareness of agile team working
Talking with people I noticed that there’s much unclearness on what a team is and why collaboration matters. With this article, I want to increase awareness of agile team working. In future articles, I’ll dive into the benefits of team working and what you can do to establish great teams.
This article is based on the presentation Teams, what’s in it for me? that I gave at the first GrowIT conference in Novi Sad, Serbia, on December 2, 2018.
In this talk, I explored why people would like to work in teams, what managers can do to enable a team structure and culture, and how to (not) manage teams.
If you would like me to give a presentation at your conference or do a full day workshop about agile team working, please contact me.