Framework vs. Framework: Agile and Waterfall

This isn’t a competition, and one isn’t better than the other. 

Coming out of the agile world, waterfall development is often vilified. That’s not how we approach conversations at Sketch, even though we’re an agile shop. The truth is it’s just a different type of tool for a different type of work.  

One isn’t better or superior. In my conversations, I try not to weigh them against each other, but instead educate clients as to how they function together. It’s not, in other words, a binary argument about which one is a superior methodology but more about how you decide when to employ one vs. the other.   

In every situation, no matter the client or project, the best way to come up with a process to solve complex problems is by starting with a simple and straightforward issue. How do we define the work in front of us? 

What Does Your Work Look Like?  

Before I start assigning methodologies of any kind, I need to understand the type of work we’re doing together. In engineering, problems break down into two categories: Empirical vs. Defined. 

Defined 

The same given set of inputs 

The same set of actions 

The same set of outcomes 

Example: Manufacturing 

Empirical 

Outcome is anticipated but not known 

Requires experimentation and trial and error 

Example: Software or product development  

When an artist starts a painting, they have some idea of what it will look like. But they develop sketches and study the subject in an iterative way to explore the subject as they go, not entirely knowing how it will turn out. So, when Graham Sutherland sat down to paint Winston Churchill, he knew his subject in a general way. He probably had no idea that what he would develop would be widely considered a masterwork of modern art.   

He knew he’d end up with a realistic image of Churchill, but it evolved with every sketch and brush stroke. When he started, in fact, Churchill asked how he would be featured, and the artist said simply, “It depends on what you show me.”   

Approaching problems and solving them works basically the same way (for the record, a client has yet to set the whole thing on fire when we’re done). Using artistic metaphors in business meetings can sometimes cloud the issue, but when I was playing with my son recently, I stumbled upon a conversation that nearly everyone understands.  

Defining Work Through the Lens of Lego 

Yes, you read that correctly. I mean Lego, as in the timeless children’s toys, the very ones that feel like you’re being stabbed when you come across one on the floor in the middle of the night barefoot and on your way to the bathroom. My son, like most kids, is a Lego fanatic, and when we were playing, I figured out a new way to explain this to clients without sounding like I was expressing any inherent preference for one methodology over the other.   

When you buy a Lego kit (like the one my son and I were putting together), it comes with specific instructions, pieces, designs, and steps so that what you end up with is the thing on the outside of the box. Today’s Lego kits are so defined, the different sections of the project are already bagged together with separate instructions. In other words, even the subsections are so literally compartmentalized, putting them together requires patience and diligence, but not nearly as much imagination or visualization. It’s a defined problem with a defined outcome.   

On the other hand, some days, my kid drags out the bucket of (undefined and non-compartmentalized) Legos and asks me if we can build a helicopter. How do I do that? What’s even in that bucket (and seriously, do they reproduce)? How many pieces are there? How do I organize and break down those parts before we can start the fundamental design for this helicopter?   

In that situation, we typically do something more agile. We have some idea of the outcome we want, but there’s quite a bit to unpack first to get there. 

Applying the Lego Metaphor  

I brought up this metaphor with a client for whom we’re doing an infrastructure project. The client said, “but agile doesn’t work for infrastructure.” My response was “Well…you’re mostly right.” Most of what we do in infrastructure is defined work. If I need to go set up a new server, I’m working from a checklist. There’s a defined outcome that follows a defined set of rules.  

In IT, I want to automate defined work as much as we can. When you hire creative and smart people, you’re mostly wasting their skills if they’re just following the instructions to put together a defined Lego kit.   

When I have a defined process for setting up a Tomcat server, I want that automated. Then, I can start using our team’s brains for more empirical work to drive innovation and creativity. Then we can use an agile methodology to solve the problems that we can’t easily automate.  

Freeing Up Humans to Innovate to Solve Human Problems 

I’ll say this again here because it comes up again and again when I’m talking to existing and prospective clients. Everything isn’t agile and everything isn’t waterfall. Leaders and project managers can and should use a set of problem-solving fundamentals to solve different types of problems.  

Even in heavily regulated industries, there are certainly some things that we always have to do. In healthcare, let’s say, the state has a very specific requirement for what data has to show up where and when. But the state doesn’t specify how to do it or where to resolve those data requirements. How we solve that problem isn’t any different than solving any other business problem. So rather than starting with the solution (It’s regulated! It’s waterfall!), I start with the problem or the goal, then work backwards to find the best way to tackle it.  

When I meet with project leaders, I’m not really there to sell agile. I’m there to solve problems, and I’m looking for ways to automate defined problems so we can free up our combined resources to use our creativity more effectively.   

Agile isn’t a goal. It’s not the be-all-end-all. It’s just another tool. If I’m manufacturing cars, I’m not going to use Scrum because making a car is the ultimate defined product. It’s highly regulated, it involves a very specific machining and engineering cycle. We’re literally not reinventing the wheel.  

But, if I’m developing a totally new piece of software, I’m not going to lay out a traditional waterfall methodology of gathering all my requirements, writing all of my code, and testing it because I’m probably going to be wrong somewhere down the line. To do that in the right way, I need shorter feedback cycles.  

We Call It Software Development for a Reason 

I spent my early career in aerospace, and while there was some creativity in the early design phase, the final production phase for aircraft is quite specific. The reason we don’t use the term “production” for software is because we rarely build the same thing twice. When we do, simple tasks can often be automated, and we shift between defined and empirical work so our teams can use their creativity for development.   

My goal is to take the most predictable tasks (like writing a script to create a table) off the task list so you have more availability for your teams for interesting development work and critical thinking skills.   

My other goal is to broaden the view of our clients and colleagues so that every problem isn’t tackled in a rote way. Behind every problem could potentially lie innovation, but you’ll never know if you’re married to a single methodology. With shorter feedback cycles, you have the information you need to work backwards from the problem instead of prescribing a solution to every problem. 

Why are you doing what you do, and why are you picking those solutions to solve those problems? How do you get your defined work automated so that you can use more creative problem–solving skills, and using people to do more people-oriented things?   

Listen, if it were easy, everyone would do it. That’s why we’re here. Wherever you are in the process–any process–we’re ready to discuss solutions to your business problems.