InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Offshore Outsourcing with Scrum

Posted by Kurt Christensen on Feb 13, 2007

Sections
Process & Practices
Topics
Agile ,
Teamwork ,
Agile in the Enterprise
Tags
Offshoring ,
Distributed Teams ,
Scrum
Swedish consulting firm Softhouse recently published the second part of an interview with Jeff Sutherland [pdf], in which he describes how one company (SirsiDynix) used Scrum to integrate with an offshore development team in St. Petersburg, Russia. Jeff relates a key decision of CTO Jack Blount:
...he wanted complete geographical transparency. Mainly to optimize the project, but also he wanted to build a positive competitive dynamic between the teams where every member of every team on either shore, knew that somebody off shore could do their work tomorrow. So, he decided something that is very unique and there was a lot of controversy about. He decided that every team would be half in Utah and half in St Petersburg.
Martin Fowler and others have written about the difficulties of merging an agile process with offshore teams, and so some might be surprised to learn about an unqualified agile offshore success story. According to Jeff, two things helped the distributed Scrum teams at SirsiDynix work effectively with one another. One was the use of automated planning and tracking tools:
When you have many teams, every team needs to oversee the state of other teams, in particular when you have outsourced teams it’s even a bigger problem. So, you need some automated tool where all the data flows in and everybody can see it all the time.
The other enabling factor was the organization of the teams:
It is really crucial to have all the product owners, in the Scrum sense, very close to the customer. And you want the product owners close to the teams. Now, what SirsiDynix did... is that all the Scrum masters were in Utah, all the product owners were in Utah, and all the architects were in Utah. So they had very tight centralized control over the product and the product direction.
  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

Decisions over the wall? by Vikas Hazrati Posted
Re: Decisions over the wall? by Deborah Hartmann Posted
Featured in the Carnival of Agilists for Feb 14/07 by Mark Levison Posted
Re: Featured in the Carnival of Agilists for Feb 14/07 by Deborah Hartmann Posted
Ummm.... This is funny because this was actually an epic fail by Ryan Gardner Posted
  1. Back to top

    Decisions over the wall?

    by Vikas Hazrati

    Since the Architects/product owners/ scrum masters were in Utah does it mean that the team in Russia was just being fed with architectural decision taken and they were not involved in the process?
    Were there any issues because of the Scrum master being geographically distributed? Did the team in Russia have to wait for a while for getting the impediments resolved?
    Though the results seem encouraging the one team concept seems to be missing within teams.

  2. Back to top

    Re: Decisions over the wall?

    by Deborah Hartmann

    Jeff Sutherland's case study on this team might provide the details you seek:
    www.infoq.com/news/SirsiDynix-Case-Study

  3. Back to top

    Featured in the Carnival of Agilists for Feb 14/07

    by Mark Levison

    Lacking trackbacks I'm abusing the comment mechanism. This post was featured in the most recent Carnival of the Agilists: www.notesfromatooluser.com/2007/02/carnival_of_....

  4. Back to top

    Re: Featured in the Carnival of Agilists for Feb 14/07

    by Deborah Hartmann

    Thanks, Mark :-)
    deb

  5. Back to top

    Ummm.... This is funny because this was actually an epic fail

    by Ryan Gardner

    One of my first jobs out of college was working at SirsiDynix at the time they were working with the outsource teams. I was doing support so I wasn't directly involved with development so I can't speak from the perspective of a developer.

    However, everything that I heard from the developers was that the Russian team was constantly messing things up... i.e. the build would be broken whenever they'd come in for the morning... their tests would all be screwed up... the project that they were doing this huge coordinated effort on ended up being canceled in part because of some major overruns in the project.

    Jack Blount - who is mentioned in this article (I'm pretty sure he was CEO not CTO - but maybe he considered himself both) went on to found another startup and in that startup he didn't do any offshore agile teams. You would think that if this method were successful for him at SirsiDynix he would want to use it again at his next company to replicate the success. Nope.

    So... Be careful putting too much weight into this study as it being a 'positive'. I'm not saying that it's impossible for this offshore agile to work - but I am saying that using SirsiDynix as the example might leave you looking like a fool once someone digs a bit deeper into the story to hear about what really happened with it.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.