[POC] On-Site Customer or On-Site Team?

At its core, agile software development is about delivering (more) value to the customer. But that means close cooperation between the customer and the development team.

“A real customer must sit with the team, available to answer questions, resolve disputes, and set small-scale priorities. By “real customer” I mean someone who will really use the system when it is in production. If you are building a customer service system, the customer will be a customer service representative. If you are building a bond trading system, the customer will be a bond trader.”

quoted from Kent Beck’s first edition of “Extreme Programming Explained: Embrace Change” published in 1999

Projects of any significant size will require a full time commitment from the customer.

Software development relies heavily on cooperation and collaboration. Distance makes it more difficult. Hence, the wish to have all required skills and the customer on the team, at best in the same office, all the time.

From our experience, it’s very difficult to get an expert customer within the team on a full-time basis. Even more since that person would need excellent Product Owner skills as well and have the power and authority to make decisions on the spot.

I’ve seen the following approaches succeed:

1. The entire team moves to the customer site, making it easy for the customer to be with the team. However, the larger the project, the more space is needed for all the people. Often times, that space is not available.

2. New office space is rented, the customer and the software development team move into the new office: neither at the customer’s site nor at the developer’s site, uncomfortable for both, at least at the beginning.

3. Product owners get to the developer’s site every week for a few days.

At Cloudflight, we don’t like the first approach. Why? Software Development is a “Cooperative Game”. We have over 100 projects running at any time, with new technologies and frameworks in several of them. We want our learnings to spread not just within the individual teams, but across all teams at Cloudflight. If every team moved to their customer’s site, there could be little exchange between those Cloudflight teams. Hence, little learning from each other. Consequently, we would become less valuable over time for our customers. Therefore, we don’t want to have our teams move to the customers’ sites 5 days a week for extended periods of time.

Unexpected Learning: It may bad to be available for each other all the time.

If the customer is available all the time, a software developer may just ask every little question instead of thinking it through by himself. On the other hand, the customer might go unprepared into meetings. Some people palaver a lot – thereby wasting other people’s time, etc.

We have seen that being physically (or remotely) close to each other for a few days per week may be more productive and efficient than being around all the time.

Important conversations still do take place. There’s enough time for generating ideas and brainstorming, as well as for working out designs, concepts, and ideas. Meetings are well prepared. The time together is considered quality time. Everybody strives to make best use of it.

In the end, it’s not a question of “on-site customer” (i.e. the customer getting to the team) or “on-site team” (i.e. the developers getting to the customer), but a question of where to meet.