Evolutionary design works by growing a system one capability at a time, keeping the design just sufficient for the system so far. As needs change, the system evolves to meet them. Evolutionary design has its technical challenges, but limiting beliefs and misunderstandings are often the biggest barrier.
The Product/Customer Side
Have you heard or said any of these?
“All I want is what I want, when I want it.”
“Everything is a must-have.”
“Everything is #1 priority.”
“Who are you to question my requirements?”
“Fixed-scope, fixed-schedule.”
(If you’re on the customer side of the team, don’t worry – everybody gets their lumps today.)
Traps
The business can fall into several traps. This is not just “mean” or “bad” customers: it’s a response to behavior generated and rewarded by the environment.
- Adversarial relationship, where customers ask for twice as much as they need, because they fear they won’t get half of what they ask for.
- The “Requirements” trap: The word “requirements” fools us into thinking things are, well, required. Most times, they’re ideas that need to be assessed and traded off against resources and other ideas.
- Solutioneering: Requirements are framed not as “what’s” – problems or needs to address, but as “how’s” – predetermined solutions. Locking in on solutions without understanding the problem orients us the wrong way. (And even if we succeed, we risk getting what we asked for rather than a solution our problem.)
- The “all-or-nothing” fallacy: The users today don’t have everything you think is needed, and they’d be happy with some subset delivered sooner. (Or perhaps – they hate your chosen direction, and you’re better off knowing that sooner.)
Addressing the Traps
How can we address these?
- Explore problems and how we’ll know we’ve made progress solving them.
- Collaboratively explore ideas – many solutions may be acceptable.
- Make sure stories tie into needs.
- Recognize that solving most problems is iterative – our attempted solutions may need further work.
- Look for smaller steps that still represent progress.
- Recognize that while a user story’s title may capture the essence of a needed solution, there are often alternatives within that scope, and we can look for smaller increments of progress.
- Take advantage of the shippable (preferably shipped) evolving system to get feedback.
I’ve definitely been on the wrong side of this. In an early e-commerce site, we spent a lot of time creating a catalog, building an ordering system, etc. When we went to deploy, we learned (at least:) three things:
- We’d missed architectural process requirements of the larger organization.
- We needed additional info on some pages to meet legal requirements.
- (Most devastating) The business didn’t really need a full site yet – they weren’t looking for “sales, sales, sales” but rather “Can we drive traffic to the site?” (They wanted to explore things like credit card stuffers, online ads, etc.)
A far smaller initial effort – perhaps even just a single page – would have been enough to answer those questions. That experience really brought home the importance of understanding what’s truly critical and focusing on delivering that first.
Management
How about these?
“We need to know exactly what will be delivered when.”
“Plan the work and work the plan.”
“Refactoring is rework, and rework is waste.”
“We all just have to give 110%.”
“Velocity was low last time, so we’ll plan for double that to catch up.”
How can we get beyond these?
- Drop the assumption of a fixed plan: Agile is built around feedback and learning. One of the big opportunities with agile methods is that you can adjust plans based on what you learn, rather than plans built when you were most ignorant about the project’s needs.
- Recognize that refactoring is a necessary part of the evolutionary approach. Rather than speculate about everything a design needs, we’re taking some of that design thinking and effort and applying it to the code we have so far. It’s sort of like the writing advice to get a poor draft written then edit – it’s easier to change concrete decisions than to seek initial perfection.
- Allow room for experiments: if you’re heads-down, working too hard all the time, you’re unlikely to have the bandwidth to explore new ways of working. If your current approach is unsustainable, you’d better figure out a better way.
Testers
Testers are often concerned too:
“We can’t test without the requirements fully specified first.”
“Iteration means we have to test the whole system too many times.”
“There’s no point testing an incomplete solution.”
Have you heard the phrase “shift left”? It’s applied to an activity that happens later, but something else could be done earlier that would proactively address the underlying goal.
Testers have often been told that testing is to take a specification and software, and assess whether the software conforms to the spec.
But this isn’t the only kind of testing. It’s also valuable if people with a tester’s mindset can shift left: get in on early discussions and decisions around design and code, to better align understanding, and provide early feedback based on their perspectives thinking like a user or adversary.
It’s also valuable to give early feedback on code. Coding involves many decisions that depend on earlier ones, and feedback on the foundation saves work later.
The Development Team
It’s not just business that makes evolutionary delivery harder. If you’re a programmer, have you ever heard or said…?
“We may as well do everything while we’re in there.”
“I already know what they need.”
“Resume-driven development.”
“Let’s build a framework first; then it’ll be easy.”
“The user will also want…”
“Let’s write this in [cool language/tool of the month].”
“Just tell us what you need.”
There are several traps:
- Non-communication – not collaborating with the project community to find out what’s really needed and what’s most important.
- Order-taking – Waiting to be told what to do rather than addressing a problem.
- “Speculative Generality” – generalizing (often wildly or incorrectly) beyond what we’re currently doing, in hopes of future payback.
- Personal interest – putting personal desires above true business needs.
I’d rather write software to write software than write software.
Dick Sites
We’re not really as good at guessing as we tend to think we are. When we guess wrong, we have to pay to rip out the wrong guess, then pay again to add what was really needed. The evolutionary approach tries to get rid of this extra expense.
Feedback and Evolutionary Design
Some teams aren’t clear where they’re going or how they’ll actually get there, yet they build detailed plans up-front, and rigorously pursue them: “Plan the work and work the plan.” This leads teams to focus on “say-do ratio” or “burndown” – internally focused metrics that don’t address the real need.
Instead, get feedback – “Get out of the building”, as Steve Blank puts it (see References). Find ways to get feedback as early as possible – so the team can adjust if needed, or stop early if needs are met!
If your first feedback is during “User Acceptance Testing”, it’s way too late to cost-effectively fix anything.
Agile, evolutionary design, Lean Startup, lean software development, etc. – all are trying to provide you tools to increase the level of feedback, so you can drive toward what you know you need now, rather than what you thought you needed when you were most ignorant – at the start of the project.
Conclusion
Whether you’re part of the customer/user or development teams, it’s easy to get entrapped in a mindset that wants everything or focuses on solutions over problems. Instead, explore where incremental and evolutionary approaches can help you get feedback faster, learn faster, and ultimately deliver solutions faster.
References
“Speculative Generality“, by Bill Wake. Retrieved 2021-05-04.
The Startup Owner’s Manual, by Steve Blank and Bob Dorf.