"Flexible" is a word that's rarely applied to the traditional waterfall software-development process, which may be one reason traditional development methods appear in many cases to be taking a back seat to Agile development, which promises quicker and more iterative development cycles.
Federal CIO Vivek Kundra is one high-profile fan of Agile development. In a recent report, Forrester Research analyst Mary Gerush stressed the need for business analysts to familiarize themselves with Agile methods due to its increasing popularity.
Increased collaboration between business users and developers is a key requirement of Agile development. That's a hurdle for many organizations with in-house development teams, an even bigger one for organizations with distributed teams, and a potentially huge one for those who use offshore development resources.
With that in mind, I was interested to see a blog post by Peter DeYoe that includes 12 lessons learned from an Agile development project with an onshore/offshore team. The big takeaway: Such projects require "a greater degree of management and communication than we would normally apply," writes DeYoe. I'm sharing half of DeYoe's points here. I encourage you to read his excellent post for the remaining half-dozen. I am also including links to other articles on the same topic, provided by both DeYoe and some of his readers.
The communications theme is a constant through all 12 points. As one of DeYoe's readers notes:
... Clearly this calls for environments that have strong practices in collaboration. This can only be supported by having weaved a set of tools that unify the modes of communication and sharing of information (design, plan and test documents). You share a "single pane of glass" as the team board across multiple time zones and coordinate your meetings to a common time-this is needed no matter how dispersed the team is. The one issue is that you can't walk down the corridor to resolve issue/conflict over a story. This requires the team to work at achieving clarity in their communications-a practice one wants from a team whether collocated or distributed. ...
Half of DeYoe's lessons:
Lesson One: To increase communication and team cohesiveness, try to ensure an overlap of at least two hours between the two teams' work days. As a commenter noted, this is easier to do for teams in the Eastern United States and Western Europe than for those in the Western United States when working with Indian developers.
Lesson Two: Create a repository and collaboration site, which will be used for specifications, test cases and discussions. DeYoe's team, which had developers and testers in India, and a Scrum Master, business analyst, user interface designer and product owner in the United States, used Microsoft's SharePoint as its repository. Developer Martin Fowler, in an article on onshore/offshore Agile development that DeYoe linked to, suggests using a wiki for this purpose since they are simple to use, easy to set up and can be accessed via any browser.
Lesson Four: Implement Web conferencing to create a sense of proximity. DeYoe's team used it on a daily basis. As I wrote earlier this year, Web conferencing is winning lots of fans among companies using it to trim travel their travel budgets and give employees a break from productivity-sapping travel.
Lesson Seven: Shorten your Sprints (Agile lingo for development cycles). Shortening Sprints from the usual four weeks to two helped DeYoe's team more easily make needed course corrections and facilitated greater communication of requirements, more accurate status reporting and more meaningful reviews with the customer.
Lesson Nine: If possible, the Scrum Master (project leader) should speak the languages of both development teams. Writes DeYoe: "The more they understand the language and culture of the dual teams, the greater the communication flow and understanding of the project requirements."
Lesson Twelve: Make sure the offshore team is properly trained in Scrum and specifically in your team's particular implementation of Scrum. DeYoe writes it is "worth the cost and time to travel to the offshore site, get to know the teams and properly train them for one or two Sprints to ensure that all expectations and processes are well understood by the offshore team."
Fowler's employer, ThoughtWorks, sends U.S. analysts to India to communicate both technical requirements and business specifications, he writes in his article. These "ambassadors" help lend business context to the offshore team and also share information that might not have been deemed important enough for official communications channels. In a video presentation on working with distributed teams, Guido Schoonheim suggests collocating the remote team for several iterations to build a sense of shared ownership and improve productivity. As one commenter notes, however, "The problem is that management often sees this as an unnecessary expense and erosion of the savings they're hoping to gain from offshoring."