Distributed Agile presentation at the Round Table CTO meet
Recently I met Mr. Joel Adams, CEO of Devon Consulting, at the Agile Philly user group. He organizes a meeting every month for some CTOs in the Philadelphia area. He invited me to one of these meeting and present my experiences with distributed agile. I accepted the invitation and today I spent 1.5 hours with the group discussing about distributed development and how some agile practices help distributed software development.
The discussion was initially scheduled for 45 mins, but as usual we overshot the time.
I started off with a brief background about myself. Spoke about the companies and the kind of projects I have worked for. I also introduced ASCI [Agile Software Community of India].
I thought a good way to start this discussion would be to have a common understanding about distributed development. Hence I started off with a brief definition of distributed development and why companies like distributed development
What is distributed development?
Software teams working on the same project separated by Distance or Time Zone or Culture
What are the advantages of distributed development?
2. Specialized talent : both technical and domain knowledge
3. Follow the Sun
4. Global Presence
After setting the context, I went on to share some of my distributed agile project specific details, like the team sizes and their structures, length of our iterations, communication patterns, agile practices we followed, scoping and release, configuration management, evolution of agile practices, challenges on the project and how we addressed them, how did we build the trust and finally what the customer had to say when we were leaving.
The obvious big question is:
What makes distributed development challenging?
1. Decrease in communication bandwidth
2. lack of visibility into project status
3. Configuration management
4. Art of Command and Control structure
Everyone seems to talk about these points. But I think there is something more significant.
1. I think lack of trust is most important challenge. Working with a team sitting on the other side of the global, whom you have never seen nor met leads to this challenge. If you would trust the team, communication and visibility would not be such a big issue. Why would you need command and control structure if you have a self organized team whom you trust?
2. Loss of context is the second most important challenge. If one does not understand what problem they are really try to solve, it can be very difficult to deliver the right solution. Most often in a distributed project all the decisions are taken onsite and the offsite teams are ordered to implement the solution given to them. Implementing the solution without the technical and business context is a big red flag.
3. Not considering offsite teams as equal stakeholders in the project is a recipe for disaster. One of the biggest misconceptions is that offsite team members only care about their pay cheques. Based on my experience I can tell, they care, if not more, at least as much as the onsite team about successful delivery of quality software solution.
4. One point of contact and abstract or data hiding is not always a wise decision.
If one considers the Agile Manifesto,
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
There is nothing in the manifesto which says distributed teams are not possible. There are some challenges with the last two values on a distributed project. But most of the agile practices can really benefit distributed teams. Agile can really help build empowered, self organized teams. This can be such a big relief to organizations thinking about distributed development.
Since this was the first discussion, we could not get into details. There were interesting questions about communication, visibility and trust. People were also curious to know about the software market in India and attrition rate in India. There was an interesting question on “defining done” and some kind of metrics definition in the contract itself while outsourcing.
Any other thoughts?