I was engaged as a consultant program/project manager for a rather large U.S.-based project and given an interesting challenge by my customer. The initial rough order of magnitude estimates for developing this new software system indicated well over a hundred man years would be required. This customer had come to the conclusion its waterfall style SDLC process, which had evolved over decades was not the answer for delivering this system as soon as possible and being able to adapt to its market’s frequently changing requirements during the course of what would no doubt be a long development effort. The customer had started to dabble with Agile (Scrum) development and was sold on the Agile concepts of starting development (nearly) immediately and iteratively meeting more requirements as they were prioritized and better defined and understood. Could Agile however scale to a project that would require 70-to-80 people working on the same project and could Agile be adapted to the compromises that would be imposed by this customer’s constraints?
Scaling is always a significant challenge but “compromising constraints”, what could those be? Well, the customer had a large inexpensive contract development workforce available offshore in India. The customer company’s target average hourly rate for the project resources dictated that as many offshore resources as possible be used. These offshore resources had moderate-to-light development and quality assurance (“QA”) experience with the technologies to be used, and the development resources were located in a separate city than the QA resources. The customer’s company had a shortage of business expertise that could be assigned to the project and that expertise was located at the U.S. base. Furthermore, the technical experts (architects and senior developers) that the customer wished to assign to the project were based in multiple U.S. locations. These constraints added up to one big Agile compromise really … there could not be co-location of all team members. Nor could they even be located in the same or adjacent time zones.
To the credit of the executive management the decision was made to move forward with the Scrum approach thinking despite reductions in effectiveness due to the resources location compromise, Scrum would still deliver better results sooner. We would learn what did and did not work and make adjustments over time to tune and hone our compromised approach.
We assembled six teams of 9-to-12 resources each, starting with two teams the first month and adding two teams each of the next two months. Each team was assigned what was thought to be a good blend of onshore senior developers, off shore moderate to junior developers, onshore business analysts, onshore senior QA analysts, and offshore testers. The resources’ experiences and skills were matched as much as possible to the portion of the product backlog that a particular team would tackle. Segmenting the product backlog and matching skills might make a worthy future blog entry, but this entry is focused on the challenge with the teams having members globally scattered.
Where it made sense from a skills and experience perspective, resources based at the same U.S. location were assigned to the same team, thus leveraging whatever co-location synergy could be managed. Following the Scrum principle of teams being self-governed, with guidance from a Scrum Master each team weighed the pros and cons of different approaches to dealing with the multi-location and time zones challenge and made their own decisions on how to proceed. Two different approaches emerged across the teams:
1) Take as standard Scrum approach as possible with all team members participating in a scrum meeting via teleconference once daily at a time that was at the end of the work day in India and near the start of the work day in the U.S. The sprint backlog would be managed using a commonly accessible scrum management application (in this case ScrumWorks). After individual reports were given in each scrum meeting, any specific collaboration meetings would be scheduled between the required team members and it would be worked out with each meeting who would have to sacrifice off-hours time for the meetings. It was also accepted that there may be a little more leniency in allowing questions and answers in scrum meetings given the communication opportunity the scrum meeting facilitated.
2) Designate two onshore team members to assign and coordinate work with the offshore team members. One person coordinated development activities and the other coordinated test planning and testing activities. The offshore team members were not required to attend the daily scrum meetings to report their progress, which was communicated by the onshore coordinator. In essence, the coordinator appeared as a team member who had the capacity of multiple people in the sprint process. Granted, this approach was made easier by the coordinators being provided by the same contract services vendor and by them having already had similar offshore coordination experience (though not related to Agile).
What was the result? All teams took about 3 one-month sprints to get to a comfortable velocity, which is common even with new co-located teams with little Agile experience. Also not unusually there were some resource adjustments that had to me made as some were unable to adapt to Scrum or the technical challenges. It was noticed over time that the teams taking Approach 2 with the coordinators representing offshore activity were continuing to increase their velocity while the other teams leveled off and in some cases began to slow down. Retrospection for teams taking Approach 1 suggested the offshore resources without a focused coordinator weren’t getting the business-oriented input as timely as they needed it nor were they being informed timely of changes being decided by onshore team members. Even if timely information was received by e-mail the offshore resources would have to wait until the end of their day to ask questions or get elaboration on the changes. Gradually, all teams moved to Approach 2 and found it to be more effective.
Senior management at this customer expressed their satisfaction with the progress being demonstrated monthly by the teams. Seeing working demonstrated within a few months for portions of the overall solution for which requirements were settled while other requirements were still being settled and defined was a convincing factor in their belief that even this compromised Scrum approach was more effective than their old waterfall approach. They were seeing acceptable working code in a timeframe that previously they would not even have finished all the requirements prior to starting design.
Without a doubt co-location of all sprint team members is optimal and anything less is a compromise with a true but hard-to-measure impact on productivity, but at least in this one instance it was shown that even compromised Agile can be more productive than waterfall. It might take a while longer for teams not co-located to yield the same benefits as co-located teams, but the same benefits can be experienced. Given the large budget savings in the use of the offshore resources in this case, the additional time to receive the benefits was found to be acceptable.