Can we create a new variant of Scrum for waterfall projects

Question

It is not easy for traditional large software product organizations working in distributed off-shore environments engaged in Product Development to follow the spirit of Agile in Scrum for the following reasons:

1. Their product development is not iterative. The product engineering teams after several rounds of iterative systems engineering, finalize the product requirements, product architecture and design for a given release, upfront and formally. Changes to this may occur but not in a large scale.

2. The Product Engineering Teams now get this product built by off-shore teams based on the specifications created. These large off-shore teams cannot work on an iterative and empirical mode as this is not warranted here.

3. However the Product Managers may like to get visibility into the Product Development by the off-shore team periodically by requesting for incremental deliveries in short iterations.

4. If these off-shore teams can follow a variant of Scrum in a formal process defined (not empirical), manager managed environment (not empowered) and using a incremental development approach (not iterative and adaptive), it would be very useful to them.

5. The true Scrum approach implemented in this situation may look very hypocritical. However if we can give them a formal variant of Scrum for traditional waterfall kind of scenario, they may use it to everyones advantages.

I have tried to describe this context in more detail on my blog at scrumtales.blogspot.com.

Can we do this ?

Answer 1

You might want to look at ThoughtWorks' (Martin Fowler) experience on doing agile off-shore development. I would say that it's certainly possible to adapt Agile to off-shore development (or your off-shore development to Agile), but it may be a big change. You might also want to look at Fearless Change - for patterns of introducing new ideas to an organization. It sounds like the biggest difficulty you are facing is resistance to change, not technical issues regarding Agile implementation.

Answer 2

The short answer is most definitely YES.

While Scrum is a methodology that consists of certain ceremonies and processes, the common implementation of them is just that - one implementation. For each process, take a step back and look for a solution at a higher level of abstraction, that doesn't have the problem you have - mainly distance. For example - co-location. While the common interpretation is having everybody who is collaborating to get a user-story "done" into one concrete room, that is not necessarily the only kind of room. Would a chat room do the work? Would a Virtual-Reality room work for you better? A VOIP solution could work as well.

One or two meetings each month (sprint planning and retrospectives) could take place in such a virtual environment, without being too hard on people occasionally working during normal off-hours.

Perhaps frequent on-line meetings can be taken offline, if time-zones and internet bandwidth are insurmountable. Daily meetings can be done by use of a wiki. Or Email.

There are a myriad of on-line tools for ceremonies such as planning-poker (PlanningPoker.com), some commercial, some free: VersionOne, AxoSoft OnTime, to name a few.

The rest of Scrum could probably be done regardless of physical distance - writing User Stories, estimating and story points have no location based constraints.

Hope this helps, Assaf.

Answer 3

formal variant of Scrum for traditional waterfall kind of scenario

This is called "Scrummerfall". Here are a couple links to get you started on the pain you can unleash on your organization:

http://www.agileprogrammer.com/dotnetguy/archive/2006/07/08/16855.aspx http://blogs.msdn.com/nickmalik/archive/2007/06/04/waterscrum-vs-scrummerfall.aspx

Answer 4

My short answer would be no, based on what I read in your question.

I would have to say that unless your distributed off-shore team are willing to adopt incremental development, then this is not going to be a useful exercise at all. Without the incremental delivery the product manager who is mocking the rest of the Scrum process for this remote team, will be looking for progress at the sprint reviews, and the team will not be able to show anything beyond the things they have completed as part of their waterfall process. So, for the first part, that designs are completed, later on that implementation work is done, and finally that system and integration tests are working. Certainly the Product manager will not be able to ask for some changes in the original plan, at a point in the process that the team can respond and still meet their other commitments and milestones they are driving for. Why? because they won't be delivering functionality till later in the project.

Incremental development is key. Once they have that and the product manager is receiving time-boxed review sessions, then you can start to move away from the Managers making the commitments, and have the team members receive the feedback and make commitments directly.

Another thing to try, once you have incremental development, is the idea of using the off-shore teams manager as a Product Owner Proxy. It allows your product manager to negotiate dependencies with all teams on the project, and convey those to the proxies. The proxies can then interact with their local teams in an authorative manner, and still represent the goals and priorities of the Product Manager. This also helps deal with the problem that distributed teams have, when they do not have direct access to the Product Owner. Having a local proxy helps deal with questions the team may have about features, without waiting for someone on the other side of the world to respond a day later.