Three Ways to Bridge the Gap Between Waterfall and Scrum

January 31, 2021|INblog, business, technology|BYandrew greenstein

In the startup world, Agile is king. Entrepreneurs are constantly exploring new product ideas, new marketing strategies, and new business models. To be effective, their teams need a framework for creating that enables quick iterations and constant learning. As long as you apply one of the many frameworks of Agile, you can pat yourself on the back for embracing modern product development practices. 

But what if you don’t have the luxury of going Agile? In established companies that might be less focused on Exploring and more on Expanding or Extracting, this is often the case. Because the cost of shipping faulty software is sometimes prohibitively high, a waterfall approach where software is carefully designed, implemented, tested, then launched (in that order) is often the preferred approach to software development. 

Both approaches have their advantages and disadvantages - Waterfall results in less product variability, often at the cost of rapid iterative learning, but the end result is less error prone and more stable. Agile results in faster product increments, increasing the likeliness and speed of achieving product market fit, at the expense of stability. Which approach would you take if you were programming a search engine? How about a spaceship? 

Where scope in Agile is often variable, time and budget tend to be fixed. This is the opposite in Waterfall - scope tends to be fixed, whereas time and budget are often variable (much to the CFO’s chagrin). All of these factors need to be considered when deciding whether you want to, and/or are able to, apply one approach or the other. 

Sometimes you can apply both. 

We work with innovation teams at large organizations who often feel their innovation efforts are marred by their company's commitment to Waterfall. How, they ask, can they succeed at innovating new product roadmaps with such a bulky and linear approach? Here are three ways to consider.

Related: Everything You Need to Know About The Agile Software Development Life Cycle

Rapid Prototyping 

Rapid Prototyping is an approach to software development that emphasizes quick, iterative development cycles and minimal feature steps. Even though your organization might use waterfall, you can use Rapid Prototyping to test out a product concept, explore new opportunities, or evaluate a technology platform.

For product development, pick an Agile methodology and organize your team accordingly. Typical teams consist of a product manager, a scrum master, and a few creators (developers, designers, writers, testers). Researchers and/or data crunchers can help set up experiments and understand the results. Another way to organize your team is to identify and include the right minds. Spend a week or so (maybe even do a design sprint) to brainstorm objectives and ideate solutions. Treat each solution as a hypothesis, then validate it with a real user experiment. For our marathon training app SportMe, we believed shortening the onboarding would result in more subscriptions. We didn’t rapid prototype a solution - instead we spent months redoing our architecture so that users could experience the app without creating user accounts. When we A/B tested the results, we found that LESS people subscribed. It turns out that the investment users spent entering their data made them more likely to opt-in to the free trial. We could have discovered that valuable piece of information much sooner with rapid prototyping. Don’t be like the old us, be like the experienced us. Rapid Prototype! 

Related: What is Rapid Prototyping

You can also use Rapid Prototyping to evaluate a new technology. We even made a fun video about it. 

Design Sprint

One of our favorite arrows in the innovation quiver is the one-week design sprint. The process, which was pioneered at Google and is used by many successful startups and organizations, helps companies tackle big problems through a series of design thinking exercises that help conceptualize, ideate, prototype, and test new products. 

To do a Design Sprint, you need a couple of things. First, you need a problem to solve. Most features are designed to solve a specific problem - get user to do x, y, or z. Design Sprints provide a framework to solve sticky, complex problems in situations where the stakes are high. Blue Bottle Coffee used one to come up with the layout for their first online store, Slack used one to figure out the best way to explain their value prop to new businesses, and we recently did one to help an innovative workplace design firm explore automating portions of the furniture selection process for their clients. 

Second, you need a few people who really understand the problem and the variables. This usually comes down to someone who has the authority to make big decisions in the company (the Decider), someone who can make your idea look good (usually a designer), someone who talks to customers (can be a sales or customer support person), someone technical (a developer or maker), and a good writer (usually a marketer). You can fill out your team with a few other stakeholders, but cap it at seven and invite any additional experts to provide context interviews on day one. 

Finally, you’ll need an experienced facilitator who has gone through the process and can guide the activities and keep the team focused and on track. I know a guy :) 

Design sprints last five days and are roughly broken up like so: 

Monday - Start at the end and figure out the big picture goal - why are you doing this? That should be clear before moving forward. Pick a target audience and map the user journey from start to finish. 

Tuesday - Rapid Competitor research and brainstorm exercises, followed by sketches of feature ideas. 

Wednesday - Pick the idea, or pick a few to test against each other. Storyboard EVERYTHING - words, images, buttons, names - details matter. 

Thursday - Build your testable prototype. 

Friday - Test. Learn. Draw conclusions. 

 

It’s a long week. It’s a crazy week. But by the end of it, you will have moved your innovation efforts months ahead. 

Related: One Week Design Sprints to Prototype New Ideas

Team within a Team 

West Elm was looking for disruptive digital innovation without disrupting their existing eCommerce properties. To accomplish this, they brought on Luke Chatelain, an innovator and product specialist, to run their newly found innovation team. While the main West Elm production team was busy keeping the lights on and the digital operations humming, Luke and his team were busy building prototypes and testing ideas like chatbots, AI, and Progressive Mobile Web Apps with real users. Their work, which we partnered with them to implement, drove real ROI in the form of revenue per user and time spent on site, and got them featured in Fast Company and other publications. You can hear about this approach from Luke himself in our Podcast, the Innovation Cookbook (episode 3).  

There are countless ways to approach innovation from within an organization, or with the help of an external innovation agency like SF AppWorks. Whether you use Waterfall or Agile or something in between, we’d love to hear about your methods and compare notes. You can reach me at Andrew@sfappworks.com or on twitter - @abgr26


Andrew Greenstein
Andrew Greenstein

Andrew Greenstein is the CEO and Head of Product for SF AppWorks, an Innovation Agency. Andrew is (weirdly) passionate about uncomplicating the IT process for business enterprises, adapting to new technologies and trends, and helping to make technology accessible to anyone who can benefit from it...so everyone. 

When he’s not participating in hackathons with his team of developers and designers or helping clients improve their product development and innovation processes, he’s either playing basketball, traveling the world, or playing drums/piano. Andrew writes, speaks, and consults on the topics of innovation processes, Agile methodologies, and design thinking. He’s also an aspiring dog trainer to his golden retriever, Taco.

More posts from Andrew Greenstein