Scrum, Virtually

Applying Scrum in a Global Delivery Model

11 February 2009

Scrum has long been touted as an agile methodology that delivers results in an application development project. The methodology includes short iterative cycles called Sprints, typically 3-4 weeks. During each sprint, the team creates a version of user-ready software. The set of features that go into each sprint comes from the product backlog, which is a prioritized set of work to be done. Which items go into the sprint is determined during the sprint planning meeting held at the beginning of each sprint. During this meeting the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint. This cycle can keep repeating itself until a product has met its release requirements or release date. The key factor is that the product is user ready at the end of any sprint (while it may not have all the features) and that the features that have been developed are the most important features. The teams who deliver this work are self-organizing. Scrum is intended to work best for collocated teams working in a team room with no walls and rolling desks so the teams can self arrange their working settings.

Global Delivery Model: Reality for a Flat World

Application development lifecycles have taken a new twist in a flat world. Rapid advances in communication and technology have led to teams collaborating in a global setting to deliver products in shorter timeframes, with better quality, and at a lower cost. This trend started with manufacturing, where companies like GM and Boeing built their products by sourcing parts from several different manufacturers around the globe in an effort to maximize cost, quality, and time, and then assembled them at their locations. This global delivery model found its way to application development in the early 90s, as the cost and quality of communication improved by magnitudes. In a global delivery model, teams are distributed geographically into separate groups within the application development teams. For example, the business analysis team may be placed near the users to have better interactions and fully understand the context of the business process while the core group of developers may be situated in an offshore location such as India or Russia.

Adapting Scrum for a Global Delivery Model

Scrum-based project delivery in a global or a distributed delivery model requires some creative modifications to the Scrum methodology set forth by Ken Schwaber. At eMids, we have adapted Scrum, adding some Rational Unified Process and PMI project management principles, to best support our global delivery team. Despite being distributed we communicate often. We call our daily standup Scrum Calls. Scrum Calls take place early in the morning via phone. Both the onsite teams and offshore teams participate. Our onsite business analysts and the offshore teams collaborate frequently on requirements, progressively elaborating them twice a week via phone. These meetings can be made more frequent as necessary but are not substitutes for the Scrum Calls.

This collaboration doesn’t stop with our delivery teams. We work closely with stakeholders during the entire process. The progress and the features delivered are made highly visible, and are developed collaboratively whenever possible. As a result, there is stakeholder buy in during the whole process. After all, the best way to validate software is to actually put it in the user’s hands!

We have augmented Scrum’s project metrics with metrics from Rational Unified Process (RUP) and Project Management Institute (PMI), including earned value analysis, resource utilization, and estimate-to–complete. We have also incorporated key PMI knowledge area tracking for issues, risks, and statuses. We share our consistent and measureable progress on a daily and weekly basis. This helps alleviate stakeholder concerns and facilitates their buy in.
As we prioritize our product backlog, we keep the RUP principle “do the most architecturally significant features first” in mind. This allows the risks to be taken head on without compromising the features later in the development cycle. We also have a consistent definition of done. When we say we deliver working software, we mean that the software delivered in each sprint must have gone through QA either offshore or onsite before being released to the customer.

We avoid project handoff by running multiple scrum teams in parallel. Each team has a ScrumMaster. The teams’ ScrumMasters report to a project-wide ScrumMaster for a Scrum of Scrums. Having multi-threaded teams avoids the serial delivery of functionality (mini-waterfall) and accelerates delivery timelines.
.
Above all, we strive for flexibility within the structure of a well-defined process. The key aspect to our blended methodology is that it should never be a stringent process where the users are frustrated with the inflexibility. No onerous change management is involved. There is a fundamental belief that requirements and the feature priorities can change but the onus is on the product manager to ensure that the impact of the change is communicated to the sponsors so that they fully understand the true cost of altering their requirements or priorities.

Scrum, Virtually

At eMids, we believe that Scrum can be adapted to work seamlessly with, and actually improve performance inside, the global delivery model. The best practices we use each day have resulted in a vast improvement in end-user satisfaction and a rapid product development lifecycle that has not only advanced the budgetary benefits of the global delivery model but also has resulted in higher quality and a more usable product.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Anonymous, 2/16/2009 4:52:58 AM
Very interesting read, especially as your GDD approach seams similar to ours (which is a combination of Scrum, XP, RUP and global distributed delivery). How is the acceptance of Agile among your clients in the US? Do they ask for Agile or do you have to sell it? Regarding most of our German clients we still have to pursuade them to use Agile. They are still very much in waterfall.
Denise Carlino, CSM, 2/16/2009 7:49:11 AM
Srikant and Jerry - we have adopted a very similar approach and currently have 5 scrum teams. One area we struggle to avoid is team dependencies ... I'm interested in knowing how many teams you have and how you avoid the teams taking on user stories that don't create dependencies on each other?
Jerry Buchanan, CSM, 2/24/2009 3:14:09 PM
I would say that certainly more of our client's prefer something iterative over waterfall. About half of them are skeptical at first since we tend to go for a time and materials approach, but the overall transparency into our progress, financials, scope, etc... has won all of those over after 1 project.

To help with the dependencies issue, I have to admit I exercise a bit more executive control than a true Scrum calls for. While I do let them pull the tasks they want to work on, there's a bit of a push from me when required!
Rajiv Bajwala, CSM, 4/7/2009 4:25:51 AM
Great job Srikant and Jerry. I'm interested to know if you'll used a full fledged project schedule (mpp) to conduct the EVA and determine the estimate to complete. Also - what problems if any did you face on your "Scrum of Scrums", if any ? Would each ScrumMaster report every activity that his team has completed since their last daily standup or was it a more highlevel information sharing meeting ?
SHRINIVAS RAMANUJAN, CSM, 4/26/2009 1:54:02 AM
Hi Srikant and Jerry
It is really a good piece of information you have provide on distributed development which hold significant relevance today.
Many a times I have teams which includes developers and testers who are distributed geographically.
I would be very interested in knowing how it is managed in your current context?
Thanks
Regards
Rama
Rostyslav Seniv, CSM, 12/21/2009 5:05:26 AM
Hi Srikant and Jerry. You say you keep ΓÇ£do the most architecturally significant features firstΓÇ¥. How do you think with correlates with Core Agile/Scrum?.. We are doing something like that too by the way. And, don't you think that makes you product less agile and ROI smaller/slower.

You must Login or Signup to comment.