Dec 14, 2006
How do you practice Extreme Programming when your customer has no time or bandwidth for contact hands-on communication?
As an XP project manager, I obviously have strong bias towards this methodology. I feel very passionate about XP values and do my best to help people apply XP practices. It is not that I haven’t tried using other approaches. I did that and found that agile solutions worked much better than their traditional counterparts. However, I also like our customers a lot and, again, it is not just about money they pay us. They have great ideas and working with them provides an enjoyable and challenging experience. But here’s a problem: XP requires the customer to be involved very closely. An ideal XP customer works closely together with the development team, is an expert in the application’s problem domain, can write user stories that developers can understand, and can even code acceptance tests for us! Let’s face it: there are very few customers who have the skills and time to do all that. So what do we do when the team wants to use XP, but the customer is not able to participate? In other words, what happens when an irresistible force meets an immovable object?
I first encountered this problem in the fall of 2004. We were starting a project for a large multinational client, with one of their senior executives as the key customer/point of contact. Asking him to be always available was a joke. We couldn’t expect him to write acceptance tests either, and the requirements we received from him didn’t look like user stories at all. On the other hand, the customer wanted quick and early releases, was interested in minimizing the cost of change, and what’s most important, the whole situation with the product was highly emergent: no one knew what exactly it was that we were going to build. The project wasn’t really suitable for a non-agile process.
This was clearly going to be tough. But, as usual, we decided to go with the simplest solution that could possibly work. We agreed to use XP, but decided that we were going to “fill in the blanks” for the customer and play their role. The project manager started writing user stories, and QA engineers created the automated acceptance test suite. The approach worked amazingly well: we delivered 18 releases over 2 years, the team size increased three times, and the number of users of our system is 15 times more now than we expected then!
The biggest problems were actually internal. The team was accustomed to communicating directly with the customer. People didn’t believe this to be “the true XP”. At least, we were lucky to start receiving real users’ feedback fairly early I the process, so creating a feeling of the end-user involvement was not that hard. Still, we needed a good metaphor describing the idea to all participants. For a while, we called it “a traditional interface onto an Agile project”. That worked, but still sounded like a compromise. Then we coined the term “Guerrilla XP”. Essentially, Guerrilla XP is a systemic way of implementing XP without one of its main pre-requisites, the customer’s hands-on involvement. “Guerilla” doesn’t mean it should be implemented without the customer’s approval. It doesn’t mean you “don’t need” the customer – it simply means that someone else should take on the customer’s role. What is also means is that you should try to make the whole process more customer-friendly.
We have tried several different setups to deal with these circumstances and still produce valuable software for the customer. Now, 26 months later, I am happy to report that Guerilla XP is working. In general, however, this approach requires more devotion from the whole team than the regular variety of XP, particularly from the team manager. It is the manager’s responsibility in this situation to become the available domain expert who is always available to the team (instead of the absent customer), which takes a lot of learning. The team manager should also find the time to write user stories. (The alternative would be to have a separate person on the team for requirement management; in my opinion, that only makes sense for teams of medium and large size.) However, as hard at it is, the results are worth it. We have completed several projects using Guerrilla XP, and managed to make both the team and the customer happy.
So what happens when an irresistible force meets an immovable object? In the Agile universe, they both win!