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 agile 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.
Hi Ben,
Interesting article with lot of food for thought. Here are some of my reflections after reading it:
Agile teams are indeed multidisciplinary. A consequence is that the team members have different mindsets (FOR, mental models). This is good news, since diversity is the fuel for synergy.
Agile team members work synergistically together. There interactions are synergistic. This means that, to me Agile team members live Creative Interchange from within. You know that CI (Creative Interchange) the process is of all learning and transformation and discovered by Henry Nelson Wieman and translated in modern management language by Charles Leroy ‘Charlie’ Palmgren. By the way, the first characteristic of Ci is Authentic Interaction.
Agile team members do need to created a shared meaning (you write idea) about the problem at hand: what it really means and what the difference is between the actual reality (with the problem) and the desired reality (once the solutions realized). That difference is responsible for the creative tension, see Peter M. Senge’s 5th Discipline.
Tuckman’s model is great, unless the team members are prisoners of their Vicious Circle. The model needs a process: the Creative Interchange process, otherwise it won’t work.
I too have mixed feelings regarding the concept ‘goal’. If an Agile team really works synergistically together they can reach results beyond the goal. I love the idea of ‘direction’!
Indeed there is no ‘best’ way to form a team, if they live CI from within, they surely find their way. And the road is more important than the destination…
And indeed Awareness is not the same of Consciousness. In our mother tongue both are translated with the same Dutch word. That was the reason it took me years to fully grasp the very important difference.
These were some of my ideas. I stop here, since I have the tendency to write comment that’s longer than the article … So have a nice day Ben
Creatively,
Johan
Thanks Johan for your profound reactions!
I like it how you state that diversity is the fuel for synergy. It indeed enables people to work together and lowers the risk of groupthink.
Meaning is indeed a better word that idea, thanks for pointing that out. I updated the article 🙂
I’ll have to give some more to “direction”. It’s something that can guide teams, but it can also make them blind for alternative paths. Food for thought for me, thank you Johan!
Keep your comments coming, please!