Why this Agile principle is not as simple as it seems…and why it is a must
"Simplicity, simplicity, simplicity! I say, let your affairs be as two or three, and not a hundred or a thousand; instead of a million count half a dozen…and reduce all other things in proportion."
– Henry David Thoreau
"Simplicity – the art of maximizing the amount of work not done – is essential." This is one of the twelve essential principles behind the agile Manifesto, and I think it is one of the most critical and challenging for people and organizations attempting Agile.
Why stress simplicity?
Just what makes this principle so critical, anyway? I mean, when we say "maximize the amount of work not done", are we advocating laziness? Of course not, but I would say we are advocating efficacy. Increased efficacy – maximizing output for a given input of effort – means we are producing the most value for a customer with our expenditure of effort. And simplifying what we do…our processes, our code, our communication, any use of our time…will maximize the amount of effort we can focus towards producing quality product for the customer above anything else. And that is one of the value propositions of well-practiced Agile…maximum output for a given input. Simplifying software can also make it more flexible to extend and adapt, easier to maintain, and easier to learn for new team members. But simplicity itself can be hard at first.
Natural or unnatural? Science or art?
Our lives are getting more complicated every day. It seems to be a natural tendency for us to allow, or enable that to happen. Think about it…do you find it more of an effort to simplify, or complicate? A quick search on the term "simplify" on Amazon's book list yielded more than 1,300 books on the topic at the time of this writing. Want more proof that we crave help in simplifying? Think of the Staples "Easy" button. One of the more successful ad campaigns in recent memory was so successful, I contend, because it speaks to such a cross-section of our society that struggles with an overly-complex business and personal life. And every generation says that, in their youth, life was simpler (I'm even doing it now, with my own kids). It's actually become "outside the box thinking" to focus on simplifying. In fact it isn't natural, so it isn't easy…it takes focus and effort to simplify. And it is an art, rather than a science, because the answers aren't prescriptive. Ultimately, the answer to maximizing simplicity is between your ears – it's how you think and how you approach situations. You have to actively look for the simple answer, the simple solution. If you don't, when you finally step back and take stock of what you've built – system or process – you may have that "Rube Goldberg moment"…the realization that what you've built is something very complex to accomplish the very simple.
Example (click to enlarge):
Recently, I was watching the Discovery Channel series "One Man Army." It's a reality show where contestants with backgrounds in the military, law enforcement and extreme sports compete in various challenges for the title. In one challenge, they had to breach a series of barriers using only the tools provided. The barriers got progressively more challenging including a cinder block wall they had to breach with a sledge hammer while being sprayed with water. By the time they got to barrier 5, the contestants were adrenaline-charged and bent on destroying anything in their paths. At this point, the host said "what they don't know is that the door on barrier 5 is unlocked, and they only have to try the handle to move on." How often do we assume in our work that the answer to a challenge has to be complex…it couldn't possibly be that simple…could it? Yes, it could.
How to do it
While, as I said, the answers aren't prescriptive, here are a few pointers and concepts to keep in mind as ways to simplify your practices.
- Focus on simplicity…continuously. The importance of diligence can't be overstated. As I noted previously, our natural tendency is to make things more complex. Things will consistently drift in this direction – you'll see it if you watch for it – so keeping this a continual daily focus is important.
- Challenge your assumptions. Don't assume complexity is a forgone conclusion. Established processes, legacy code, tools and procedures…all are likely to remain static and unchanging unless questioned. One note of caution: I'm not telling you to go raise Cain across your organization and change the world overnight. Start with even your own practices and see if there are opportunities to simplify. You might find you end up leading others towards this way of thinking by your example.
- Framework, not process. Agile frameworks like Scrum are indeed simple in structure…even deceptively so. Resist the temptation to extend and augment them with more process. Again, some people will tend to add on additional processes to their Agile practices over time, assuming something so simple in structure can't be effective. Don't be one of those people.
- User stories. User stories are so powerful in capturing users' needs precisely because they are so straightforward and focus on what the user wants to accomplish, not what "the system should do" or the technical implementation should be. Use them as they were initially intended…as a starting point for a conversation between customer and implementation team. Try them, trust them, and practice face-to-face communication for requirements, and you will be amazed at the rapid rate of sound understanding that develops.
- "POW" modeling. I won't name them, but there are one or two modeling software programs out there I just can't stand to work with. They are complex, awkward, and by the time you've built the model being discussed in a meeting, creativity, flow, and some aspects of the design may be gone. Instead, I like to use Scott Ambler's "POW" modeling…the Plain Old Whiteboard. Quick, simple, dynamic…and just pull out a smart phone, snap a picture and email it to the team and/or stakeholders and *poof* you have model documentation.
- Manual task boards. My experience is that this is consistently the first Agile practice that nay-sayers change to something more complex. "Seriously…we build software. We can come up with something slicker than post-its, can't we?" "This looks like a children's classroom…can't we clean it up a little and use something electronic?" Now, I like electronic ALM tools, and there are several terrific ones out there. They will do a great many valuable things for you and make many aspects of your Agile life easier. But replace the good old post-it task board? Sorry…no. The effectiveness of a manual task board is in itself worthy of a separate post, but for now, trust me. I have lived it personally. Buy stock in your favorite office supply store or sticky note manufacturer. Then, go buy a ton of them and use them, and promote their use with others.
These are just a few tips on practicing simplicity. I would love to hear and share yours, and your views on the subject, as well. So as always, I welcome your comments and questions.
Editor's note: In my Agile meetup group, we're exploring the twelve Agile principles, one per month, over the course of 2012. If you are in town, please join us.
