Another great night at the Extreme Tuesday Club where I met Chris Matts, a Business Analyst (or Agile Business Coach) who works for ThoughtWorks.  It was an interesting discussion about the role of an analyst in a XP/Agile project.  Chris views his role as helping the business customer and the development team get closer together and helping the developers learn more about the customers' domain problem.  This kind of thinking about software development practices is a key reason why I like the XP/Agile movements.

I'd heard about the great work Chris had done on a large project that was going off the rails.  By tracking close to the business issues he was able to influence the project being cancelled and restarted.  We spoke about how to influence projects when it's obvious they aren't going to be successful, the complexity that can be involved when the contract work depends on the project continuing and the personal integrity involved in sticking with a decision you believe in.

I was interested to find out more about how a Business Analyst fits into such an Agile-oriented work place.  To me one of the big gaps in the Extreme Programming methodology is the generic concept of 'The Customer'.  It's a great thing that a lightweight methodology exists that is pushing the importance of customer involvement, but to me XP is thin on the details of what's involved.  In XP Refactored the authors point out that the notion of the onsite customer is a difficult idea to achieve.  Most work places wont allow their best people to leave the workplace in order to sit alongside the development team.  Even if they did they aren't always able to effectively communicate with the team.

Chris' concept was that he understood the technology and the business domain knowledge.  He believed that one of his benefits was to bring the customer and the development team closer together.  He was more effective than just a customer because he was skilled in learning about the business problems and analysing the requirements for a solution. He believed he had a role to play in an Agile team by viewing his role as the Business Coach focussed on transferring his business knowledge through to the development team.

One of the techniques that Chris mentioned as being effective was having the customer draw the business model on a blank sheet of paper at each meeting.  They found this produced much better customer feedback than they received from the customer reviewing their diagrams.  Drawing and talking about the business model produced a greater involvement than someone simply reading and reviewing a document.

Chris had extended this idea further with the concept of producing documents as a way of learning more about the business himself, but not necessarily publishing or sharing those documents with the team.  A very 'Agile' perspective that says the value of the analysis is the impact it can have on the rest of the team.

Quite an interesting discussion developed around the concept of 'How People Learn' or how a Business Analyst could help the team learn about the business.  I take the 'constructivist' perspective which says people learn through constructing their own view of the world.  The key to learning is to engage people in thinking in order to develop more sophisticated connections between concepts.  Any activities that encourage people to actively think about topics and relationships between topics are good.   Drawing a diagram and talking about it are much more likely to engage someone in thinking than passively reading or reviewing a document.