By Jerry Buchana and Srikant Chellappa
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.
