Friday, April 25, 2008

Managing Offshore Software Projects


Verma, Vikas (2008) Managing Offshore Software Projects. Icfai University Press.

A new book republished the Scrum case study on the highest performing large project ever recorded.

Sutherland, J, Viktorov, A., and Blount, J. (2006) Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams. In Proceedings of the International Conference on Complex Systems, Boston, MA, 25-30 June.

This project distributed Scrum teams so that half of each team was in the United States at SirsiDynix and the other half of each team was at Exigen Services in St. Petersburg, Russia. It showed how to set up distributed/outsourced teams to achieve both linear scalability of teams on a large project and distributed velocity of each team the same as the velocity of a small colocated team.

This project is still generating controversy in the Agile community by showing that you can run distributed high performance Scrums. There were quality problems on this project that caused some in the Agile community to discount the remarkable results and argue that it could not be repeated successfully.

However, Xebia in the Netherlands has now repeated the fully distributed model on a seried of projects using Scrum with a complete implementation of XP practices inside each Scrum team. Half of each team on all large projects is based in the Netherlands and the other half of each team is based in India. They achieve the same performance as the SirsiDynix project with extremely low defect rates. Their definition of done at the end of each Sprint is that the software has been successfully acceptance tested by the end user.

A paper on the Xebia experience has successfully passed the first phase of the review process for publication at Agile 2008 in Toronto.

Fully Distributed Scrum: The Secret Sauce for Hyperproductive Outsourced Development Teams. Jeff Sutherland, Ph.D., Guido Schoonheim, Eelco Rustenburg, Maurits Rijk.

Tuesday, April 22, 2008

What to do when Sales guys are Waterholics ...

Here is today's best question in my long list of emails. The Sales guys don't want Scrum in a company because they think they can't commit to the customer to close deals.

"We need to sign the contract first. The customer does not sign the contract, if finish date, price and features list are not in the contract. When using waterfall, the customer has all of that. That's how sales works. That's what we offer to them. With SCRUM either end date or features list is not defined. And end price is also not defined! We can't sell anything that way!"

Here is my answer ...

Your sales guy's are clueless about Scrum. They should take the Certified ScrumMaster class so they know what they are talking about. First they might start applying Scrum to their work in Sales. Then they could understand what the developers should be doing.

Our venture capital group runs company acquisitions using Scrum. The most junior guy on our team is the former SVP of Global Sales for Oracle. He could probably give a good answer for your sales force and maybe help them start using Scrum.

Basically, a sales plan calls for closing deals. This is the product backlog. The velocity of closing should be known by the sales guys. They have a list of tasks that need to happen to close the deal as the opportunity moves through the sales funnel. This can all be mapped out on the Scrum board. They should have a burndown chart that shows deal closing for a Sprint. They can burn down revenue achieved.

The immediate deals are locked and loaded for closing. The ones further out are in the planning stage for closing. Further out the deals are forecast just like software features. You know you will achieve a closing velocity but don't know exactly which deals will close.

So for Scrum, whether for sales or software development you need a plan (product backlog). The product backlog needs to be prioritized. The closing velocity needs to be estimated by the individual teams, the revenue needs to be committed to in the plan based on closing velocity, and the projects need to be DONE (whether they are closing sales plans or finishing software development contracts). There is always a roadmap owned by the product owner from which commitments are made.

This is exactly the opposite of what your sales guy is saying. We have a lot of teams that say they are doing Scrum but do not have product backlog, estimates, velocity, and burndown. Your sales guy must have seen some of these dysfunctional teams and completely misinterpreted Scrum.

Trifork in Denmark runs their sales with Scrum. All their sales people are Certified ScrumMasters. Every time they stop updating the Scrum Board they start losing track of deals and revenue and need to refocus on getting the Scrum Board updated. The VP of Sales runs the board as most of the people are on the road all the time.

When they close a software development contract, a sales person is sometimes the ScrumMaster leading the software development team. In this way the sales guys make money for the company while selling instead of wasting a lot of money on their expenses and driving up cost of sales. Once inside the company as a ScrumMaster they can sell even more stuff.

As for development, some of the leading companies in the world are doing fixed price contracts in Scrum. They know all the features, they estimate them all, and they commit a date to deliver. They then work an Agile process to finish the contract early and save money for the customer while driving up margins for themselves. It may be your Scrum teams are in the very early stage of maturity and are not able to make the committments that the sales people need. Or they have not educated the sales people properly. This is the responsibility of your Chief Product Owner. Do you have one?