Tips for Structuring Agile Teams
After interviewing a bunch of teams and based on my personal experience, I would like to outline some conclusions I have made regarding Agile team forming decisions.
Business is used to a department or functional structure, so they try to build small teams still within those same departments. Using this approach, making teams cross-functional and independent becomes a real challenge. Skills within any such team are not sufficient to deliver a fully functional product, therefore the group members need to work with people from other departments or streams. This causes endless and pointless meetings, conflict of interests, and disappointment in Agile.
For example, let’s look at a team of technical writers. The group is small, self-organized and collocated. Everyone has the skills to do the work and the same goal - to provide documentation for the various products of the company. Seems like a perfect Agile team and management is quite happy, too. However, to achieve their goal, the writers need to work with the product teams way more often than within their own group. As a result, lots of their Agile ceremonies have no value as the writers have not much to talk or collaborate about as a team; i.e, their meetings are always with the wrong audience. Also, they have a different manager and goals than the members of product teams, which causes a conflict of interests. Despite the right size, collocation, skillset, and shared goal, the team is not independent enough to deliver value.
One of the solutions to the described situation could be to place technical writers on the teams of products for which they produce documentation.
One of the solutions to the described situation could be to place technical writers on the teams of products for which they produce documentation.
One manager per team
It's well known that people perform much better in smaller groups as there is less communication overhead, fewer dependencies to solve and it's easier to come to a consensus. The same is true for having multiple managers. The fewer bosses, the better the team performs.
I've been on a team with 9 team members under 5 different managers (one for each function - Product Owner, Scrum Master, Developers, Testers, and a Designer). The group was cross-functional and independent from other groups but not the managers. The fact that we had to please so many supervisors was a disaster. Every team member had different directions from his/her manager, so besides keeping the stakeholders happy, we had to find compromises for management as well. It included providing various kinds of metrics, accommodating everybody's staff meetings with our ceremonies, and complying with the strategies of numerous departments. Being a Scrum Master, I spent more time on solving this big puzzle rather than focusing on my team.
Therefore, try to form a team under one manager. If you think it's impossible in your situation, you may need to dig deeper into the higher organization level. Quite often it points to some necessary reorganization changes at the top.
Check what the metrics say
An agile team is successful when it's continuously improving and easily adjusting to changes. Metrics are an excellent way to assess the team's maturity. In case you find that your statistics depend more on individual performance rather than the group's, or if the team does not have the autonomy to improve on their own, then it could be a sign of an incorrectly structured team.
Let's look at the team of technical writers again. One of the metrics they were using was Cycle Time for creating a document. The Scrum Master noticed an increase in the average time to deliver the final paper. After a discussion, the team concluded that even by knowledge sharing and helping each other when bandwidth allowed, they were still heavily dependent on the product teams. So they could not resolve the problem on their own. It was a clear example of a non-cross-functional team. Having skilled writers on the team was not enough to do the job.
Therefore, if you find yourself in a situation when your metrics don't make much sense, you may want to look at whether the current set up serves the team in the best possible way.
Too many meetings? - Team structure could be the reason
Did you ever wonder why the teams accuse Agile in being a bad practice because of too many meetings? I did, and I believe that the team structure is a significant factor.
A meeting seems redundant to the attendees when it is not relevant to them. In such conditions, they are not engaged, and they don't express interest or intention to help achieve the goal of the conversation. Later on, they complain about such meetings. Agile ceremonies will never help teams who have no shared goals. Indeed, they just make things worse as they create a sense of pointless meetings which keep people away from doing their jobs.
On the other hand, a meeting will never be perceived as being redundant if its attendants share a goal which they need to achieve together; this will only happen in cross-functional teams.
I suggest reviewing the team structure if during the following warning signs exist.
An agile team is successful when it's continuously improving and easily adjusting to changes. Metrics are an excellent way to assess the team's maturity. In case you find that your statistics depend more on individual performance rather than the group's, or if the team does not have the autonomy to improve on their own, then it could be a sign of an incorrectly structured team.
Let's look at the team of technical writers again. One of the metrics they were using was Cycle Time for creating a document. The Scrum Master noticed an increase in the average time to deliver the final paper. After a discussion, the team concluded that even by knowledge sharing and helping each other when bandwidth allowed, they were still heavily dependent on the product teams. So they could not resolve the problem on their own. It was a clear example of a non-cross-functional team. Having skilled writers on the team was not enough to do the job.
Too many meetings? - Team structure could be the reason
Did you ever wonder why the teams accuse Agile in being a bad practice because of too many meetings? I did, and I believe that the team structure is a significant factor.
A meeting seems redundant to the attendees when it is not relevant to them. In such conditions, they are not engaged, and they don't express interest or intention to help achieve the goal of the conversation. Later on, they complain about such meetings. Agile ceremonies will never help teams who have no shared goals. Indeed, they just make things worse as they create a sense of pointless meetings which keep people away from doing their jobs.
On the other hand, a meeting will never be perceived as being redundant if its attendants share a goal which they need to achieve together; this will only happen in cross-functional teams.
I suggest reviewing the team structure if during the following warning signs exist.
- Daily Scrum: team member's updates are not interesting to most of the other attendees.
- Retrospective: there are many comments such as "we can not solve the issue because it doesn't depend on us," "we don't have enough information," "it's not just us who has to make a decision," etc.
- Planning: There is really nothing to plan as people don't share any work. Thus, no group discussions or clarifications. The meeting reminds more of confirming that the group has work to do.
- Grooming: Most of the time the team is grooming stories which are related to one or two people and the rest is just waiting for their turn.
Therefore, before concluding that working in Agile means lots of meetings, review your team's structure.
Collocation is not a deal breaker
Collocation is very important because there is nothing more effective as face to face communication. However, sitting in the same space should not be a deciding factor when forming teams. We live in an era of advanced technologies so not having everyone together is not the end of the world. The same time zone is an acceptable alternative.
I’ve worked in the environment when the main focus was on collocation. Everything else was not as critical. Some teams were too big; others lacked skills so they became dependent on outside groups. Ironically, management was still happy as they reached 100% collocation. In the end, it all turned into teams facing lots of unnecessary dependencies, communication overhead, and ineffective meetings.
Therefore, collocation is great, but criteria such as cross-functionality, having a shared goal, and the proper size comes first.
Collocation is very important because there is nothing more effective as face to face communication. However, sitting in the same space should not be a deciding factor when forming teams. We live in an era of advanced technologies so not having everyone together is not the end of the world. The same time zone is an acceptable alternative.
I’ve worked in the environment when the main focus was on collocation. Everything else was not as critical. Some teams were too big; others lacked skills so they became dependent on outside groups. Ironically, management was still happy as they reached 100% collocation. In the end, it all turned into teams facing lots of unnecessary dependencies, communication overhead, and ineffective meetings.
Therefore, collocation is great, but criteria such as cross-functionality, having a shared goal, and the proper size comes first.
Follow up with the team
Last but not least - get the team's feedback about the group's structure. Agile is all about getting better. Team structure falls into that as well.
It's important to check with the people whether the current set up works for them and if anything is missing. Usually, the Scrum Master can answer such questions, but it's better to confirm with the whole team. This way you will show people that their opinion matters and also verify that the implemented team structure served its purpose.
When gathering feedback, ask open-ended questions such as "what they like or dislike" or "what they would change if there were such an option," and so on.
When gathering feedback, ask open-ended questions such as "what they like or dislike" or "what they would change if there were such an option," and so on.
Great blog article. It's a tough equation to solve primarily because of what you pointed out, "Business is used to a department or functional structure, so they try to build small teams still within those same departments. Using this approach, making teams cross-functional and independent becomes a real challenge."
ReplyDeleteKeep up the writing! :)