I recently received a question about the basic qualities Agile teams should have via the website. I replied with a reader’s digest version to the requester and promised a more complete answer in a blog post. Here’s that more complete answer.
Basic qualities for an Agile team
What are basic qualities should Agile teams have? I think it’s some combination of speed and flexibility. What are your thoughts?
Based on referring back to those sources, the main qualities I look for in a team are collaboration, the ability to learn and adjust, and the ability to consider the context in which they operate.
Hopefully the need for collaboration is self-evident. One unique aspect of the Agile mindset and many of the related frameworks (i.e. Scrum and XP) is the focus on the people doing the work and how they work together. It should follow that you want your team to be able to work together, and work together at a high level.
In order to deliver value to your customers, you need to know what your customers find valuable. You can’t find that out if you can’t communicate effectively with them.
Once you’ve identified the need you have to satisfy, you need to come up with a solution. You’ll have a better chance of coming up with the right solution if you incorporate the ideas, experiences, and skills of everyone on your team. You’ll also need to make sure that everyone on your team has a shared understanding of the need and how you end up deciding to solve it. To get through the messy process of coming up with a solution and getting everyone “on the same page” about it, you’re going to need effective collaboration.
Note that effective collaboration does not mean that your entire team has to be involved in every single discussion on every single backlog item. A team that collaborates effectively can determine when only a couple people need to be involved, when the whole team should be involved, and when you need to bring in people from outside the team.
Effective collaboration also means that the team experiences conflict and uses that conflict to their advantage. They use conflict to explore different assumptions, challenge assumptions, and arrive at novel solutions all the while emerging a well-running team.
Learn and Adjust
The part of the Agile Manifesto that seems to be most overlooked yet is probably the heart of the entire idea is the first sentence: “We are uncovering better ways of developing software by doing it and helping others do it.” In other words, learn and adjust from experience and feedback.
Your team learns whether you properly understand the need you’re trying to satisfy by interacting with your customers. You learn whether your solution will satisfy that need by delivering a part of that solution and getting feedback.
Your team uses retrospectives to learn whether the techniques you’re using and the methodology you follow enable you to deliver the right product and react to feedback effectively. A highly functioning team might find that having an explicit retrospective is no longer needed because you’re able to reflect and adjust on an ongoing basis. That in itself is a form of learning.
I suppose you could say that flexibility is related to learning and adjusting, however I think it’s important to explicitly call out the need to learn from experience and to do something with it. After all, a retrospective without ensuing actions is often just a gripe session.
There’s one concept that is conspicuously absent from the Agile Manifesto. That’s the idea that you need to consider the context in which you’re operating. The idea is certainly implied but it’s not stated directly, and I think its absence has led people to try to apply silver bullet thinking when they apply Agile frameworks.
Your team needs to be able to understand the context in which you work and adjust your approach to account for the unique aspects of that context. Your team needs to be able start with a particular framework and adjust it to fit your circumstances with the understanding of why the framework is structured the way it is and the problems that certain collection of techniques was intended to address.
Why speed is not necessarily a desirable trait
The emphasis on speed when it comes to Agile teams is detrimental. Yes, if your team collaborates and adjusts your approach and what you’re doing you will inherently deliver some value sooner. That speed is a result of the team adopting those other qualities, not an inherent quality in and of itself.
Organizations that adopt Agile because they think Agile by itself will allow teams to do things better, faster, cheaper are often disappointed. Agile helps with that, but you also need to improve your decision making so that you focus on the right things and not do a lot of things that don’t make sense.
How to measure those qualities
Can you recommend a survey to measure the team’s agility based on those qualities?
I don’t recommend trying to measure a person, team, or organization based on “how Agile” they are. I find surveys that propose to measure agility tend to drive people to focus on that rather than focusing on whether they are delivering value to their customers.
Agile is a means to an end. It will certainly help your team to deliver value, but you’ll need to do other things in conjunction, such as effective decision making about what you do and do not undertake and deliver. Agile will help you achieve your outcomes, but it should not be the outcome. That’s where some Agile transformation efforts make their mistake: they target being Agile as the ultimate goal and lose sight of why they wanted to be Agile in the first place.
You need to understand why you want to measure how teams are doing with respect to those qualities. What are you hoping to accomplish?
If you’re looking for some way to gauge how well the team is performing for purposes of making adjustments and seeing the impact, I’d suggest looking at the outcomes they produce. Do they know what they’re trying to accomplish and are they making progress toward that target? If there’s a trend heading in an undesirable direction, do they dig into why that is and make adjustments to get back on track?
If you’re looking for some way to compare one team to one another, I’d recommend against it. You get what you measure, and all measurements will be gamed. Measurements used explicitly for comparing teams against each other will generate activities you probably don’t want to have, and certainly won’t support collaboration between teams (although you may find individual team members collaborate with each other to stick it to another team).
What do you think?
The above is my perspective on the qualities of a good Agile team. I fully realize that my perspective is but one of many.
What do you think are some good qualities of Agile teams? Should you measure them, and if so how?
And if you have a question you’d like me to tackle in a future Agile Q&A post, let me know.