Scrum Team in Waterfall Land! What to do?

The real question sent to me was: What are some tips for integrating our SCRUM model with non-Scrum groups who will not be adopting the process?

One can go many places with this question, and there could be other questions within this question.

For now, let me answer two questions.

1. In general the culture and the management systems (eg, metrics) are used to or adapted to waterfall. With a Scrum team(s), what should we do about this?

The finding is that this will remain a solid, and increasingly annoying impediment until you fix it.

How big of an impediment is this? This can vary a lot. It depends partly on the metrics and partly on how they are used.

Fixing it can entail, ultimately, changing the whole company culture in a pretty significant way. Which, for a large company, takes some time. Sometimes, you can select a major group within the larger company, and just change the culture of that group. And that is enough (for you).

Changing the culture is hard work and takes time. It must be balanced, maybe, against fixing more immediate and pressing impediments now.

How to do it?

Gather a small group of change agents regularly. Identify the changes you want to put into effect…how you want to go about changing the culture, at least in some specific ways.

“Fearless Change” by Manns & Rising and “A Sense of Urgency” by Kotter are two places to get ideas about how to make change happen.

For metrics, I would initially get the Scrum teams exempted as pilot efforts. Then I would suggest that the basic Scrum metrics (velocity, Sprint burndown, Release burndown, BV metrics, speed or frequency of releasing, quality metrics, etc, etc) be used in place of the old metrics. It is common that you will win some of these discussions and lose others. Typically, this means the team must do “extra” metrics, typically for no good reason except that “they are there.” Make clear the extra cost to the team in doing the extra metrics. Over time, you will likely win more and more of these discussions as people become less afraid of the Scrum teams.

2. A Scrum team must work with other groups that are used to waterfall. What should we do about this?

The main advice is: use common sense and do just barely enough to make it work. That is, make some accommodation for the waterfall teams, but as little as is needed for good success.

In general, different people will react differently to an agile-scrum team. So, your response will depend in part on how the other people react and perform.

In simple terms, there are two situations:
(a) they provide deliverables to the Scrum team, which affects what we can deliver or complete.
(b) we provide deliverables to them (which affects them and our reputation).

First, prioritize the groups the Scrum team is working with. Put the most ‘work’ in on the person or group who is most important (obvious as soon as I say it).

Second, are there any personal relationships we can leverage, such as, Team Member John is a friend of George (who is in Dept 1)?

Often, John can visit George, and discuss agile-scrum a bit. (And maybe take the time to discuss Scrum over lunch with George’s manager too.) This reassures George.

Then John should ask George “I know this Scrum stuff sounds a bit weird and is certainly different than what you are used to, but can you help us out?” And often George will do it, especially if we/John make things a bit easier for George. (“I’ll scratch your back, if you scratch mine.”) It’s all part of the unofficial ‘pizza & beer network’ that many of you know well.

Sometimes this is enough.

Third, let’s imagine that George’s boss hears that George is “being easy” on the Scrum team and orders him to “be tough, demand that those guys fill out all the usual waterfall forms each time! And abide strictly by the rules!” And let’s assume we know that this is a silly bureaucratic waste (mostly).

The next step is to have a high-level “Impediment Removal Team” (IRT) that hears about all the top impediments from all the Scrum teams. Assuming this impediment (George’s boss) is important and we are sure we are right to complain, then the Scrum team sends this impediment to the IRT. A person from the IRT (a senior level person) goes to talk sense to George’s boss. If done right, surprisingly George becomes more cooperative with our Scrum team in a few days.

Sometimes this is enough.

Sometimes the problem is not George’s boss, but only that George has 15 things in the air, and we are not that important to him, so his performance for our team is not reliable. In that case, we can set up a special board on the wall (in the team room or virtual team room) and John or someone else in the Scrum team can ‘manage’ George, using the wall. Some examples: visit him often, send him ticklers, go to his boss, help George fix his own impediments, etc, etc.

Sometimes George is so key to the Scrum team for a Sprint or two, that we have him come to the Daily Scrum every day to report on his progress. Sometimes we have somewhat formal ‘weekly’ meetings with George.

The main thing is: we add to ‘Scrum’ just enough other stuff to make things work with George and Dept 1 (George’s Dept). We try to ignore or minimize the stupid stuff as much as possible, and get as much value from Dept 1 with as little effort as possible. Sometimes we just accept some degree of ‘stupid stuff’ from Dept 1 for a while….but only for a while.

Again, each department or group will be different. Some things we do for Dept 1 might be overkill for Dept 2. So, we adjust our response for each department and each “George.” Based on our team’s needs and who they are. So, the way we work with Dept 3 will be different than how we worked with both Dept 1 and Dept 2.

Sometimes a ‘serious’ issue comes up. Be ready to explain Scrum, explain how it is less risky than other approaches, and why it does not need to comply (completely) with the usual BS bureaucratic stuff that we have always been doing. But learn to say this in a nice, non-confrontational way. That sounds (and is) supportive of the main business drivers in your firm (“we have to have faster time to market”, “we must reduce costs”, or others).

But be reasonable. Bend ’em but don’t break ’em. Remember that changing an organization takes time, and much of it is based on goodwill. So, increase your capital of goodwill and spend it judiciously.

Changing an organization takes time. Keep plugging, but have reasonable expectations. You don’t have to win every battle in the first minute. Be adaptive.

 

« « Getting Higher Velocity – Take 3 || One reason for “Business Value Engineering” » »