People Vs. Technology: Creating the Team

The Agile Manifesto emphasizes a focus on people over other things.

Individuals and interactions over processes and tools
…
Customer collaboration over contract negotiation

Most of us that work with technology are enamored with it.  Even those not struck by love of bits and bytes seek predictability in our work.  Humans are so much harder to predict and deal with than spreadsheets and marketing requirements documents.  Thus, the enterprise tends to start-up new teams considering only the numbers, features and skills while largely ignoring the humanity of the team.

Recently I have participated in the definition of a new project.  The marketing department measures and discusses features, engineering leadership discusses architecture and micro-processor choices.  Slowly, over meetings and emails, a Marketing Requirements Document emerges and engineering begins to create an architecture definition.  The defined “bells and whistles” show a product that will dominate the market.  The technology described looks fun and exciting, with new processors and data-flow paths that will meet the high performance numbers.  The concept is good, the management team is on board, funding is approved.

“Yee-ha!  Let’s go!”

“Wait.  Who is going to do the work?”

Now, it is true that discussions about people and skills happen during all the planning described above.  But many times such discussion is shallow until the project needs to start.  With the project already started, defining and building the team becomes an hurried exercise.  Consideration of current teams and their projects may be tossed aside in the rush to get started.

More difficult yet is the personality equation.  Rarely in my experience does the “human side” of the people doing the work get as much attention as the questions of technical skills and availability.  Expecting a team of experienced and socially mature developers to gel, simply because they’ve been assigned to the same team, is courting project difficulty.  This matters much more for agile teams who are expected to meet everyday, collaborate on decisions about work and even work side-by-side in the same room.

Here are some suggestions on how to make sure that the people part of the team gets deserved attention:

• Involve potential team members in the product and project definition phase. Even before the project is defined, the people likely to work on it may be known.  Have them participate in the definition discussions and research.
• Create a definition review team to help create the initial Product Backlog. The review team will consist of those most likely to be on the project team.  This allows them to learn about the project and practice working together before the full-time commitment starts.  Estimating a backlog brings out personality, allowing “measurement” of the human factors involved.
• Let the members know as soon as the full-time team is selected, even before they are full-time on the project. This allows for responsible team member feedback about the makeup of the team while there is still time to adjust.
• The first meetings of the team should not be about the project but about the team. Time should be spent defining work agreements and other rules of interaction within the team.  The team defines all the everyday questions like documentation tools that will be used, when will meetings be held, how will disagreements be handled, how will pair-programming partners be determined, will there be penalties for being late to meetings, etc.  The ScrumMaster should facilitate the creation of these rules and publish them with a team commitment to them.
• Allow a day or two for the team to get their working environment in order. Like the working agreement, the team needs to create their physical working environment such that they take ownership and are comfortable.  Moving desks, building servers, setting up the team task board and so on are needed parts of the initial team connections.

For organizations practicing agile or Scrum, the above suggestions should be obivous.  But given our tendancy to get wrapped up in the technology and numbers, neglect of the “human equation” happens easily.

What steps do you take to make sure a new agile team starts off with the best possible human foundation?