Deceptively small stories??

For sometime now I have got the feedback from developers, that the stories I write look small but have loads of work to be actually done and they get under estimated during the Iteration Planning Meeting. Now when I asked for a way in which I could make the story look as big as it is, I was given the idea of putting tasks in the story.

I have used this method for sometime now and I find myself writing things like:

TASK 1: When the user clicks "OK" an empty Word template should be uploaded to the server and then the same file should be opened for editing

whereas I would have generally written:

Clicking "OK" should open MS Word with an empty template so that the user can edit the contents.

While this puts implementation into the story and makes the story really bulky, it seems to really help the devs and may even be of help to a technically inclined client or the client's IT department which is going to take over the maintenance.

I think distributed agile makes us take many such deviations from the pure form of agile ideas we have read about. Most of these are justifiable in terms of the trade-off between concepts like "minimum documentation" and "transparency / knowledge sharing". After all isn't agile about doing whatever it takes to quickly deliver value to the customer??

Communication Patterns

Incidentally my earlier post was about how Distributed Agile works. My unexpectedly long web silence was infact due to the current DA project that I am working on.

One interesting thing that we get to observe is how the communication patterns change over time, amongst the local team and also with the distributed team.

There are few specific things that I have observed during the last 5 months on this project, which I would like to bring up here. All of these relate to the communication that happens across oceans.

Overview
Last few months I have been busy on a Distributed Agile project. I feel obliged to put down my observations of the changes in the way communication takes place between distributed teams.

The typical setting renders the following arrangement:

1. Client (since this is about communication we restrict clients to be the people who give requirements. NOT sponsors or end-users)
   
2. On-site BAs
3. Delivery Team. This is the larger team that does the development and consists of BAs, QAs, Devs and an IM/PM
   

Note that the patterns of communication enlisted here use the above setting as a base. They may not be similar to the way distributed teams work when actual delivery is distributed.(That'll be covered in part 2, if there is one)

Communication
Communication is arguably the most emphasized practice in Agile methodologies. A perfect agile team will communicate in these ways (in order of preference)
- face to face
- video conferences
- voice conferences
- email or other documentation.

Small co-located teams will easily handle communication amongst themselves and with the client. It is the larger teams that find it difficult to manage without emails / documents and it gets worse when the teams are distributed and have to work with each other across seas.

This is a collation of my experiences about how the communication patterns evolve and affect the project.

Context blues
When the project begins, a very small number of people have had a chance to meet the client face to face. To make things worse, the team that ramps up, and starts to increasingly communicate with the client, is the team which is going to deliver the software. This is the 3rd entity listed in the overview.

The BAs in the ramping team lack 3 things that makes communication effective. These are listed below in order of importance.

Business Context
The first thing that the delivery team lacks is the business context in which the solution is to be provided. The Business Objective behind this project and the criticality of the project success are the fundamental things that let the team organize it's thoughts and actions towards a common goal which is more or less inline with the client's expectations.

Client Context
The second thing that hampers effective communication is the lack of knowledge of who the client is. It is of high importance that the delivery team is aware of the client's position and the stake that he has in success of the project.

Client
Knowing what the client is like, is also very important to be able to communicate effectively. Having met the client personally impacts the effectiveness of communication a lot.

This is the first phase of the communication with the on-site team. Another interesting feature of this phase is the importance of the on-site BAs. The on-site BAs do not lack any of the things listed above, which makes them many folds more productive and hence important to the project.

Infrastructure blues
This is the second phase of the communication evolution in a distributed agile project. This is the phase where the delivery team reacts to the earlier phase of lack of context. The immediate solution which is put forth is to strengthen the communication infrastructure so as to get as "close" to the client as possible. By the order of preference given above, the team rules out the face to face communication and promptly moves towards video and voice conferencing solutions.

This phase features infrastructure failures which are acted upon with varying degrees of success and in the end, stabilize.

Delivery team amnesia
This phase is a result of the rising ease in communication with the client. The delivery team now has ease access to the client. It also has most of the necessary context of the project. The development also starts showing real progress by this time and hence the delivery team now gains importance. It has to get critical questions answered, give development support and show progress via showcases.

All this action tends to give the delivery team intermittent amnesia about the existence of the on-site BAs. This is a pattern that continues in varying degrees throughout the project. For countering this particular problem the team comes up with a schedule to communicate with the on-site BAs. This turns out to be a decent solution but it fails every time there is a change in the schedule. Every change then takes time to stabilize.

Guests and parties
By this time the delivery team is using the communication infrastructure to the full extent. But there is still some context that's missing and the delivery team starts becoming more and more aware of this fact. There is a strong strong need to talk to the client face to face.

The project has more or less stabilized by this time and so the cross-pollination as well as client visits to the delivery location take place. Many important decisions, sessions, context & knowledge sharing happens during these visits. There are invariably some tricky areas/issues to be discussed during these sessions. Making the most of these sessions is one responsibility that the BAs should really handle well.

Another amazing effect of the visits is the trust that builds between the client and the delivery team because now the client actually sees the work going on and progress being made. This is a good opportunity for the delivery team to bring to the clients' notice, the implications of their actions (or inaction). Signing off / giving feedback on functionality that has been developed is a major participation required from the client. Demonstrating how this feedback is taken and worked upon helps the delivery team to considerable extents.

These visits also enable teams members to spend more informal time with the client. Team outings and sight-seeing are important parts of these visits.


Stabilization
This is the phase after the client visits are over. Whatever major issues were to be discussed have been discussed and decisions reached (well, almost). This is the golden phase in the project where everyone is much more clear about what they need to do and when to do it and that includes the client.

This is the phase to be reached by a distributed agile project as soon as possible. It is generally not possible to jump these phases and get to the stabilization phase early. It is however, quite helpful to understand that these phases will come and will need to be handled.