Simplicity for Building the Right Thing
At GOTO Amsterdam 2013, Russ Miles did a lightning talk in the hard things made easy track about building the right thing in 5 questions. He referred to the 4 questions from impact mapping by Gojko Adzic “Why? Who? How? and What?” and added one additional question “What assumptions underpin everything?”. Together they become a simple tool which helps to make product and technical roadmaps, and to build the right thing, right.
He shared his view on complexity and simplicity:
"Complexity is the silent killer of delivering the right software, or change, at the right time; it is singly responsibly for killing many good ideas and companies. A focus on simplicity is the answer, but simplicity is not easy. Through our techniques and practices, I help software delivery organisations and teams ensure their solutions are as simple as possible while not missing the mark by over-simplifying." – Russ Miles, Formation of Simplicity Itself, 2013
InfoQ did an interview with Russ Miles about building the right thing using simplicity.
InfoQ: Your lighting talk at GOTO Amsterdam 2013 was about building the right thing. Why is that important?
Russ: We've spent the last 10 years building really great engines of potential software delivery in our organisations, and those engines are beginning to really hum. These days the problem is not always about how to deliver something, it is how do we build the right thing or, as is often the case, whether we should decide to build anything at all.
Software development and delivery is not easy, and so my main focus at this level is around avoiding wasting people's lives building software that is either overly complex or not in fact the simplest answer to achieve the real goal.
InfoQ How does simplicity help you to build the right thing? Can you give some examples?
Russ: Building the right thing (or not as I mentioned above) requires a roadmap where goals and assumptions are made explicit and can be tested. Simplicity's governing value statement, i.e. "Reduction to the point that any further reduction will remove important value", is a good governing value when selecting from the various options as you traverse your roadmap towards your stated goal.
In this way, Simplicity is your guide through your roadmap and helps you build what is necessary to move forward, without over or under-complicating in the meantime.
InfoQ: You talk about "remove unnecessary and costly complexity in everything from developer skills and practice". That sound somewhat similar to Lean?
Russ: I think there's certainly harmony between the Lean, and Agile, values and principles and Simplicity; in fact in many ways Simplicity underpins both efforts.
It is my intention to turn Simplicity from being a blurry, vague value into concrete principles and guidelines that affect all facets of software development and delivery. Some of that will will be firmly rooted in Lean and Agile when it comes to processes, but it will also extend into the structure of the very software we build.
Optimising a process for adaptability through Simplicity while at the same time building complex software that actively fights against that adaptability is a fools errand; my aim is to reflect Simplicity throughout so that we can not only be adaptable in terms of what we decide to build and our process but also in our software.
InfoQ: Most people hate complexity, so wouldn't they be doing already everything they can to make things less complex?
Russ: Unfortunately complexity is not easy to identify and a lot of personal bias and confusion exists around the term 'Simplicity'.
Simplicity is an objective measure of the level of entanglement in our architecture, design and code but it is not always obvious to us where that complexity is and where we're introducing it. It's all too easy to add complexity to an existing, naturally or inherently complex problem domain.
It is that introduced complexity, what we call extrinsic or accidental complexity, that I am helping developers spot and fight because the competitive rewards, essentially more adaptive and agile software, are huge.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015