In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams. It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment. The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective. They were functional teams (e.g. a team of testers). But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration. So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team. Everyone was involved – all the people who would be on the teams were in the room. Those teams stayed together with the same membership long after that meeting.
This “team creation event” was a fantastic success for that particular department. What made it a success?
- Everyone participating already had Agile training and experience. They knew what they were getting into and why they were doing it.
- Everyone was encouraged to participate through the way the meeting was facilitated. No one felt like their opinion was ignored.
- The meeting was long, but also time boxed. It wasn’t an open-ended discussion that could go forever.
- It was in-person!!! Everyone was physically present so that not just abstract facts, but also feelings were clearly visible to everyone else.
- It was honest: tough things were discussed including potential personality conflicts. This open discussion required expert facilitation.
- Management was not involved in the decision-making during the meeting.
- The overall purpose of the exercise was clear: here’s the business we’re in, and here’s the people we have to work with – how can we organize ourselves to be most effective?
- A big diagram of the proposed teams and their membership was constantly being updated on a whiteboard: visual and concrete for everyone to see.
- Preparation: the meeting was scheduled far enough in advance that everyone could make it and management was informed about how important it was (don’t schedule over top of it!)
In the Real Agility Program, the team creation event is used to launch a Delivery Group. The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people. Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day. Longer is not recommended. For larger Delivery Groups, we recommend that the team creation event be held off-site.
Facilitation of the team creation event is usually done by the process/people Real Agility Coach. If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.
The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work. If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again. A few days should be the maximum delay.
One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready. In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees). As a result, the teams created in the team creation event were not really properly stable. This caused a great deal of disruption and even significant morale problems for some teams. It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event. That includes any necessary means to encourage people who are thinking of leaving to reconsider. It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.
So, to make it systematic, here are the steps required to run a team creation event:
- Make sure that everyone who will participate has Agile training and has been on an Agile team for at least a few iterations/sprints/cycles.
- The Leadership Team needs to publish a notice (usually through email) explaining the upcoming team creation event and their unqualified support for the event.
- The people/process Real Agility Coach needs to schedule the time for the event, and if necessary, book the venue.
- In the weeks and days leading up to the event, some communication should be provided to all the participants about the overall business purpose of the Delivery Group. Is it for a specific Program? If so, what is the objective of the program from a business perspective? It should not just be a one-time communication. This should come from the business Real Agility Coach.
- The Leadership Team needs to decide which management stakeholders will attend the team creation event and make presentations. These presentations should be about setting a vision for the Delivery Group, not about assigning people to teams.
TEAM CREATION EVENT AGENDA
- The team creation event starts with the people/process Real Agility Coach welcoming people and reiterating the purpose of the event.
- Management stakeholders make their presentations to ensure that participants have a clear vision.
- The business Real Agility Coach summarizes the vision presented by the management stakeholders.
- The people/process Real Agility Coach provides instructions about the constraints for a good Agile Delivery Team:
- Multi-skilled (see the Skills Matrix tool for ideas here).
- Correct size (usually 7 +/- 2).
- People who want to work with each other.
- People who want to work on that particular team’s goal (if such is set).
- Everyone must be on a team.
- Every team must choose the people who will fill the Agile Delivery Team roles (e.g. ScrumMaster and Product owner for Scrum Delivery Teams).
- Everyone starts self-organizing! Usually the three Real Agility Coaches circulate through the teams as they are working to organize themselves to offer gentle guidance, to answer questions, and to see if there are opportunities to optimize across teams. These optimization opportunities should always be offered as suggestions rather than being directive.
- As the self-organization is happening, the people/process Real Agility Coach needs to clearly indicate the passage of time so that people are “finished” when the time has run out.
- Once the self-organizing is done, the Leadership Team (or a representative) thanks everyone for their work in creating the teams and agrees to let everyone know within a short period of time if there are any changes required (to be done before the teams start working).
- The people/process Real Agility Coach closes the meeting. It is critical to record the final results of who is on which team. It may be easiest to get the teams themselves to do this before leaving the meeting.
- The people/process Real Agility Coach makes sure that the Leadership Team receives a complete and accurate record of the results of the team creation event before the end of the day.
- The Leadership Team reviews the results and makes any (minor but critical) adjustments within a few days, at most, and publishes the final list to everyone. Failure to do this in a timely manner can deeply demoralize the staff who will be in the Delivery Group.
- Any updates to org charts, management tools, time tracking tools, job descriptions, etc. that need to reflect the new team organization should also be made immediately and certainly before the Delivery Group starts working.
- A final thank you message from the Leadership team should be delivered immediately prior to the start of the Delivery Group doing its work.
Have you experienced an event like this? Did it work? What was different from what I described?