This is Part #2 of the series of posts devoted to combining agile methodologies with software development outsourcing. You can find Part #1 here.
Why is the question of the business model that important? It becomes clear when you look at the seemingly weak controls that the client organization has over the work of the agile team provided by the outsourcing provider.
Let’s take Scrum as the most widely used methodology from the agile family (though the Lean sub-family has been reducing the gap recently). All it promises (if implemented correctly) is that you get the maximum amount (per the team capabilities) of the most important requirements (as prioritized by the product owner) in the given timeframe. It doesn’t guarantee that the product is complete in that timeframe. It doesn’t even guarantee that all high-priority requirements are implemented or the product is feature-rich enough to hit the market in that timeframe.
It allows the team (not the product owner who formulated the requirements but the team who implements them) to tell how long it will take to do the tasks from the backlog. It doesn’t even attempt to push the team to do these tasks faster or penalize the team for low performance. It doesn’t have any ability to say, “Do these X requirements by Christmas, or else…” All it does is capture the actual team productivity and predict when it will be over if the productivity stays the same and no new features are introduced.
The first reaction of any traditional outsourcing client to that lack of financial penalization for lower-than-expected productivity or later-than-expected release dates is, “Now, they will just keep crawling through the backlog for years, and I will keep paying them for that…” It’s not an unreasonable concern. Check out this story from the Project Management section of Stack Exchange for an example of how agile outsourcing can turn into a nightmare: “Communicating requirements to offshore teams”.
What you need to understand is that you can and should protect yourself from nightmares with offshore agile teams in the same way you handle your internal agile teams. You are using agile methodologies internally despite the fact that you have less direct control over the team, aren’t you? What happens when you have clearly under-performing/lazy/incompetent teams or team members? You fire under-performing employees, you shuffle the teams, you change the Scrum Masters who let the situation get out of control, you offer bonuses for certain achievements. You can do the same things with outsourcing providers.
First, add a clause into the contract that would allow you to stop the project and stop paying for the team with little heads-up notification required. Second, add provisions allowing a change of team leader and other key members of the provider’s team on your request. Third, provide certain incentives for reaching the milestones on time.
Whether you believe it or not, the providers are very interested in your business, and few of them (and I hope you can filter these out in your provider-selection stage) would be willing to get paid for doing little or nothing for two to three sprints only to see you become completely dissatisfied and cancel the project after that. We, providers, get much more from keeping the clients happy: We get more future projects and recommendations from you, and we keep our teams utilized, our attrition low, and our revenue streams predictable. And any failure is a huge blow: In our trust-heavy business, any negative publicity scares away future customers. Plus, we have to figure out how to utilize the suddenly free team and how to pay their salaries after the financial stream unexpectedly dries out. It just isn’t worth the “free money” that the providers can get from you for a few badly executed sprints. It probably doesn’t even cover the pre-sales expenses associated with winning your account.
So, the first important takeaway from this post: Structure your contract to have an easy way out and control over key team members if things don’t go as expected, and don’t forget to make it crystal clear to the provider that you are not afraid to use that weapon. And a little carrot in the form of a bonus for a job well done won’t hurt either.
For those who still feel more comfortable when the contracts directly reward/penalize for good/bad productivity, there is also a model called “Fixed-Price Agile.” It should be noted that it is far from a silver bullet, and in general, in my opinion, simple time- and materials-based contracts with the precautions listed above are more than sufficient for agile outsourcing. But the option is there, and you may want to use it.
The Fixed-Price Agile model—let me call it FPA for brevity; I know we all love three-letter acronyms—assumes the following set-up. At each planning session, the team estimates the stories—in story points or ideal hours—as usual and then fills its sprint backlog. Each story also gets a fixed price to be later paid by the customer calculated as the estimated number of story points/hours multiplied by some pre-agreed rate.
At the end of the sprint, the team, as usual, demonstrates all implemented stories. There may be certain addition requirements defined for the story to be considered implemented (e.g., that it should be covered by auto-tests) or an architectural model for the product that should be updated to reflect the changes introduced for the story. In that case, those additional items are demonstrated and accepted as well.
Then for all accepted stories, the provider is paid the price determined during the planning session. And for all stories that were not accepted by the client (even though they were “90% done”), the payment is zero. If the story is later implemented in one of the subsequent sprints, a full payment is received for it. The payment doesn’t take into account the actual efforts for implementing the story, only the planned efforts. Hence, it resembles the “fixed-price” model and is thus called “fixed-price agile.” It transfers the risk of underestimating the project from the client to the provider, provides incentives for the provider to work faster (if you do more tasks within a sprint, you get more money), and thus is seen as a welcome improvement to the basic T&M approach by some clients.
You can’t avoid having a devil in the details, though. One of the common points of tension between the provider and the client is the question of bugs. By the time the stories are accepted at the end of the sprint, they pass only unit-testing and some limited amount of system/integration testing (with load/stress testing often planned as separate stages in the project lifecycle). Thus, it’s not uncommon for a bug to be discovered in the already-accepted code, sometimes many sprints or even months after the acceptance. And what is seen as a new story worth extra money by the provider (“Fix issue with …”) is seen by the client as something that should be covered under the free guaranteed support. So, don’t forget to discuss and agree upon that subject on the shore, before launching your outsourced agile project. And don’t be surprised that the story point/ideal hour rate depends on the reached agreement.
Another thing is the question of the changing velocity of the agile team. As the project progresses, the team gets better at estimating the tasks on one hand and becomes more productive on the other. All that affects velocity and the ideal hour to actual hour ratio in estimates. Again, don’t forget to agree upon periodic rate re-synchronizations if your project is expected to last longer than three to four sprints (and if it doesn’t, you may find out that the good old “fixed-price” plan works pretty well for such a small scope).
These small gotchas (and the misunderstandings, tensions, escalations, and renegotiations caused by them) are the reason why, as I said, I believe in a healthy relationship between a mature provider and mature client. The plain old T&M is sufficient and works better than a more complicated FPA model. But feel free to experiment and introduce FPA components into your contract. As long as you do it in good faith, you can always renegotiate the agreement with the outsourcing provider if you see that your set of rules doesn’t work well.
