Nearshore Agile Development Needs to Fix Major Flaw

Companies that want to grow their bottom line while saving money by speeding software cycles are turning increasingly to Agile development. But how can companies combine the cost savings of Agile with the economies of Nearshore while protecting themselves from miscommunication and the mismanagement of time and resources?

Traditional development contracts include terms such as cost-per-hour and date-of-deliverable and include an addendum with a long list of requirements, says Russ Fletcher, who has managed IT efforts at Global Systems and XanGo and currently works as an Agile coach and trainer at Davisbase. “The challenge with that is, what happens when the world changes?”

Since Agile development involves many iterations of work on sub-units of software, rather than a smaller number of hands-off of larger chunks of work, “the ideal contract would say, I will make you happy for X amount of money,’” says Fletcher. “But of course, you can’t say that. The best you can do is try to define what ‘making you happy’ looks like and then assign a value.”

True Cost

With Agile development, value is not produced when an idea is developed, but when the code to implement it is delivered. Thus, charging by the hour encourages developers to work less efficiently, says Fletcher. Instead, he suggests results-oriented labor costs, through a contract that allows the client to charge by the number of story points (specific functions within the software) the team delivers. “This changes the labor cost paradigm to create value by producing visible results,” he says.

Peter Stevens, a self-described “Corporate Thawing Agent,” and author of the blog Scrum Breakfast, warns that in Nearshoring, “long communication lines can create inefficiencies which cancel out the price advantages.” While the best co-located scrum teams have been documented to be 10 times more productive than the average team, he warns that if you have only an “average capability” offshore team you must carefully consider whether offshoring will provide a financial benefit.

Timeline Estimation

Contacts can go awry when development teams fail to meet deadlines or inaccurately estimate the amount of time and staff required to complete a project. A major benefit of Agile is the ability to measure the “velocity” of a development team’s output, says Fletcher, by evaluating the working product as it evolves and providing constant feedback to the team about the users’ (perhaps) changing expectations. “This creates a healthy dialogue that a traditional contract doesn’t allow for,” he said.

To maximize this benefit, Stevens says, “it makes sense to contract experienced teams rather than individuals, and as a supplier, it makes sense to keep teams together over longer periods of time.”

 Unambiguous Reporting

Checking progress has always been an integral piece of ensuring a project is on track. With Agile, say both Fletcher and Stevens, unambiguous reporting can be simple when compared to traditional development methods.

Development teams demonstrate the working functionality of the software following every Sprint (or two-four week development interval). Meanwhile, progress for the entire project is measured on a burn-down chart. Stevens explain, “If a feature is finished, the team may deduct the estimate for the feature from the total time estimate of remaining work to be done. So a Scrum project is considered 50% done when 50% of the features are complete. If 50% or less of the time has passed, then everything is in good shape.”

A significant paradigm shift with an Agile project, where you no longer have the flag at the top of the hill, is that progress reporting boils down to whether you are on track or not on track, adds Fletcher. “It’s not everything or nothing, but just asking ‘Are we still on the path?’”

Better Processes, Better Contracts

While both Fletcher and Stevens are proponents of Agile methodologies, they agree that contract processes must change to make the most of it. “For me the most important sentence of the Agile Manifesto is the first one: ‘We are uncovering better ways of developing software…’” says Stevens. “It’s a voyage and you can always learn and improve. ‘We are uncovering better ways of writing contracts…’ would be just as true.”

“When we write traditional contracts and use Agile methods to achieve them, what we have is a constant project schizophrenia,” says Fletcher. For Agile to truly work, customers need to create contracts that reflect Agile processes, he says, but there are very few attorneys that understand this. “It’s the next biggest hurdle to overcome,” he says.