Spinning up a new team

I am forming a new team. We are doing this as an experiment, so we are documenting the heck out of it. As part of this effort, I am publishing “Coach Arlo’s Secret Agenda”—a daily journal of what I intend to teach each day and what the results were. This is/will be a name-scrubbed version of that series.

Welcome inside my mind as I go through each day and detail of spinning up a new team and transitioning it to agile at the same time.

The plot

This team is a 2-week experiment being run by my work group (Microsoft’s Engineering Excellence Learning & Development group). EE L&D wants to work in a more agile fashion. We are trying to determine what that means.

We’ve identified several things that we want to improve. We’ve picked a process that we think will achieve those goals (a product council with one backlog, with cross-functional, cross-capable teams pulling from that backlog to create 1-week sprint commitments). However, there are two things that this process requires that we are not sure we can do:

  1. Focus fire. Plan to do a few things at once, get them done, and only start more things after they finish. Start actually prioritizing.
  2. Create cross-capable teams. The team needs to be able to consistently choose work from near the top of the backlog, even though the kind of work varies dramatically.

And we’re not a software group, so when I say “dramatically,” I really mean it. Some days we may be creating a hands-on lab to teach people the ins and outs of refactoring, showing them how to do emergent design by doing it ourselves. And the next we’re creating walking decks for managers to use to train their executives in the needs related to fault tolerance for a service.

We, as a group, need to cover all technologies and all domains in which Microsoft participates. We need to be able to talk to 20-year veteran programmers, new hire UX designers, test managers, and executives, covering everything from mind-shift to deep technical details.

Because of this, and because of Microsoft culture, we have developed into a loosly-connected set of specialists, each with a large set of contacts across the company. We each work on different things for different people. We spend a lot of time helping people in product groups learn from experts in other product groups.

This team is formed as an experiment related to the second point. Our goal is simple.

Experiment definition

Demonstrate that EE L&D can form a cross-capable team which, in its first 2 weeks:

  • Is no less productive than the control group (a set of 5 specialists who are working in the old way)
  • Is more flexible than the control group. In particular, it can focus the efforts of the entire team in a specialized field even though the initial membership includes only one person with any depth in that specialty.

Good luck measuring that

There is no good measure for productivity. However, EE L&D is far more interested in impact anyway (also difficult to measure, but much easier to identify). So we will be focusing on impact. Our team’s goal is to have at least as much impact on a product team in this time as the 5 semi-independent specialists, but to focus that impact in a way that does not match the specialties of the team members.

Our team has 5 members. I am one of the 5. It is assumed that I will be a contributing coach. Or, rather, it is assumed that we are comparing all-in costs. We want to include the cost of coaching and moving to the new way in our comparison to continuing to work the old way. Also for this reason, the experiment starts measuring from the first day of the new team.

If we roll this out more broadly, each team will have a short bit of training and chartering before it is expected to produce. We are given the same. That means a single half-day session (3 hours) to spend as I will. I spend about 2 hours of it giving a basic grounding in XP (core concepts & attitudes, purposes achieved by the practices, how they fit together, and a 3 second mention of each practice). I spend the last hour doing a chartering.

That means both activities will be rushed. Such is life.

The cast

Our 5 members are (note: only my name is real; all others have been changed):

  • Arlo. Team’s embedded coach. Also a contributor. Lots of experience with this sort of thing—both the style we are shifting towards and the process of shifting. I am a developer/coach by trade. I am a bit of a recovering-Wizard role.
  • Dana. Likely the product owner. A couple of years’ experience with being product owner on a scrum team. No other agile experience, but good at being PO and very organized / driven and competitive. She is a program manager by trade. She is somewhat Bishop role, with a bit of Salesman.
  • Fran. Recent convert to agile. Was on my team when I transitioned us last fall. Initially highly skeptical; now a new convert. Especially had good experiences with pairing, and now one of the strongest proponents of agile practices in our group. She has lots of positive stories and speaks well in the we voice. She is an Instrucitonal Designer by trade. She fills the Champion role.
  • Tara. New to agile. Skeptical. She is driven by achieving results. She has never done anything like this; her entire career has been individual work. Her current team is trying Scrum without shifting to team-based work. It isn’t working, so she is somewhat skeptical. But willing to try; she sees this as different. She is a program manager by trade.
  • Ben. New to agile. His boss is skeptical. His boss is, in fact, the most skeptical of this approach within management. Ben landed in the experiment entirely unprepared: he wasn’t even informed that it was happening. He is a tester by trade.

And here’s what happened…

…Tune in tomorrow when we discover what Arlo was thinking as he prepared this team and what happened during their training and chartering. Also what awesome team name they came up with.

Leave a Reply

Your email address will not be published.