- April 8, 2016
- Posted by: admin
- Category: Agile Methodology
Ever wondered what makes the Chennai Super Kings the most successful IPL team, although they don’t win tournaments every other year? Ever thought of why Leonardo di Caprio is considered one of the best actors of all time although he does not have a single Academy Award for best actor to his credit?
What makes these folks stand out? It is, but trying out new things, taking risks and doing so passionately and consistently. Welcome to the world of distributed agile, where consistent and passionate risk taking yields big reward.
What is distributed agile, then? Distributed Agile involves teams working across different locations of the world. They work together across time zones, different locations, and sometimes across glaringly different cultures. And they succeed. Their success sometimes is many many many times more than a conventional Agile project. Does that not sound extremely powerful and successful?
The Virtual Organization
The client team and the development team no longer function as two teams. They work towards a common goal, so they work together as one team. In distributed agile, this collaboration of teams world over is called the virtual organization. Let’s say a project runs in Europe and India: a project manager and three developers may work out of Europe, and the remaining team of analysts, developers and testers may work out of India. All these people together form a virtual organization, that spans across cultures, time zones and workplaces.
They are self organized and extremely committed to one goal
These teams are fully equipped with all they need to execute a project – be it the analysis skill, the ability to develop iteratively or even test the juice out of their product. This team is self – organized despite sitting at different locations. They attend the stand up at the same time, agree on an iteration’s plan and work toward smaller yet impactful releases. There is no political agenda, and personal egos are given a good farewell when the project is on. Hierarchy is not applicable either.
They trust each other
Without trust in each other, this team can never go forward to implement a project. Above and beyond perceptions about ethnicity and race, this is team works as one people, one race, one team. The trust is so immense that even teams within their respective organizations are surprised by the degree of camaraderie.
This trust obviously is not built overnight. It will take a short while (maybe a couple of iterations, with some working software) for the clients to trust the development team. Come one release addressing the critical pain points of the clients’ existing working model, the trust is sure to have creeped in.
They are outright honest about their plans
These teams talk about their mission, vision, good, bad, upcomings and shortcomings with their hearts on their sleeves- they are honest, and always accommodative. They share a common goal, and how each member of the team takes it forward to reach that goal is upto each individual within the team. They do not see the point in beating around the bush, and are mostly to the point. Their meetings are objective, and feedback is quick and honest, while also not being blunt and pointless.
They communicate like it’s judgement day tomorrow!
The biggest challenge as well as the best thing about the distributed team is the sheer volume of communication that is required to run a project. Onsite and offshore teams communicate with each everyday, and sometimes more than once a day to ensure smooth running of the project. The project team is always concerned about being on the same page about requirements, goals and project end state, and hence they over communicate, albeit all to the advantage of the project.
All that sounded ideal. Even fairy-tale-ish. However is that for real? While all the above said are traits of a successful distributed agile team, and most of teams stick to the quoted principles as much as possible, nothing ever goes 100% as planned. So what are the challenges these teams face?
Client buy -in
While clients will eventually trust the development team over a period of time, it is not necessary for them to instantly give in to everything the developers say. Let’s consider a classic case of a complicated requirement thrown in by the client a few weeks before a major release. If the developers think that only a portion of this requirement can be completed, then this conversation is going to be a difficult one to do. Buy-in becomes difficult, and adding to it is the factor of physical proximity.
Client visibility is a key factor in executing a distributed project. While trust and communication are a clear given for the distributed team, proximity to the client matters. Rotating team members from offshore to onsite, and vice versa will help in giving more visibility to the team about the key members in the client site, thus strengthening trust and paving way for buy-ins. Also, doing frequent and short requirements discovery, and regular functionality showcases with the clients can help the pulse of all team members stay active and high.
The first and basic mistake everyone makes is to make an assumption that English is everyone’s native tongue. In fact, it is nobody’s native tongue. Especially when working with European clients, language can be a big barrier. However, it is not just restricted to non-English speakers.
Even American clients have difficulties in understanding Indian development teams. A good way to build rapport and make sure clients do not misunderstand or misquote, is to use direct video conference communication or calls, or instant messaging. Emails can be used as summary, just to ensure that everyone is on the same page.
This might sound like something that developers can get sorted in a couple of iterations, but working with setting up infrastructure and maintaining it in a distributed team can be much more challenging than that.
For starters, access to a client’s network and getting a VPN connection could take longer than expected. If a team of 20 members are trying to access a network somewhere in the hills of Europe via a VPN, then there could be delays and time lags, that actually lengthen the work day of development teams offshore.
The cultural differences between client teams and offshore development teams is a learning curve. While this is not a critical challenge, during the initial stages of the project it can be a nagging factor that will irritate both parties. The clients may not understand the offshore team’s culture of say working overtime.
The offshore team may not understand the client team’s culture of leaving on the stroke of 5 p.m. There needs to be a period to normalize and cool off these tensions before all is set for the project to run smooth, but this is not a constant worry at all.
In summary, distributed agile is challenging but a lot of fun. Given there are experienced co-ordinators who enforce strict discipline about agile processes, and self-organized teams who ensure test-driven development, chances are slim that a distributed agile project will fail.