My first distributed delivery gig!

I just rolled off from my first distributed delivery gig with Thought works. I had a great time working with the team and it was also a great learning experience for me.
The client had its head quarters in Perth (they also had another office in Melbourne as well) and thus I was sent there to help out with some analysis work. The delivery team consisted of a total of 7 members of which a team of 5 (4 developers and one tester) were based in our TW’s Melbourne office and 2 of us (I and another Thought Worker who played the role of an Iteration Manager) based in Perth.

In this blog, I shall mainly discuss the approach that we followed to successfully deliver the first phase of the project.

Our approach

Daily stand-up meetings – We had 2 stand-ups every day. The first one (held every morning) was an internal stand-up meeting and then one in the afternoon involving the whole team (through a teleconference facility between Perth & Melbourne)

Analysis sessions – Almost every day, I used to organize at least 2 analysis sessions. The morning session was used mainly for story analysis and I had a story sign-off session in the afternoon.

Workshops - I used to conduct a workshop's only when I had to get a broad consensus from the clients. I faced such a situation when finalizing the new design for the application. For this, I could not just rely on the Subject Matter Expert assigned for that Iteration as it affected all the users. Thus, I had to get all the main stakeholders into the same room and conduct a workshop using 'hi-fi' design prototypes and demonstrations of the application(using firebug plug-in to modify the code on the go). This helped me to gain consensus amongst all users and also finalize the design.

Story kick-offs & hand-over – Before the developers picked up any story for development, we used to have a kick-off meeting where the developers would call me up to discuss the same. Apart from the implicit benefit of gaining more knowledge of the requirement, it also used to provide me with a chance to check if the developers had picked the right story according to the priority.

Triage – We used to have a weekly story prioritization session (which we called as Triage). Being an Agile project, this is a key mechanism to deliver value to the customer. Re-prioritization on a regular basis helps provide the best value for money to the clients.

Iteration kick-offs – We had a 2 week iteration and at the beginning of each iteration, we used to have a kick-off session in which we discussed the stories which were currently being developed and then the analysts would discuss details for those stories which were prioritized highest within the backlog and thus ready to be picked up for that particular iteration.

Showcases & Walk throughs – At the end of each iteration, we used to conduct a showcase where we demonstrated the latest version of the application being developed (usually the Subject Matter Expert from the client demonstrated most of the functionality which were developed within that iteration – this gave them a feeling of ownership). Each iteration, we also conducted walkthroughs which was a more hands on approach for the users to test the latest additions to the application. This involved the users actually logging into the application and trying out individual functionalities. I think that this approach is a fantastic ‘Change Management’ initiative and helps get an acceptance from the actual users even before the application has been deployed.

In my next blog, I shall discuss some of the tools that helped me dealing with the distributed nature of the project.