Agile Outsourcing Success Part 1: Fact or Fiction?
This is post 1 of 2 in the series “Agile Outsourcing”
- Agile Outsourcing Success Part 1: Fact or Fiction?
- Agile Outsourcing Success Part 2: 5 Steps for Evaluating Agile Software Partners
As more companies embrace digital transformation, we are frequently asked the same question – “Is using Agile outsourcing to develop an incredible piece of software a pipe dream – or can it really work?” We understand why you might believe that outsourced Agile development is the ultimate oxymoron. Maybe you’ve tried it and the collaboration just wasn’t there, leading you to go back to Waterfall development when outsourcing. However, we’ve seen more Waterfall development projects result in major frustrations brought on by poor communication, missed deliverables, unmet expectations and more. Following are some recommendations for getting stellar results when leveraging an Agile outsourcing approach.
Learn 5 steps for evaluating Agile software partners in the second post.
Waterfall Development is bad for in-house Projects and even Worse for Outsourced Ones
Here’s why.
Many IT executives continue to cling to a Waterfall approach for outsourced development projects, believing it to be the only approach ensuring predictability and accountability from their development partners.
It makes sense, right? You tell your partner what you need. They tell you what it’s going to cost. They go away and build it. You get what you asked for at the price and schedule you expected. They make or lose money depending on the accuracy of their estimates and the efficiency of their organizations.
It’s taken some twenty years, but most IT organizations now recognize the fallacy of Waterfall-based development. The success of Waterfall software development was predicated on assuming you can:
1. Fully determine all requirements upfront
2. Perfectly forecast the time, materials, and effort required to build a system meeting those requirements.
3. Implement the project without encountering any unanticipated problems.
In practice, all three of these assumptions have proven false.
And that’s not all.
More often than not, the net results of most Waterfall development projects are frustrated business people, dejected programmers, and train-wrecked initiatives. Business people angrily demand explanations for every deviation from the forecast, and developers frantically trying to avoid scope creep by strenuously pushing back on most change requests.
How Waterfall development falls short for most Outsourced IT projects
While the assumptions outlined above seem completely reasonable, each one completely ignores three types of inherent uncertainty.
1. During any development initiative, requirements evolve in response to changing market conditions, continued reflection on what’s needed, and the deeper understanding that comes from actually test driving working software.
2. Every program to be written is unique, and successful coding depends on a myriad of technical, social, and creative dependencies that prevent any level of exactitude in estimating.
3. Even a single unanticipated issue — for example, an obscure, but critical bug in a commercial software component — can have very big impacts on the time and effort required to complete a project.
The list goes on.
Just because a project is outsourced doesn’t mean it’s any more amenable to Waterfall methods than in-house development. On the contrary, an outsourced Waterfall project sets up an inherent conflict from the onset, with the customer maximally interpreting requirements to get as much as possible for the agreed upon cost, and the service provider attempting just the opposite to maximize profit.
Another inherent issue with Waterfall projects is that they are typically sourced via a competitive bid process, which incents the service provider to aggressively estimate the project to minimize estimated costs. If the project is fixed-priced, the provider is then incented to cut corners wherever possible to deliver as cheaply as possible. If the project is a time-and-materials effort with widely spaced deliverables, it may be many months before it becomes apparent that an estimate was too low. In these cases, the client has little choice other than to continue with the provider since, unless the provider is completely incompetent, switching providers at a late stage will only further increase costs and delay delivery.
How you can create stellar solutions with Agile Outsourcing
With an Agile approach, the client and the service provider agree upfront to a certain team composition and a high-level project scope and timetable, and then work collaboratively to maximize the amount of functionality delivered by the team. There is still a risk that the provider is overselling their capabilities and is setting unachievable expectations, but sprint-based delivery with frequent demonstration of deliverables should reveal provider incompetence early while it’s still feasible for the provider to be replaced. Ideally, incompetent providers are weeded out during the due diligence process, before any contract is signed.
Agile development benefits the client by providing the flexibility needed to adjust to changing expectations and unanticipated issues. While Agile software development accepts the uncertainty, it provides the transparency and control to make the best decisions for the project in a timely manner.
Agile development is based on three basic assumptions:
1. You don’t need a complete specification upfront – but a pretty good idea of what you need.
2. You can’t perfectly forecast, but you can have a reasonable approximation of what it will take to deliver.
3. The process of stakeholders and developers working together to define priorities and tradeoffs, especially around must-haves and nice-to-haves, will produce the best product achievable given budgeted time and resources.
The bottom line – Agile Versus Waterfall
Waterfall says that you can have perfect requirements that perfectly determine time and resources required. Agile says you have an allotment of time and resources, and these ultimately dictate how much functionality you can deliver. Many people bristle at this idea, because it implies you won’t know exactly what you’ll be getting until you get it.
But when you think about it for a moment, you realize that because requirements always evolve, and estimates are always very approximate, there is not really any more certainty with a Waterfall process. To put it another way, Waterfall says, I have these requirements, and therefore I need six people for six months to get it done. Agile says, I have six people for six months, and I’m going to prioritize the work and get done as much as I can. In this way, Agile actually provides more certainty around time and cost than Waterfall! How? While the upfront planning of a Waterfall project feels more solid, it is, in reality based on a false sense of security. As requirements evolve the previous sense of certainty crumbles. Tensions build.
Five Keys to Success when Outsourcing Agile Development
The first step into understanding how to outsource an Agile initiative is to change the way you think about outsourcing.
Agile is a highly collaborative endeavor among members of a development team, but more importantly, it is the ongoing collaboration that occurs between the technical staff, business-aligned product owners, and stakeholders who ultimately determine the functionality to be delivered.
At the onset of an Agile outsourcing initiative, the end-product is only loosely defined, with much of the detailed definition deferred until it’s better understood and actually required for implementation.
In an Agile initiative, the product definition is fluid and depends, in part, on what is learned through target user interaction and feedback through development. For that reason, development is never simply handed off to a partner. An Agile initiative should not be viewed as contracting for some product to be developed. Instead, you are contracting for a delivery team that you believe can efficiently deliver a quality product. With that understanding in mind, the following steps are critical in evaluating providers and structuring a partnership for Agile delivery.
1. Define Your High-Level Requirements
2. Vet Your Partner
3. Establish Your Budget
4. Agree to a Team Composition
5. Evaluate Team members
In Part 2 of this series, we shall guide you through these steps to provide you with the knowledge foundation you need to select the right delivery partner for your Agile initiatives.
Gorilla Logic has been leveraging Agile software development for more than a decade and was named in Gartner’s October 2017 Market Guide for Agile Development and DevOps Services. Our Agile process is customized to the specific needs of our clients. Each Gorilla is an Agile native with whom you have open communication along with full transparency into task prioritization and goals. We know it works – read our reviews on Clutch.co. Companies that could work with anyone choose Gorilla Logic.
