Agile development, structured workshops for knowledge sharing

At work we are using a form of Extreme Programming. In XP requirements are fed to development is through the use of interation and release planning. The system is broken down into stories that describes what the user requires to do with the system. This commnicates the customer's requirements to the development. However problems can arise communicating specialised domain knowedge to the development team, and domain implementation knowledge to the customer and operations.

Existing Knowledge Transfer

Within the development Often new concepts, architectual spikes and other information is known or researched by one member of the development team. In this case a brown bag presentation is done. This is often a lunchtime session where the information is presented to the group.

Domain Knowledge

One problem we encounter even with pairing is sharing domain knowledge, where more context around the problem is needed for the right solution to be implemented. To improve the situation we have held workshops between a number of people in the business:

The Players

Developers

One thing that you might find with agile, once the system gets big, is pairing is not sufficient to share knowledge. Occasionally we've come accross, mid-project, islands of knowledge occuring. Some people in the agile community talk about a project's Bus Number; this is the number of people that could get hit by a bus before the project suffers. We have been working in an Agile Team here for some time, although our Bus Number is high, it isn't enormous. Domain experts do arise due to the mixed talents in the team. Sometimes pairing is not sufficient for knowledge sharing. Especially in a large organisation.

(Proxy) Customer

In a field like telecomminications which can often move fast, you may have a number of customers. Each customer wanting a different schedule and set of features, also the solution that the customer is willing to except, because of money involved might not be best fit for the future network architecture. Agile, particularly XP is customer driven. In these cases a Proxy Customer is created that makes a judgement of where the product should go next. He talks to the customers arranging when customers will get their features and balances that view with how the company wants the architecture to evolve.

Workshop Structure

The workshops are structured, with a set flow. This is based on the seven steps of RaPiD7 a technique for requirements gathering which is used for producing specifications in mobile companies. The seven in RaPiD7 steps are:

1. Preparation Phase
2. Kick-off Phase
3. Idea gathering Phase
4. Analysing Idea Phase
5. Detailed Design Phase
6. Decision Making Phase
7. Closing Phase