We’ve written in the past about the Do’s and Don’ts of offshore development on our website and in blogs. We’ve also written about how to adapt Agile to offshore development, based on 10+ years of doing same. In those articles we argue that combining methodologies where appropriate works better than a purist single methodology approach. We also point out the importance of decision factors related to scope, schedule, cost, and quality, on determining when to apply different methodologies. I thought it might be useful to do a search on the title of this post, to see what others are saying in their blogs on the same topic. Here is what I found.
Predictive vs Adaptive
Some posts describe pricing as being the most important criteria in choosing a methodology, relating predictable result to predictable process, where a predictable result is a synonym for fixed-scope, and fixed-price, and a predictable process is a synonym for Waterfall. In this scenario it is claimed, “client and provider are naturally tied to predictive software-development processes…not a good fit for agile software development”.
We would argue that while the above scenario can be true, it need not necessarily be so. Before we discuss why that might be the case, let’s take a look at the word predictable to establish a more precise meaning. Historically, the word predictable has been bandied about a fair bit in software development circles, as if by repeating it we can make it a reality. But can we? Certainly, if we were building a bridge or an office building, something we had done many times before based on established engineering principles, there would be at least a reasonable chance of predictability. Even on those types of projects predictability is not guaranteed. What about software? It is relatively rare in the software development world that we build the same or even a similar system to what we have built before. The same conceptually perhaps, but often the details of the specific requirements and implementation can vary markedly. A Customer or Account in one company is not necessarily identical to a Customer or Account in another company, even when they operate in the same line of business. Many companies who choose to adopt a package solution must change their business operations to be in line with the package, or conversely they modify the package to suit their business operations. Adopting a package is often seen as the cheaper risk mitigating solution versus the more complex and expensive task of building a custom system. Additionally, one might ask, what chance is there that some person or group of people can predict precisely what functionality they will need 6 months, or a year in the future, which is often how long it will take to custom build the system. This is precisely the point that detractors of Waterfall have made for quite some time. There is very little chance of absolute predictability. So why then is Waterfall predictable? Because it predicts that we will build something of fixed-scope within a fixed-price and schedule. That something might not be exactly what we need, but it will be something! In other words, the quality of the product may suffer due to the imposed methodology.
Let’s take a step back for a moment. Many have claimed that an iterative approach to building software can often produce a superior quality product, sometimes at the expense of rework of particular components to get that higher quality. I would generally agree with those claims, as I have seen it in practice. Is the expense of the rework acceptable if it will produce such a quality product? That’s a good question, and one that should be asked at the outset of the project. In fact, we suggest clarifying all of the decision factors related to scope, schedule, cost, and quality, before the start of the project. The answers to these questions will help us understand whether or not we can employ an adaptive, iterative process such as Agile for feature development. Some projects factor in a budget for rework ranging from 15% – 25% for feature development. This can put an effective cap on the allowance for perfecting the product, while permitting the Agile iterative feature development which results in a higher quality product. At the same time this approach gives project sponsors a realistic idea of what it will cost to get that improved quality. Of course, this requires that the project sponsor recognizes the value of iterative development, and he or she understands that it can function effectively within the organization.
Regardless of whether your project has a Time & Materials budget with some allowance for variation of scope and schedule, or a Fixed Price budget with a Fixed Scope and Schedule, it is important to have a good idea of what can be delivered for a given amount of money within a specified time. In other words, a Time & Materials project should not be an excuse for poor estimating and/or delivery execution. Along that line of thought, consider doing a Project Scoping before launching into an Agile Application Delivery process. Not only does this help orient everyone to the expectations of the project, it provides a guideline that is invaluable to the distributed teams that inevitably result when using offshore development. Coupling that approach with a well thought out onshore-offshore team structure will significantly increase the chance of success of your project.
Communication and Teamwork
Some posts describe communication and teamwork as being the most important criteria as to whether Agile will work in conjunction with offshore development. Perceived problems that have been cited:
- The offshore developers just didn’t understand what was needed.
- Team members have never met each other, are not all sitting together and do not have the same working hours.
- Due to the lack of face-to-face communication, cultural differences and time zone issues, the developers start to misunderstand requirements.
- The product owner starts to use more written communication, which causes more misunderstandings
- Because the team has never met one another, the onshore developers don’t treat the offshore developers as part of the team.
Interestingly, all of the above problems stem from a single decision to set up the project onshore-offshore team structure as follows: onshore team (master) using offshore team (slave). I use those provocative words deliberately, because that is exactly how some organizations view their team structures: onshore innovation dominating and controlling offshore coders. This makes the mistake of decreasing cohesion between the team, while unnecessarily increasing coupling between distributed teams. You can set your team up that way, but believe me you won’t reap the benefit of offshore development. Read more about that here. We maintain that software should be architected, designed, developed, and tested offshore with a co-located team. Following our Agile application delivery process, Subject Matter Experts (SMEs) are co-located with the delivery team offshore on a rotation basis. There are four very practical reasons to have the project SMEs rotate through the offshore center:
- For the customer it feels good to have a “person on the ground” where the action is happening.
- It increases engagement between customer SMEs, who are relieved on a temporary basis from their day to day operational responsibilities, and the delivery team.
- We remove the bottle neck of communicating through onshore liaisons.
- The approach ensures that every SME has met every project team member.
Correctly structuring your onshore-offshore team, and following an Agile process that has been tailored for offshore development is critical to the success of your project. With a few minor changes, your onshore-offshore development teams can work together efficiently to make the most of offshore cost benefits, while delivering a quality product on-time, and on-budget.
Glenn Reid is the CEO of RJB Technology Inc., a Canadian firm with Branch Offices in Makati, Philippines. Contact us today for more information about our company, or to discuss your custom software development needs.