By Mark Rickmeier and Jane Robarts - 6 July 2008
In the classic movie Jaws, an unusual and ill prepared trio set out to capture and kill a shark that is preying on the local (and apparently tasty) New England tourists. Tempted by fame, reward, and their desire to bring safety to the waters these sailors head out into the deep not really appreciating their situation. They draw up plans to hunt their prey assuming that this monster is like all other sharks they’ve faced before, greatly underestimating their challenge. Trusting that what has worked in the past will work again, they decide to use typical tools including Hooper’s trusty shark cage, which gets destroyed almost as soon as it’s lowered into the water. They travel in their tiny boat, only to find that it too will quickly become shark bait. Essentially they go after a new kind of challenge with the same old approach, and they’re lucky to only lose a third of the crew. Companies today are similarly tempted to venture out into the unknown and take on the challenges of distributed development. It’s a beast they haven’t challenged before, but the temptation to try is too great to resist, because distributed development appears to offer two clear advantages. First, companies want to realize cost savings. Having been sold on the concept of lower marginal rates per person, they are convinced there is money to be saved. Second, they are interested in improving their turn-around time by scheduling development activities “around the clock.” IT executives are told that this can pay large dividends: critical defects found in production during the business day can be resolved overnight by an offshore team, and deployed prior to the start of the next business day.
This interest can turn into skepticism when projects become larger and more complex. Given these uncertainties, IT executives often turn to Agile or Scrum methodologies to reduce their risk when delivering these kinds of complex systems. These methodologies allow teams adapt to changing requirements, quickly respond to stakeholder feedback, and deliver working software faster, often in shorter incremental releases. However, they also require a lot of informal and high bandwidth communication between team members that is not always possible in a distributed setting. The Agile Manifesto itself calls out several key principles, many of which are directly challenged by a distributed approach:
- Individuals and interactions over process and tools
- Customer collaboration over comprehensive documentation
- Responding to change over following a plan
Several development best practices face constraints within the distributed model. Developer pairing is considerably less effective without face to face interaction between team members. The limited overlap hours between distributed locations greatly reduces collaboration time, lengthens feedback loops, and reduces the team’s ability to collectively resolve issues. Communication barriers can foster trust issues between the teams, sometimes leading to “us vs. them” mentalities and a breakdown in the effectiveness of the limited communication that is possible. Lastly, self governing teams that rely on team meetings like retrospectives and daily stand ups can tend to receive input from only one of the distributed groups – either ignoring or not hearing the other team’s inputs at all.
All too often, project teams will jump into the distributed waters having been sold on the advantages of distribution without fully appreciating the challenges that await them. (Experienced practitioners can almost hear the John Williams soundtrack slowly building in the background: duh-duh. Duh-duh.) If a distributed project is approached with the same project management style, the same development practices, and the typical “roles and responsibilities” of collocated agile teams, there will be blood in the water within the first month. To drive distributed projects to success, and to realize the benefits of the distributed development model, the project team must take a modified approach.
As companies approach this challenge, an important first step is to realize that there are hidden costs: distributed development is not all savings. These projects require a larger amount of infrastructure to support the offshore effort, not only in physical hardware and software, but additional management and communication infrastructure as well. Distributed project teams will always be larger than their collocated counterparts as duplicated roles such as analysts and project managers are required to keep the two teams operating and communicating effectively. Furthermore, team members must put more time and effort into their communication to make up for the distance created in the distributed setting. These costs can be greatly underestimated and the cost savings associated with distribution can therefore be inflated.
It is also important to realize that although distributed delivery can offer certain advantages, not all projects are equally suited for distribution: some carry more risks than others. A typical project risk, such as complex integration with third party systems, will be more greatly magnified on distributed projects. In addition, there are new risks that must be dealt with, such as the inability to easily transfer knowledge. IT executives must decide if the benefits outweigh the risks before deciding to move forward.
Finally, when the team has weighed the risks and approximated the cost, they’ll still need to adjust their plans and strategy before they can have any expectation of success. To overcome communications barriers, technical challenges, and cultural hurdles, teams often have to increase contingency in the overall release plan to accommodate the associated increase in risks with distribution.
Distributed development can be a very effective and rewarding way to deliver software. It has been proven to work not only on small projects, but also on large, complex, enterprise applications. But it requires the right kind of preparation, a realistic approach to the risks and challenges the teams will face, and an understanding that what works for local teams will not always work for distributed ones.
Unless, of course, you’re willing to make a third of your team shark bait.
About Mark Rickmeier: Mark has 8 years' experience as a quality assurance tester, business analyst, iteration manager, Scrum master and project manager working on large scale enterprise applications. He has extensive distributed development experience working with project teams in Australia, India, China, Canada, the UK, and the US. His industry background includes equipment leasing, retail, insurance, healthcare and retail banking. He is currently a project manager specializing in Agile transformation and project governance with a focus on metrics and measurement.
About Jane Robarts: Jane has over 10 years of experience in custom development of enterprise applications as a developer, analyst, project manager, and coach. She has consulted on and managed projects in India, China, the UK, the US, Australia and Canada. Jane has spent most of the last several years coaching distributed teams and working directly on distributed Agile delivery projects both onshore and offshore. She has also developed and delivered many sessions on agile delivery to a variety of audiences.
No comments:
Post a Comment