There’s a common scenario with some implementations of agile methods that – I believe – leads to poor design.
For ‘agile’ teams that suffer from this, their process will often looks like this – time is spent up front, creating a rich and high fidelity design that is then fed into development for incremental implementation (bear with me if you’ve spotted the inconsistency already). With this approach, there are a few possible outcomes:
- We discover during implementation that certain elements of the design aren’t feasible.
- We discover during implementation that the design is more complex to build.
- Both 1 and 2 together.
- Everything goes perfectly – we deliver what we planned and on time.
Let’s take a look at these possible outcomes in more detail.
Feasibility
When we create a design solution up front, then commit it to development, the successful implementation of it rests largely on a number of assumptions. Even when technical members of the team are involved in creating the design, without actually doing the work, assumptions about feasibility still exist.
When implementing the design and it’s discovered that part of the design isn’t feasible, it means the design needs to change. The impact of that might not be profound; perhaps just a small workaround is required and much of the design integrity is maintained. However, multiple small workarounds can result in a more significant degradation to the coherence, nuances, and holistic being of the original design. It can even lead to a point where the design is no longer fit for purpose. It’s like designing a Ferrari, but part of the body ends up like a pickup truck.
It’s also possible that more than just a small adjustment is required, and instead an element of the design which is central to the experience needs to change. Imagine if some of the design is implemented, and it’s discovered that one part upon which the rest of the design is based isn’t possible to implement, or at least not as originally intended. You could remove this element and significantly impact the quality of the design, revisit the whole design and incur costly rework, or stick as close to the original design as possible and accept compromises and defects. No option is a good option. It's like designing a Ferrari that ends up, at best, with the wheels of a push bike or, at worst, with no wheels at all.
Complexity
Building a product is an investment, and any investment is based upon receiving a return. Therefore, when deciding what to build, how much it’ll cost is a key factor in assessing the return on investment (ROI). When committing to a design up front, how long it will take to build is based again on a number of assumptions. So when unforeseen complexities are encountered during implementation and things take longer than expected, the ROI based on the original design is negatively impacted.
Of course, a depreciated return as the only outcome assumes that the extra time needed to implement the design was granted or available, but that’s not always the case. Sometimes there are budgetary constraints, hard deadlines that need to be met or windows of opportunity that need to be leveraged. When this is the case, we again start to move into the territory of compromise. Our options are similar to those described above – implementing a reduced version of the original design, or making technical compromises which lead to a poor quality implementation that is less performant, degrades the experience, and will likely result in software defects.
It’s a bit like designing a Ferrari for a planned 20% profit, only to end up with 5% and the engine of a moped.
Everything Goes Perfectly
Strictly speaking, it is totally possible for the building process to go perfectly. However, the likelihood of this depends on the uncertainty of the path ahead. When you require bespoke solutions in a new or changing environment, the degree of uncertainty is high. Operating Systems, hardware, tooling, and programming languages are constantly changing.
For things to go perfectly, it requires all of our assumptions to be correct, for there to be nothing that we don’t know, for there to be no hidden complexity, and for nothing to change along the way that’s outside of our control. Again, everything going perfectly is possible in highly certain environments, but modern digital product development is anything but certain. How many experiences in or with product teams have you had where every has gone exactly as planned? I’m yet to find, hear of, or experience such a case.
The Root Cause
When discussing the issues around feasibility and complexity above, you might have noticed that the feedback received from the process of implementing the design could if viewed a different way, actually be considered valuable. I’m sure that had the team known the resultant information prior to creating the design then they would have chosen to create a solution that was more appropriate for the constraints ahead. Of course, we’ve also learnt that this knowledge can’t be acquired up front – we have to actually do the work to uncover what we don’t know. The real problem then is that the process employed to separate design from development creates a resistance to change, as opposed to an environment that embraces that valuable feedback.
You might also have noticed something amiss early on in this article (I hinted strongly at it), which is that the process I described for these ‘agile’ teams is in fact more akin to a plan-driven process, characterised by sequential stages of delivery (e.g. analysis > design > development > testing > deployment). Often this is disguised under practices associated with agile methods, such as work being broken down and delivered in ‘sprints’, and maybe the work is even estimated in ‘story points’. Despite this camouflage, design and development remain largely as separate activities. To reiterate – I agree that this way of working often leads to a poor design outcome.
A Different Approach
So what would good look like? Instead of design and implementation being sequential, these would be done largely in parallel with close collaboration between design and technical team members, and above all, with a feedback mindset. Rather than trying to get everything right before we start building anything, instead we visit the big picture view of our product with just enough fidelity and confidence to start making decisions (e.g. user story map, sketches, low fidelity prototypes etc), take some small but real steps forward (actually build a part of the product), get feedback from those steps (design and technical feedback), and then incorporate that feedback into our big picture view and decision making on how to take our next steps.
So as an alternative to designing a Ferrari at the beginning, instead we have a vision for an incredible transportation vehicle, but start by building a great skateboard, gather feedback on that, and then continually increment and iterate towards the vision. It might end up as a car, but maybe it’ll be a boat, or maybe all the user really needed was a simple push bike.
Credit: Henrik Kniberg for the original inspiration for this gif.
By working this way opportunities to adjust course are maximised, and design is more emergent in nature. This means that the resultant design works with the constraints that are uncovered along the way whilst also still delivering the desired outcomes.
Of course there are challenges to this approach, such as achieving and maintaining stakeholder buy-in, maintaining team alignment, fostering collaboration, working out when and how to test concepts with users, optimising for flow of work rather than utilisation, avoiding ‘chuck the design over the wall to keep developers busy’ behaviour, working with other parts of the business that are less responsive to change, and maintaining a holistic view of the product and technical architecture. This is by no means an extensive list of considerations and each a topic for a blog post in their own right.
‘Up front design’ I think also is an all too encompassing phrase as the right design activity up front (for example discovering who our users are and what they value), both before building a product or a feature, is important and valuable in order to reduce the risk of building the wrong thing altogether, or the right thing but in the wrong way. This too is a post for another day.
Ultimately, I hope that readers of this article have been able to relate to some of the scenarios I have described and, as a result, will take some time to work with their own teams on improving their ways of working. If you’d like to know more, or just want to throw some ideas around, then you can reach me here. Alternatively, for further reading on the topic I recommend ‘Product Fail’ by Marty Cagan which focuses more on the product outcome, and ‘Beyond Staggered Sprints’ by Jeff Gothelf which describes a design team’s journey away from a sequential process.