Darrell Norton's Blog [MVP]

Fill in description here...

Development team facade

One of Extreme Programming's practices is OnSite Customer (also see Martin Fowler's definition of OnsiteCustomer).

Although it is good if each programmer can constantly ask questions of the customer whenever they need to, it is not good if the customer has the same ability. Anytime the customer wants to ask a question, just being able to call up a developer kills that developers concentration, subsequently killing his productivity. On the other hand, if the developer is able to get an immediate answer to his question, it maximizes productivity.

The solution is to designate someone to run "interference" for the developers. Who runs this interference? In Brooks' The Mythical Man-Month, the role is assumed by the copilot, who attends all meetings, answers all technical questions, and acts as the general technical answer guru for the project. This leaves the surgeon (chief programmer) with all his time devoted to programming. In my own experience, I was the technical lead and ran interference for my team. Although I might not have made much of a contribution to our body of code directly on some days, my real accomplishment was enabling the other 8 developers to contribute 100 percent every day (8 * 100% is much more than 9 * 80%).

So what this really is is a facade for the development team. The customer is supposed to speak with one voice, and they speak to one person who will get them the answer or pass it along to a developer. Does this then break the facade? I don't think that a developer has to go through the team spokesperson to communicate with the customer, but it helps. In our case, it avoided anyone calling a developer back or stopping by our work area and standing over our shoulders for hours. I don't tend to think of email as a distraction, since you can just not check it. You might argue that most phones can have their ring disabled. Most can, but I like to keep the phone as an option for extreme development emergencies, such as when the CEO puts you on the spot in the middle of a seemingly innocent status meeting.

Devoted readers of Martin Fowler's bliki will note that in PleasingTheCustomer it says that a major source of enjoyment is direct developer-customer interaction. While I certainly agree with this, I do not think that it requires 100 percent all-day everyday direct interaction. Sometimes you just need to get things done... alone. Completed iterations, milestone deliveries, or whatever progression of steps your project goes through, are excellent times for everyone (business people and developers) to get together and party. In my experience this is usually enough, but if there needs to be more interaction to chase down a troublesome and elusive bug, then so be it. As always in agile development, people over process.

Published Aug 20 2003, 07:28 PM by darrell

Comments

Alan Dean said:

I disagree!
-------------
In a team with a ratio of less than 1:1 customers (or proxy customers) to developer (or developer pair) then it is difficult to fully integrate the team.

But here is a thing, my most productive development project was pre-XP (or at least before I knew of it) in 1997. In that project I did 'pair' programming - but with the customer as my pair! We had three months to ship a complete rewrite of the product - and it could not slip as it was to be rolled out at an international conference. Btw this is why we completely restarted the product - it is often easier to do fresh greenfield dev than to wallow in fundamentally broken code.

There were three of us on the project. Customer, tester and me. I would dev with the customer *right* next to me - "you mean like this?", "what should I do if?" etc. and approx every hour I would release new versions to my tester (unfortunately I had not heard of test-first at this point). He would exercise his automated tests on old code, test the new and extend his automated test suite.

The velocity achieved was astounding. Truly astounding. And here is the real gotcha - it is the only code that I have ever released that was defect-free from public release. I'm serious. DEFECT-FREE! Not a single one. And another curiosity - there were very few change requests or feature requests. Our customers looked at it as a stable, dependable product that met a need and that 'did exactly what it said on the tin'.

I agree!
---------
If you haven't got a golden ratio (see above), then I can see the benefit of having an intermediary to avoid friction. Incoming requests from the customer can be routed to the appropriate developer (pair). But, my observation is that a Factory pattern is more appropriate - the developer (pair) is served up to the customer as appropriate (say, out of Golden Hours). This is because direct communication is more effective than proxied communication via an intermediary.

# September 22, 2003 8:06 AM

Darrell said:

My initial thoughts are that you did have a very high ratio of customers:developers (1:1). Ours was something more like 1:10, and requirements analysts:developers was 3:2. Plus we were operating in a somewhat agile manner, and the requirements group and testers etc were not.

I agree that the more "hops" communication takes, the more lossy it is. Direct communication is preferred, but even in my just completed project, asking someone else on my team and funneling communication through the tech lead avoided some repeated questions (I'm a newbie to my current company's client).

It could also be the difficulty in the area of interest. Less complex topics (relative to the people involved!) work fine through an intermediary without too much loss, whereas more complex subjects need to be end user-to-end developer.

# September 22, 2003 5:21 PM