One Team: Replay

Since many of the readers of this blog weren’t around for some of my earlier writing, I will occasionally mix in popular articles I wrote some time ago. The plus for me is that I don’t have to spend so much time writing. The minus is that I cringe to see the thought errors in my earlier work. I wouldn’t write this way now, but rather than bowlderize my own history I’ll present it as is, binary thinking, exaggeration, and all.

This piece one entitled “One Team”, about the evolution of my thinking about software development teams. It was initially published in July of 2001. It was interesting to me to re-read it in light of Steve Blank’s Customer Development and the Problem Team in Lean Startups.

Stupid Mistake

The biggest error in Extreme Programming Explained is the implicit assumption that you have a technical team serving a single customer.

The lonely customer orbits a team of programmers

I had this picture in my mind because of two experiences. At a mutual fund company I had a customer who had been a customer service representative for seven years, a supervisor and trainer for three years, and then threatened to quit if the crummy old system wasn’t replaced. At a large manufacturing company I had a customer who had run a finance department for years, knew all the ins, outs and exceptions, and was willing to work very hard to keep up with the programmers.

The picture of a single person feeding expectations to a whole team of programmers is seductive. You don’t have to worry so much about disagreement in detail, and political disagreements are even rarer. You don’t have to worry about finding the appropriate expert to answer a question.

Don’t get me wrong. If you can find that one person who knows the whole domain, is willing to make quick decisions and fix them later, can speak to you both concretely and abstractly, and can put up with a room full of nerds you are likely to be successful. First, though, such folks are understandably rare. Second, this picture seems to exclude many people who now dedicate their talents to software development, like analysts, testers, and modelers.

It Gets Worse

The problem is compounded in XP Explained (and subsequent writings and conversations) by referring to the programmers when using the phrase “the team,” as in “the customer speaks to the team with one voice.” This usage always bothered me, but I didn’t know what to do about it.

Cracks Appear

The first inkling I had that “the team” shouldn’t mean just programmers came out of my experiences at Evant Solutions (evant.net). We (I’m a sometime coach and stock holder) have about ten programmers on (what we’ll call for nearly the last time) the team. But the product, a demand chain management tool for retailers, requires specialized knowledge of many different aspects of retailing. No one customer has sufficient knowledge or perspective to guide the programmers in implementing the whole system.

“The customer” consists of six product managers. One (I’ll call him “Jim” because that’s his name) is the uber-product manager, overseeing the competitive vision of the entire product. Working with him are five product managers specializing in aspects of retailing: assortment planning, purchase orders, inventory, and some other stuff I don’t understand even that well (contact Evant for useful details).

Evant chose a three week iteration, curiously beginning on Tuesday (Jim says, “Planning sucks and Monday sucks, why put them together?”) On Tuesday, the product managers present their stories to the programmers for tasking and estimation. Sometimes one product manager dominates the iteration, sometimes the stories are spread around, and sometimes they are shared. Curious. Even curiouser is the frequent appearance of fresh bruises and bandages on the product managers at the iteration planning meeting.

A Team Is Formed

What gives? Jim says,

The short of it is that we hold a pre-planning meeting before each cycle to discuss which use cases we want to attack. Usually, we have a theme/focus to each cycle that is provided by our clients (i.e., incorporating feedback from XYZ Inc. regarding planning) that makes the discussion around which use cases to select somewhat “non-toxic.” Although our process is very collaborative and democratic, my “uber” nature does make it easy to “break the tie” when we have competing requests.¹

Regardless of Monday’s disagreements, Tuesday morning the customer team presents their story choices to the development team with one voice. It is as if they agree, at least as far as the programmers can tell.

Stranger in a Strange Land

The second crack in my model of the lone customer orbiting “the team” came during a visit to Japan in April 2001. The Extreme Hour is an exercise invented by Peter Merel to simulate the dialog used to choose scope in an XP project. A group of eight people is split into four developers who draw pictures of a coffee maker, two customers who write stories about a coffee maker, and two testers who verify that the coffeemaker as drawn satisfies the stories.

For ten minutes the customers write stories and the developers estimate how long they will take to draw. Then comes the interesting part. In five minutes the customers have to choose which stories will go into the first release of the coffee maker based on the estimates on the stories and the developers’ estimate of their overall speed.

I say interesting, because the choosing phase always takes too long, at least a minute or two. The customers disagree on the relative priorities of the stories, they argue with the developers over estimates and speed, and they are reluctant to make a final decision until absolutely compelled to do so.

I gave a private XP lecture to a group of 20 programmers from Technologic Arts, the sponsor of my trip. The first phase of the exercise went as expected—they wrote a bunch of stories. The second phase was interesting.

Instead of six or seven minutes to pick the stories for the initial release, each of the teams was done in two minutes. Strange, but after all these were bright folks who had been studying XP for a while.

The next day I gave an all-day lecture to 200 programmers and project managers. My hosts (hi Marika and Yoshi!) insisted we could run the Extreme Hour with the whole group. I was unconvinced, but it was their show, so what the heck.

The attendees were sitting four to a table, four tables across. The easiest way to form the teams was to have every other row turn around. The backward-facing attendees were the customers and the forward-facing attendees were the developers (we skipped the testers for simplicity).

The first ten minutes went better than I expected. We had them work on a tea maker (although my translators told me later they would have preferred coffee since there are two words for tea and they didn’t know which one I meant). Every team wrote plenty of stories (with a little prompting). We were ready for the first release plan.

In a giant room, with 200 people who had never tried the exercise before, giving instructions through simultaneous translators (who were excellent, but still), the entire room, all 25 teams, had their release plan finished in, you guessed it, two minutes.

Westerners hearing this story often comment, “Sure. Japan is a hierarchical society. The senior customer decided and the others followed.” Au contraire, my ethnocentric friend. In the conversations I watched, every customer talked about the same amount. Body language was similar in the whole customer team. Without knowing Japanese I can’t tell for sure, but I’m guessing the four customers simply formed a team faster than I could recognize and got on with working together. Yoshihide Nagase comments,

Japan has many hierarchical styles. Software development in Japan is hierarchical, too. But manufacturing development (such as in Toyota, Sony, Epson and so on) uses small teams. Maybe attendees of your XP seminar here felt like these small teams, not the usual Japanese Software Engineering way.

The Last Straw

My identification of “the team” with “the programmers” finally died when I had the chance to visit a testing conference and a modeling conference in quick succession. In both places the primary question was, “I’d like to try this. Where do I fit into the XP picture?” As long as the XP picture contains a lone customer orbiting a team of programmers, the answer is “nowhere.” I know that many of the skills and attitudes of modelers and testers would be a huge asset on my teams. If they are right, then my XP picture must be wrong.

One Team

What if we redrew the picture to reflect what happens at Evant, and what I observed in Japan?

The new picture reminds me of American football teams. The offensive and defensive teams have different skills, values, and perspectives but they share a single goal, winning the game.

Where do our good testers and modelers fit in? On the Business team. Helping scout, write, slice, dice, and verify are everyone whose lives will be affected by the scope and quality of the released software:

• Analysts
• Representative users
• Testers
• Marketers
• Customer support
• Sales
• Modelers
• Interface designers that watch what real users do and help “pave the paths”
• Business strategists

Their jobs are different than they have been in the past. No longer can any one of these groups grab a phase to themselves, either before development starts or after it finishes.

Looked at from Here

Once I shifted to viewing one team, some problems I had been wrestling with for months came into focus. Martin Fowler reported a team at Thoughtworks where the programmers brought their workload and stress level under control with the Planning Game, but only at the expense of overloading the analysts. Analysts need liberation, too. ThoughtWorks has since been using teams of analysts and QA in its larger XP projects for a year or so now with reasonable success http://martinfowler.com/articles/planningXpIteration.html.

Another problem that came into focus for me was the growth of the customer team on the C3 project, XP’s spawning ground. At first there was only one customer. After a few months another payroll expert joined the team to help prepare test data. A few months later a third payroll expert joined. The One Team picture explains this. As the business sponsors discover how responsive the development team could be they chose to increase their business investment.

Far from being the norm, perhaps the original “one customer/many programmer” picture is weird. A picture with the teams more nearly balanced in size may be more healthy.

But Wait, There’s More

Our happy little family would be complete, if only we didn’t want to get paid. And if we always got along. And probably eleven other impossible things before breakfast.

I spoke at the University of Oregon CS commencement this year. One of my old professors, Andrzej Proskurowksi, heard the XP story and likened the picture above to a two-legged stool. And he’s absolutely right. There are questions that are outside of the scope of the people on the team as we’ve drawn it so far.

• How does the project get started?
• How is investment increased, reduced, or terminated?
• How are disagreements resolved that aren’t handled by business and development?
• How are relative priorities set between this team and all the other projects that need doing?

I would love to have a better name for the team that answers these questions. The only one I can think of threatens to unstopper the bottle into which we have just so laboriously stuffed the Demons Control, Hierarchy, and Certainty. But, my failings as a thinker being what they are, I’ll just have to call this, for the moment, the Management Team.

But I really mean “team”, not “manager” and certainly not “roomful of hens squabbling over too few grains of corn.” To scale XP practices to the next size of organization (up to about 150), the members of the management team must work together to solve problems at the scale of the whole organization, typically by breaking them into bite-sized chunks that can be chewed and swallowed by individual teams.

Being on the management team is no easy ride. XP Management is not there to Make Decisions, and certainly not there to Fix Things. Managers are there primarily to notice when the words and the deeds don’t match, to market and sell the achievements of the teams, and to make sure there aren’t obviously better ways to spend money.

In redrawing the picture, I’m forced to switch metaphors. If I draw three circles, whichever one ends up on top will think it’s in charge. If two are on top, whichever one ends up on the bottom will think it’s being oppressed. Circles just won’t cut it. However, Andrzej’s suggestion has merit:

I like this picture. First, the three legs are equal partners. Without the support of any one team, the stool collapses. Second, it’s an Aalto design, and I’m a big Aalto fan. Third, imagining the stool in use, the three sub-teams have to work together to withstand the pressure from the …, well, from above.

Making the Shift

I’ve been using “the team” to mean the whole team for a week or so now. Old habits die hard, but it’s starting to feel natural. If you want to try it, talk about “the team” to mean customers, programmers, and managers. Talk about the customer team, the development or programming team, and those clueless suits (just kidding, talk about the management team) when you need to discuss narrower concerns. Give it a week and see how it goes.

Some Predictions

Where will it end? I’m reminded of engineering driven startups, where engineers often form 80-90% of the employees. As these firms grow and mature, the proportion of engineers drops to something like 10-15%.

Will we see this as XP teams mature? Will we ever see a customer team of 10 marketers, domain experts, representative users, sales people, analysts, testers, and usability engineers feed stories and acceptance tests to 4 programmers with 3 managers? What would happen if there was such a team?

Roles

The division of the One Team into three sub-teams smells of taylorist division of labor. I can imagine someone reading this and saying, “Oh, I have to decide once and for all whether I’m a manager or a customer.” In practice, people move between the teams, sometimes even iteration-to-iteration. And once the team is clicking, the artificially hard divisions blur, and rightly so.

However, the social contract of work is different between the members of One XP Team. Before you can begin messing with the roles you have to get used to how they are different. Then you can begin experimenting while working together towards the ultimate goal: getting as much of the most valuable stuff done as possible by a given date.

Sidebar: Customer Team at Thoughtworks

Martin Fowler writes:

At ThoughtWorks the notion of “one team” makes a lot of sense. We often staff projects with our own analysts, who are often business experts. Indeed in some business sectors our analysts are more familiar with the specialized domain than our clients. QA is also obviously an agent of the customer, as indeed it was in the early days at C3.

Our largest XP-ish project has a full team of analysts and a full QA team—all as part of the overall project team. The analysts need to collaborate to present the stories with one voice to the programmers. They’re also a mixed bunch combining both business experts with pure analysts.

They’ve recently set out some of their conclusions about making the customer team work.

• They’ve missed having some kind of “big picture” to act as a road map
• They’ve found it hard to divide up functionality into suitable story-sized chunks
• They’ve found it frustrating to not give an indication to developers of which direction future function is likely to go
• They’ve found that specialized analysts are better at looking at the thorny details of exceptional cases – in other projects testers have reported a similar phenomenon.

The danger with an analyst group is always that they can end up being a communication barrier rather than a communication enabler. The notion of the single business expert customer helps prevent that, but I don’t think there’s any way to structurally avoid a barrier. The key lies in the attitude of the people involved. Particularly on the customer side of the team you have to build the roles around the people – not the other way around.

Certainly the programmer-centric attitude of XP has caused frustration. Part of XP’s guiding mission is to heal the rift between business and technology. For this to work we need to better understand the various aspects of the customer team. In many ways it’s a more complex team than the developer team. It’s also one where the techniques are less developed.