When organizations that have become frustrated with the Waterfall model (i.e. gather one million requirements, then design for those requirements, then build everything, then test everything, then deploy it a bazillion weeks, months, or years later to a resounding thud) learn about the Scrum framework, they tend to get pretty excited about it. And why not? The Scrum postcard says it helps organizations deliver products of higher quality more quickly. Who wouldn’t want to do that? It’s a great idea. Unfortunately, we often get the transition wrong.
Change is hard, and I’d bet most of us would prefer sticking with familiar ways of working to complete upheaval. To that end, we often end up only partially changing the way we get work done – as opposed to diving in head first. One way organizations tend to deal with the discomfort around dramatic change is to create hybrid models of the two ways of working. You may find, for example, that you can break the work of a traditional Waterfall project into two-week “sprints”. While this method may get you to a place where you’re delivering something more quickly, that something is not likely to be something the customer could actually use. Basically what’s being done in these instances is Waterfall with more reviews; Your “sprints” end up being nothing more than shorter versions of the same old way of working (Sprint One: Requirements, Sprint Two: Design, etc.).
The term for these hybrid ways of working – or halfway doing Scrum, as I prefer to say it – is ScrummerFall, WaterScrum, or my personal favorite, WaterScrumFall. Regardless of what you call it, the strategy is a killer. If you don’t push your organization past that middle ground, you’ll run into problems, and whatever excitement may have existed around doing Scrum will evaporate. Simply put, you won’t get the benefits you expected from moving to Scrum. Here’s why.
Scrum and Waterfall are Completely Different Ways of Working
In a Scrum project, Requirements Gathering/Analysis is combined with Designing, Building, Testing, and Integration activities within one Sprint. The goal is to get to something called a “potentially shippable product” – something that is done (fully tested, etc.) and ready to show a customer. Scrum teams focus on some small piece of the larger end-product (often called a “feature”) in each sprint, so they can get feedback and incorporate it, adapt, and change what they’re doing going forward.
Unlike a Waterfall-type project, a Scrum project does not try to define every single activity that must get done over the lifespan of a project. Nor is it focused on a particular “phase” of work. Effort is not worth anything to our customers, only results. Thus, tackling Scrum is not going to be of much help to you or your customer unless you look at adopting it – even if only for one project and even if it takes you months to do well – in its entirety.
Scrum and Waterfall are Completely Different Ways of Thinking
Working with the Scrum framework requires more than a change in approach – it requires a change in our way of thinking. We kid ourselves thinking we can predict up front – when we know the absolute least about a project – how much everything will cost, how much time it will take, and 100% (or close to it) of our requirements.
A Scrum project assumes we know very little about our customer’s requirements up front, but we GET STARTED with only a few requirements. The beauty of starting to BUILD SOMETHING is that it’s not until a customer can hold or touch something – a completed feature – that they know exactly what they want. It may be something different than what we built, but it’s great to know that sooner than later. Working in this way allows you to learn and adapt quickly. Waterfall only gives organizations and leaders a false sense of security. Your project will still fail, it just won’t fail for a while. It’s better to a fail a bunch of times now (yes, there will be failures along the way – another thing we will have to get over) than to do so later.
How do You Make the Full Transition from Waterfall to Scrum?
The first step is to pick one project and incorporate all the elements of Scrum. Try to find someone internally that has successfully worked on a Scrum project that used all the elements of Scrum. If you don’t have the internal expertise, find an Agile/Scrum coach that can look at how you are working, celebrate your successes (no matter how small they are at the beginning and along the way), and give you some tough love on what needs to change. Make sure you have the human resources to be able to pull off a Scrum project. This may involve moving away from a traditional Project Manager/project team mentality and move to roles of Scrum Master, Product Owner, and Development Team. You will also need to give them the tools and training they need to be successful.
Give up the Matrixed Organization in Transitioning to Scrum
In my experience, the most successful teams are the ones dedicated to making a single Scrum project work (yes, you’re also going to have to let go of your beloved matrixed style organization where everyone works on one bazillion projects). Pro tip: You will get many, many more projects done if you let your staff work on one project on a time. If the project is important enough to you, it’s worth trying ALL the Scrum concepts and reserving judgement until the project is done. If you find that you weren’t more successful, you can always go back to your old way of working.
Realize What You’re Currently Doing Isn’t Working
The first step in making a change is to agree that what you’re doing isn’t working. If you’ve “tried Scrum, but it isn’t working”, you may need to look at how you’ve implemented the Scrum framework. In working with customers, I find that the framework itself is not typically the problem, it’s how it’s been implemented. Most of the time, in fact, I find that historically Waterfall organizations have a hard time making the full shift, and habits from the old way of working are still in place.
Scrum vs. Waterfall Checklist
Here is a quick checklist of 10 questions to you can ask yourself to determine whether you’re doing things the old way. For each of the items below, answer Yes or No.
- Do customers wait longer than a month to see fully-tested and integrated product features?
- Do customers complain about the amount of time it takes to receive the end-product or the quality of the end-product itself?
- Are my Scrum Master, Product Owner, or team members (the ones doing the actual work) working on more than one project at a time?
- Has it been more than a year since my Scrum Master, Product Owner, or team members received any sort of formal Scrum training or coaching?
- Has it been more than a year since our leadership team has received any sort of formal Scrum training or coaching?
- Do I have any issues receiving real-time visibility into the progress of the project?
- Does my team still use words like phases or phase gates, baselines, etc.?
- Do my teams spend a lot of time with upfront planning, creating a Gantt chart that defines all the steps of the project from beginning to end?
- When changes arise throughout the project, do we put them through a rigorous Change Control process?
- Do I reward my teams on project progress (% complete) rather than work delivered?
If you answered Yes to any of the items above, you haven’t fully adopted the Scrum framework. Need additional help or have more questions on making the transition? Let us know.