How to ease the formation of agile teams
I see a lot of people struggle when new agile teams need to be formed or existing ones are to be reformed. These struggles can be addressed by introducing and agreeing on a handful of principles. So let’s first look at the struggles and then discover what principles can do.
Common struggles include:
- Managers who decide on team formations while bypassing the people who will end up in these teams and, as such, pissing them off for not being involved.
- Managers who propose team formations but their communication about their proposal is interpreted as a decision, pissing people off for the same reasons as above.
- Managers who propose team formations, communicate late and then struggle with the feedback they get because “the formation process already took a long time and now it’s time to decide”, which is pissing people off again because they feel rushed.
- Managers struggling with the question “which resources” they should put into teams by trying to map work to be done on people’s specialties and functions.
- Candidate team members having assumptions about agile, especially about “being in long, boring meetings” and who therefore try to create specialized sub teams so they will not be “bothered by the unnecessary stuff”.
- Candidate team members who have no clue with whom to form a team because there’s no clear product vision and/or idea about the work to be done.
- Both managers and candidate team members asking themselves is the teams “really need to be this big”, and then end up failing to make the teams smaller.
These are the 7 most common ones I see. There may be more. Let’s just work with these for now.
Regardless of who is actually forming a team, let’s first look at the basic principles on which to build a team:
- A compelling vision exists which helps the team to embrace a sense of purpose and direction and enables them to define, design and build valuable outcome.
- The team, as an entity, takes responsibility for creating outcome in line with the vision and as such is (as) multidisciplinary and (as) autonomous (as possible).
- The team is small enough to be able to collaborate as one entity towards both the required outcome AND an increasingly more effective team. Clever people who wrote clever books say that this number is about 5 or 6 people per team.
Obviously, adhering to these principles will immediately solve struggle nr. 6.
The underlying issue with most of the other struggles is the assumption that people are stupid and can do only so much. They have a function and are paid to do a certain job. We cannot expect them to do everything right? So…we need A LOT of people do change a light bulb.
This is why managers tend to form teams instead of the candidate team members. Most managers tend to be RESOURCE managers anyway, so that’s what they do.
And even if these managers allow people to form their own teams, these candidate team resources are often so stuck to their function that they themselves will admit they will need many colleagues with them in the team to stand any chance as to delivering result. Right?
When you give people some basic principles to work with, they will usually turn out to be very capable of forming their own teams. Let’s just take a look at these principles:
- As a team, you are the smallest steerable entity (i.e. individual team members will not be bothered).
- Failure is an option, as long as you visibly work towards the vision, learn, and improve, not making the same mistakes too often.
- It’s fine to not (yet) being able to produce fully shippable results, as long as you work towards the vision, ask for help, and work on becoming more knowledgeable, more skilled, more multidisciplinairy, and more autonomous.
- You can change the team if it’s not working despite everyone’s efforts.
Of course these principles are in addition to the team principles mentioned earlier.
That said, it ’s okay if the team members themselves decide they need to start with 10 people. As long as they understand the principle of small teams and decide to consciously try it anyway. This will address struggle nr. 5 because they now have to organize exciting meetings with 10 people by their own choice 🙂
It will also address struggle nr. 7 because now the team can decide NOT to include all specialities they apparently need and focus on acquiring the required skills with a smaller group by learning. Eventually they will become more multidisciplinairy and are then able to let some team members go or split up in two teams.
Let’s finally look at the management issue which encompasses struggles nr. 1 – 4. For this we can refer to two of the principles from the manifesto for agile software development:
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The best architectures, requirements, and designs emerge from self-organizing teams.
That said, it’s fine if a manager PROPOSES a team formation and then communicates it timely and properly. Sometimes it is even okay if a manager decides on a team formation, especially when candidates turn out not to be able to form teams.
As a last resort, a manager can add one more principle to the ones we already have by now.
- Management can disband the team if the required results are not being met.
Not a strange one because the team is not paying for their own existence and still needs to live up to the expectations with respect to results and team improvement.
So there you have it: teach and apply principles to to ease the pain of agile team formation and avoid common struggles. I hope it helps you on your journey, either as a manager or as a team member.