Ask Teams to Organize Themselves
If your organization has always organized by function (development, testing) or by architecture (front-end, back-end, middleware), consider asking the teams to organize themselves to become feature teams.
Too often, managers want to assign people to cross-functional teams. Instead, ask the people to discover how to create feature teams that make sense for them.
Too often, managers don’t have enough information about the people. Managers might not know what a team member wants to learn. They only know what a person has done since that person started to work for that manager. People have many more capabilities and skills.
When team members self-select their areas of interest, they have a purpose. They start to exercise their autonomy so they can build more mastery. When managers assign people based on expertise, those managers reinforce the problem of resource efficiency.
Let the team members decide what features to work on and whom to work with. You will see better throughput and more of a chance at technical excellence. See Creating Great Teams [MM15] for more information.
If you have everyone on one campus, consider asking them to come to a large room. Explain the feature teams you expect: Admin, Diagnostics, Search, and so on. Label flip charts in different areas of the room with the names of the features. Ask people to stand near the flip chart they would like to work on.
Ask people to add their names to the flip chart. When the people are done moving around, see what you have. Ask each team to see if they are missing any capabilities on their team. Encourage the people around each flip chart to write down their capabilities and see where they are.
Facilitate organizing teams who have “too few” of any capabilities. In my experience, teams might be missing product owner, UI/UX, or testing capabilities.
If you can’t get everyone in the same physical location, ask people to do the same exercise virtually. The virtual exercise works especially well if people want to work with a particular product owner. People may have worked with this person before, so the product owner attracts a team to work with him or her.
If your organization has optimized for resource efficiency (see Managers Move from Resource-Efficiency to Flow-Efficiency Thinking), don’t be surprised if you have teams that are not full-feature teams.
In that case, ask the team members to work in pairs (two people working together on one feature), and preferably as a mob (the entire team works together on one feature) so they can collaborate as a team. As they collaborate, they will learn—as a team—which other people they will need to create features. (See Work as a Whole Team to Create the Product, for more information about pairing and mobbing.) Teams can start the hiring process, regardless of whether that means extending an invitation to someone inside the organization or hiring from outside.
In my experience, teams of four to six people are just about the right size. In agile terms, that’s a couple of developers, a tester, and a product owner. Your experience might be different, so consider running experiments to see what the right team size is for different areas.