What our very own IQers have to say…
By Brand Zietsman – Agile Consultant, IQ Business
Recently, I worked with a team in an organisation that had just adopted Agile Methods. During my initial interaction with them, they identified concerns regarding the team’s structure and the relative strength of the current Agile teams.
The team’s line manager had recently attended Management 3.0 and was keen to let the team determine their structure.
As a starting point, we had to identify the skills and domain knowledge that the team would need to be effective in their environment. The team workshopped the ideal competencies, and we developed a checklist for use in team selection. The primary focus of the list was the required business domain knowledge and technical skill sets. At this point, we did not consider the level of competency in each of these areas.
At the end of the workshop, we had a competency checklist that listed Technical skills:
Business domain knowledge:
Next, we had to figure out how to structure the team. We played “The Meddlers Game”, one of the Management 3.0 tools.
We reviewed the roles currently in the team and included a couple of vacancies in the team. The team then split into three groups to configure a team structure that they think would best support the organisation, given the current people and roles.
After two iterations we had the following configurations emerge:
We reviewed the pros and cons of each configuration. The team and the line manager agreed on a four-team configuration. They support a system used in multiple countries across the African continent, and they reasoned that this setup would best allow them to serve the various countries. This configuration would enable teams to work on the top priorities of the different countries, in light of challenges in identifying a single highest priority across all countries. Their biggest concern with the configuration was the ability of a team to continue in the absence of any of the team members.
Following agreement on the structure, we had to populate it with the best possible combination of team members for each team. We ran a self-selection workshop, using principles on Self-Selection (borrowed from Sandy Mamoli and David Mole at Nomad8).
We created four posters representing the four teams with the roles that had to be filled and attached the competency checklists. We reminded team members to make their decisions based on the best interests of the organisation and its customers. Then we started the first round of selection. After seven minutes, teams completed the competency checklist and reported back on the areas they believed they still had a weakness. Once all the teams finished providing their feedback, we held another round of selection of seven minutes followed by a feedback session. After three rounds, the teams settled into what they considered the optimal configuration, and there was no more movement between teams.
The team started working in their new configuration. Soon after that, the area showed some improvement.
Based on research that Nomad8 did on self-selection, it has the following benefits:
I believe that a process that includes the team in defining their team structure will only amplify these benefits. The full benefit of self-definition and self-selection did not realise for this team. Some other environmental factors impacted the team. Unfortunately, the team lost team members due to competition for competent people with knowledge and technical skills on the platform that they used. Their concern regarding the impact of absent team member was realised, and they fell back to a two team configuration. The change to the two team configuration was relatively smooth.
I have not yet used this approach with larger teams; it will present a new set of challenges that I am certain can be overcome with cunning facilitation.
If you have followed a similar approach, I would love to hear from you and learn from your experience. I will keep on experimenting with this approach… the benefits are worth it.