The agile principle #10 talks about simplicity. One of my favorites, quasi-philosophical, really hard to live by.
While this applies to coaching on any agile principle, the agile principle #10 is the one I like to coach on by asking: “what does it mean to you?”
Especially, because this principle was stated:
“Simplicity–the art of maximizing the amount of work not done–is essential.”
If you’d rather watch a video than read, check out my Youtube video on Agile Principle #10:
While people are sold on the simplicity thing, many get stuck in this “art of maximizing the amount of work not done”. Are we lazy? What could it possibly mean?
In a world where productivity is misunderstood and overrated, no wonder this one might seem scary.
So, if you yourself are getting stuck on what to think about when the agile principle #10 comes to mind, I’ll sprinkle a few ideas in this blog post. Feel free to use them with your clients and teams as well to provoke conversations if people seem to be a bit shock-struck.
It’s in the word
As a coach, you know the power of simply asking questions. So to introduce the thinking behind this principle without having to get dogmatic, you can just ask in any ideation or solutioning workshops:
- What does simple look like in this case?
- How can it be simpler?
- Is it the simplest it can be?
What you are basically inviting people to do is to avoid bells & whistles and strip ideas and solutions to the part that seems to be where effectiveness is.
Complex is difficult, messy, and long. It’s how many projects go off-track. It is how we end up coding for 4 weeks with nothing to show for yet.
Simple, on the other hand, is undoing ambiguity as we go.
But simple is different than crappy. Quality is present in simplicity.
The simpler something is, the easier for you to define:
- Is it done?
- Does it have enough quality/ beauty/ <desired attribute>?
Because you can probably reduce the definition of those things to a couple of bullet points.
If we go on that note, not only simplicity helps work to get done, but it also helps make change easy. And we know change will come, either by request or by happenstance.
Simple products
Agile principle #10 can manifest itself as simple products.
First iterations of a product can be very simple. Zappos was a simple website that delivered you brand shoes back in the year 2000. The premise is simple. The website was simple.
Zappos made millions with simplicity.
Great, loved products also evolve towards simplicity. If you look at the design of cellphones, something similar happened. Their look overtime got very decluttered.
Simplicity, especially in the world of software products calls us to avoid delivering stuff no one asked for and few people can justify. Because there is a cost not only to create, but also to maintain something on a product. You’ll be carrying dead wait if you don’t abide by simplicity.
Declutter the product. Avoid the shiny object syndrome!
It works for software, books, courses, any service or product really. There is always a point of diminished returns for when you add stuff into whatever you are creating. That point where adding more costs more, but does not bring any more value out of the product. The result? Bloated products, confused customer, overwhelmed developer.
Simple code
If you came into agile coaching from being a software developer first, I’m not sure you are old enough, but maybe you remember the mention on certain protocols like KISS and YAGNY.
KISS – KEEP IT SIMPLE STUPID
YAGNI – YOU AIN’T GONNA NEED IT
And that is because as developers who love their craft, they can get overzealous and future-proof and overengineer the solution. That’s why long phases of “design” are also unhelpful. Those mnemonics helped developers over time to keep their head into creating good solutions for what is needed, not for ten years from now.
Avoid future-proofing something you don’t even know works.
Why make your system able to support 1 million users if you don’t even have 100?
As a coach, help your teams notice that when they are avoiding simplicity, they are preventing shipping fast, frequent deliveries, constant feedback. That’s how much simplicity is helpful in the code.
Simple design will call for constant, elegant refactoring, which in turn increases quality.
Everything should be made as simple as possible, but not simpler
OK, apparently Einstein did not use these exact words, this is a compression of what he put on a lecture.
But I believe the old scientist was onto something!
A helpful tool to implement “simple enough” is why user stories were invented in the first place. Small enough, valuable enough. Small is easy to understand, to digest, to prioritize, to implement, to test, to deploy… you got the picture!
But understandably it is possible you are not coaching a software development team. Maybe a healthcare team or a marketing agency.
The question still stands about your team’s “code” or the artifacts they produce. Maybe they are prototypes and copy and creatives.
So, what can make these artifacts simpler?
Simple processes
Agile had a strong influence from lean thinking in 1990s. And in Lean, not simple means waste. And Lean is set out to destroy, to eliminate waste. Of which there are many identifiable ones in the blue center of the picture. That’s where the agile principle #10 came from.
But even if we don’t look at other methodologies, just think of this: when we consider our processes… think that it could have 3 steps instead of 10. 3 steps mean 3 chances of making an error happen versus 10 chances, one for each of the 10 steps. See how simple wins? Remove the fluff from your processes. They are the “just because”, the steps or checklists that are there “because we’ve always done it this way”.
Effective and efficient processes have a compelling reason for every one of their steps.
Not simple process also means spending more hours, either because it’s long or difficult to be executed. And working hours are expensive. Maximize value from these working hours. Be selective on the work you take (value) and how you execute it (effectiveness).
That’s simplicity in a nutshell for processes.
In software development, there are long discovered notions that help simplify the process for your teams without compromising quality. For example:
- Does your team need those long-structured specs? 99% sure they don’t. You need the analysis part, the conversation, not the document.
- Do you need to have refinement, then estimation, then planning? No, you don’t need any of that for a great agile planning session.
- Do you need all those test case scenarios for great test? No, let the code evolve to pass the tests.
The contrary to those 3 bullet points is more steps, more hand-off, more opportunity for errors and disconnect. Longer, more expensive and more error prone.
One final note here about simple processes.
A thing to consider is that processes evolve and over time they can get polluted again. And that’s why we continuously inspect ourselves, how we do things. To make them better. And the key learning is that lean processes (those with no unnecessary step) are actually built over time. You remove what is no longer needed over time.
Think of all that is in the process of making your product today. Think of what is in there that may or may not benefit the organization and may or may not benefit the product.
Ask “how can it be simpler?”.
Because competitors are asking themselves that and that is how they gain speed and spend less to produce a similar product.
Te art of maximizing the amount of work not done
When I said earlier that in some organizations we seem to get the productivity thing wrong, I really mean it. I keep hearing managers talking about their “resources” (their word for people) being utilized (ugh!!!) less than at maximum capacity.
If that is your scenario, show the following video to your leaders and help everybody avoid being busy!
How about you?
I started this post by asking: “what does simplicity mean to you?”
And I think this is the first step for you to evaluate your own understanding of the agile principle #10 and how it could manifest in your team, in your organization or in your industry.
Once you yourself feel comfortable with the question, you will be able to invite the teams and peers into it and facilitate a discussion.
Because remember that we coach, but we also teach and mentor and offer perspective as agile coaches.
So I invite you to end this post with one final question that is put into context:
How can your team(s) and even your whole department benefit from adopting some simplicity?
