Why doesn’t the traditional global delivery model work?
There are several reasons why the traditional global delivery model doesn’t work, but we’ll focus on a few reasons, with examples.
For one thing, the initial overhead created via documentation, rigid processes, and several managers often leads to unmaintainable artifacts, too many meetings, and confusion, which translates into bloated budgets, missed deadlines, misinterpretation of requirements, scope creep, and so on. I remember a project for which the developers had countless meetings with the QA team to explain the testing effort and to review the requirements specification in detail. By the time the QA team wrote the manual test cases, business had already changed some of the requirements and another group discussion was required, followed by revision of test cases.
In another project, we had the most painful bug scrubs imaginable. Since the QA lead represented the QC folks (manual testers) in the requirements discussion meetings, there was a lot of misinterpretation of the requirements by testers, which forced the entire team to spend hours reviewing, isolating, and categorizing defects. In several instances, the defects were dismissed because it was the expected behavior for those scenarios. But it’s common in a traditional offshore model that team leads and managers are sent onsite to interact with the client directly, serving as the proxies for all offshore communication.
I had the opportunity to attend the annual NASSCOM conference last year in Mumbai, India. NASSCOM, the National Association of Software and Services Companies, is a trade association for the Indian information technology industry. From listening to senior managers from most of the large, local software consulting companies, it appeared that their view on global delivery of software services is deeply rooted in the old mind-set — an intake process that requires a lot of documentation up front and that sees people as “resources,” and therefore any problem can be resolved by scaling up resources. With projects that I’ve managed in the past, we lost a great deal of time from people being added onto the team, because of the ramp-up time invariably needed. Also, increasing the team size, especially with developers, led to an increased volatility of the code and project risk. This translated into significant refactoring or scrapping of the original code altogether.
The traditional global delivery might be fine for straightforward projects that have frozen requirements. But for complex projects, a dynamic approach for changing requirements and technology is better suited. However, I don’t fault these companies entirely for not being proactive in evangelizing a better approach to software development and delivery of service. From my own experience, the clients themselves impede vendors from bringing innovative approaches to problem solving and setting a standard for being efficient and effective. These clients are heavily compartmentalized, with several layers of functional and senior managers, and they’re often caught up in their own bureaucracy and hidden agendas. This creates too much red tape for any project to be successful.
The future global delivery model
Some people say the future is already here, and I tend to agree with them. Given the rapid changes in technology and market trends, and the turbulence in the global economy, it’s no surprise that companies are more cautious these days with their IT budgets and the projects they’ll take on. They want to see value early and often and have confidence that they’re building the right product the right way, without compromising on quality. Scrum, when implemented correctly, accomplishes this.
With the increased number of automated and collaborative tools in last few years, Scrum has become much easier to implement in remote teams. I term these tools a disruptive technology in this context, because they are indirectly changing the global delivery model for software development services. With automated testing frameworks such as Tellurium and iQA, third- and fourth-generation programming languages such as Visual C# 2010 Express, advances in videoconferencing like Google+ Hangouts, and tools to simulate colocation, it’s getting easier to implement nontraditional, Agile processes for remote software development.
One of my favorite tools for remote Scrum teams to use is the Team Foundation Server (TFS) Agile template for .Net projects. You can create your entire product backlog, then pull stories into each Sprint planning session and create tasks. Everything is tracked (users, date and time, etc.), and you can configure reports to generate dynamically for release and Sprint burn-down charts. Feedback from retrospectives can be recorded in TFS as well, and people can log in from anywhere via secure access.
Conclusion
When I look at the innovation from Silicon Valley, it’s hard to believe that those entrepreneurs used traditional approaches to build and launch their software products. Whether you are a company that contracts software services or a vendor that provides these services, to stay competitive in a global market you need a framework for software development that is robust, flexible, and easily adaptable to market and external changes as described above. Scrum is that framework, and in the coming years I think there will be a major shift in ideology from classic scaling up of “resources” to leaner, hyperproductive teams.
From consulting on various projects throughout the United States, Europe, and Asia and attending international conferences, I have already seen the adoption of Scrum and the way it’s gaining more and more acceptance in the global market place. I do see more adaptation in smaller to medium-size companies than large, global companies. However, I am convinced that eventually the pressure from the top management of these companies will force their IT managers to work more intelligently and to leverage cost-effective tools in the market to implement better frameworks. Once this happens, vendors who want to compete will have no choice but to change their global delivery model for software services. Therefore, the need for Scrum coaches and mentors to help organizations and teams worldwide to transform their processes will be both challenging and in high demand.
