Scrum Team in Waterfall Land! What to do?

This content is syndicated from Agile & Business by Joe Little. To view the original post in full, click here.

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 questions.For now, let me answer two questions.

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

The finding is that this will remain a small-ish and firm and increasingly annoying impediment until you fix it.  

Fixing it entails, ultimately, changing the whole company culture in a pretty significant way. Which, for a large company, takes a long time.  Sometimes, you can select out a major group within the larger company, and just change that culture.

Doing this is hard work and takes time.  It must be balanced 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 you want to go about changing the culture, at least in some ways.

Fearless Change by Manns & Rising and A Sense of Urgency by Kotter are two places to get ideas about how to effect the change.

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, etc, etc) be used in place of the old metrics.  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.

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 team that 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 (in the team room or virtual team room) and John or someone else in the Scrum team can 'manage' George, eg, 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.  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 of 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 need 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 organizations 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

15 − 6 =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”



To explore how we can help you, please get in touch