"It's possible to achieve almost anything as long as you are not worried about who gets the credit." -- Harry S. Truman
Over the past several years, I have worked with many clients who, while in the process of incorporating Scrum, either did not have company-wide implementation or had contracts with third parties who were using Waterfall and did not intend to change to Scrum or any other Agile process. This became an issue when the Scrum team(s) were implementing functionality that was required by the Waterfall teams and vice versa. This article will explore some of the methods that I have used when working with these types of situations. It will also identify common practices that can be used to provide a harmonious working environment while delivering value to the customers.
Detailed planning is a major effort in every Waterfall project, no matter how small. Project managers rely on very detailed project plans containing all of the tasks/subtasks, milestones, resources, start and stop dates, etc., up front before any design/development is even started. With Scrum, however, planning does not get detailed down to the task level until the sprint planning meeting. In my opinion, this makes a lot of managers and executives nervous, because they really do not understand how planning is actually handled on a Scrum project.
The first thing I always try to do is educate the staff on how the planning process normally works on a Scrum project. I start out by discussing the Scrum planning principles described in Ken Rubin's book Essential Scrum
. Then we work through the concepts of portfolio, product, release, sprint, and daily planning and discuss the level and type of information that is needed.
Once the staff has an understanding of how Scrum planning "normally" works, we begin the actual planning discussions to determine what product(s) or functionality are being produced by each group, as well as any potential dependencies. Keep in mind that this planning is being done at a high level for the Scrum teams, so specific tasks have yet to be determined.
There are basically three situations that I have had to deal with:
The Scrum team is creating features that are dependent upon the non-Agile (Waterfall) team components.
The non-Agile (Waterfall) team is creating features that are dependent upon the Scrum team components.
Both teams are creating features that interact with each other and have numerous integration points.
Regardless of which of these scenarios you are dealing with, the general concept is the same. In order to deliver quality and value to the customer, both teams must come to a common understanding of the interaction dependencies during the various stages of planning. There is no time for methodology-process warfare; both groups will have to agree to compromise and in the end meld into a team with the common goal of providing valued software to the customer.
I have always emphasized the importance of planning, coordination, and communication based on the planning level details that Rubin details in his book. These levels are:
As I have yet to be involved in any planning at the Portfolio level, I will leave this portion of the discussion to anyone who may be able to provide accurate information.
At the start of the Product (envisioning) sessions, I strongly encourage the product owners, project managers, and stakeholders to discuss the vision and the evolution of the product over a period of time. From the product envisioning session, we develop a product road map, a high-level feature list, and a thorough understanding of which groups/teams will be working on features that have dependencies on each other.
During the release planning sessions, all of the members of the teams/groups should get together with the product owners, project managers, and stakeholders to discuss the schedule, scope constraints, and overall desired customer value for the next two to three releases. From this meeting, each team should have a good idea of what customer value is immediately desired for the current release. They should also be able to identify at a high level all dependencies that the teams may have with each other.
It is vital that the technical staff and the business staff discuss the dependencies and how they will affect the delivery of the desired customer value so that that they can inform the product owners, project managers, and stakeholders of any potential issues that may arise due to these dependencies. This will give them the time they need to evaluate and reprioritize the capability as deemed appropriate.
Some individuals on non-Agile teams may not want to discuss high-level interactions during the release planning sessions. I have found that this is usually because the detailed requirements that they were accustomed to having were not complete. In cases like these, having highly experienced technical staff is vital. In all cases, it is imperative that each member of the team understands that no one individual has all the needed information. This is the nature of the beast, and we must all be willing to work together by being prepared to talk through the specific situations.
Based on the outcome of the release planning sessions, the product owner is able to work closely with the other product owners and/or project managers in order to properly prioritize and populate the product backlog.
Before and during sprint planning, the teams need to be fully aware of all of the dependencies that they have on other teams, as well as the dependencies that other teams have on them. This is where I have experienced the most difficulty with Scrum/Waterfall projects. I have found that this difficulty can be minimized if all the teams have been planning, coordinating, and communicating on a regular basis, not just during the normal Scrum planning sessions. The teams also need to have established a relationship based on trust. Many times, a lack of trust is rooted in fear. For further explanation, please see my see my article, "The Fear of Agile Transformation
The teams need to coordinate their strategy, processes, and work environments in order to work together. Representatives from Scrum team(s) need to attend Waterfall meetings and vice versa; this will greatly improve relationships and provide better value to the customer.
Planning, coordination, and communication are vital to the success of any effort, regardless of whether a team is using a single method or there are multiple teams using different methods. However, we cannot just have the planning sessions that are described in the Scrum Guide. As anyone who has experienced any type of Agile project knows, the traditional Scrum planning sessions are also the place to identify and coordinate the additional conversations that will be needed in the future -- especially in regard to key points of contacts and assurances of support.
Unfortunately, there is no magical pixie dust that can be sprinkled on teams -- even those that are using the same processes -- that will make them work well together. If there were, I am sure that one of us would have found it, patented it, and put it on the market by now.
In my experience, teams that work well together have established and effective communication. Most have done this through forming real-life, nonthreatening relationships with each other. These teams have learned -- as should we all -- to work and to play well together.
In the end, the lesson that we must all learn is that there are no winners in a methodology-process war -- only losers. The customer suffers, and this suffering is then projected, and rightly so, onto us. Our reputations are tarnished, and the customer will never hire us again.
If we do not want to see this scenario played out, we are all going to have to accept the fact that the sandbox really is big enough for all of us to play in, and we are going to have to learn to share our toys. Cooperation is the key to all of our successes!
In this article, I have briefly discussed my experiences with Scrum and Waterfall integration dependencies and how I worked through some of the problem areas using planning, coordinating, and communication. What has worked for me may not work for you and your team; however, you owe it to yourself to try everything you possibly can to deliver value to your customers -- regardless of the situation.