“Simplicity—the art of maximizing the amount of work not done—is essential.”
Identifying the least-essential elements of a project in order to avoid doing those very things is at the heart of simplicity. Ironically, getting there can be complicated.
I have plenty of opportunities to hear from people through our coaching and software development engagements (call it “anecdotal research”) and learn from them. Even in our project-based work, we’re constantly educating people, and what I’ve found is that the above principle is the least understood. Isn’t “maximizing the amount of work not done” just a cumbersome way of saying “do less”?
Let’s dig into what this really means, what the implications are, and the complex nature of identifying complexity.
This concept has been stated a million ways and from dozens of business leaders and innovators. It’s what Jim Collins calls the to-don’t list. It is the organizing principle underneath the Eisenhower Matrix. It’s what lies at the core of productivity expert David Allen’s “someday” folder.
“Maximizing the amount of work not done” is about dedicating adequate time and analysis to what you’re not going to work on. The statement could have been stated as, “minimize the amount of work done,” but that’s not what we’re really talking about here. Minimizing work done just encourages folks to be lazy. In Agile, we want developers to remain active in the search for things to say “no” to.
This is how we introduce a good portion of Agile’s benefits. When you have a framework for saying “we’re not going to do that (yet),” you will spend more time focused on the things that are truly vital.
This is where batching becomes relevant. You can’t just take a complex project (which, once you understand the definition of complexity, includes almost every project we encounter in 2020) and make it simple.
What you can do, though, is break the large, complex project into compartmentalized—but still valuable—smaller projects. And then you can break those projects down into smaller parts.
Eventually, the result is a valuable component that is both simple to understand, knowable, and valuable. Imagine a process that looks like this:
This is easy to understand in software projects. Software projects are loaded with VUCA (volatility, uncertainty, complexity, and ambiguity). Almost everything about the project is based on interpretation, assumption, and emotion.
The answers to most questions about the project are a variant of “I don’t know” or “it depends.” Try treating it like a game of Clue. Break off a tiny piece of the project, the one most likely to get clear answers, and use that information to eliminate other unknowns throughout the rest of the project. (Or maybe it’s more like Minesweeper, where you tackle the knowns and through that process, slowly, you figure out unknowns—and hopefully nothing blows up.)
We recently built a solution that automatically creates Word documents based on data in a database. Our team didn’t have a Clue (#seewhatididthere) about the possibilities of automating Word documents, let alone what the customer was really asking for.
So, we batched and we broke it down, and we started small. We started with a tiny app that created a simple document that inserted one line of text into a Word doc from a database. We learned a ton and applied that learning to the rest of the solution.
So, how do we do this? Here are some steps to take to keep it simple:
A lot of professionals cling to their own subjective definitions of the word “simple.” For now, let’s stick with mine.
A simple system is one where:
Brushing your teeth is simple. Tying your shoes is simple. Opening a car door is simple.
Determining what’s enough is another story. Because the work we do is complex, and by definition unknown, we can’t know what “done” looks like until we get closer to the end of our timeline. In many instances, we coach customers to get away from the idea that something is ever finished. (When will Facebook be finished? When will Star Wars be finished?)
The simplicity principle in the context of “is it enough?” doesn’t really apply. The statement in the Manifesto is referring to all the other things you have going on right now. Maybe, many of those things can be taken off the list so that the current important thing you’re working on can be prioritized and executed. Orient teams around the enduring units of value, and ask “is this enough?” continually and frequently.
Everyone benefits from seeing immediate progress. For you and your team, those benefits include:
Customers also (and even more so) appreciate signs of immediate progress. Imagine you’re remodeling the kitchen. You come home on day one and see that a single cabinet has been installed, so you get a tangible sense of progress. If on day two you see another cabinet, you start to understand the pace at which value is being delivered. If, on the other hand, you see nothing until the last day, and on that last day you see a kitchen that doesn’t line up with your expectations, you’re not happy.
Let’s go back to that first cabinet. If you’re not happy then, you still have time to make comments before the kitchen is delivered. Even when that kitchen is delivered on time, that customer is going to be pretty dissatisfied if it’s not what they wanted.
In our company, we talk a lot about valuing outcomes over output. Scrum, for example, is really helpful in muting the condition of being overly focused on output, but only if you know how to leverage it. Remember, you’re breaking things down into smaller pieces so that everyone understands the incremental nature of what you’re building.
Scrum, when it’s not executed in the right context or by folks who actually know how to manage within it, is useful only for exacerbating the obsession with output. In Scrum, ideas or statements of value are added to the backlog. They are processed by the team and come out as deliverable value. But Scrum requires that you actually protect your backlog from items that are not expressions of value.
If you start putting “work” in your backlog, it’s going to come out looking like you did “work.” When that happens, that’s what you’re going to be judged on. So, get really good at speaking the language of what your customers/stakeholders believe is valuable (in other words: address their conceptions directly), and paint the picture of how you’re incrementally achieving that value.
Agile principles are the most useful when they’re applied correctly. If you’re ready to learn more about how to bring agile into the workplace, it’s time for you to check out our virtual Business Agility certification and training class or our Agile Fundamentals Bootcamp if you want a little more technical depth!