How much up-front design work should we do?

Agile methodologies, such as Lean, Scrum and Kanban, which started in manufacturing and have seen widespread adoption in other industries, such as software development, advocate an iterative approach to product development. It is an almost universally accepted truth that, except for some specific cases, the big, design up-front process, often referred to as the Waterfall Model, is an outdated delivery methodology.

In order to work on a particular product or feature, some design is clearly required, but just how much? This question cannot be answered without thinking about the way we define a feature. To minimise up-front design and re-work, we should try to break down our initial or subsequent product release into small, easy to manage iterations. Smaller features are easier to imagine and reason about and significantly increase the chance of getting it right first time.

As we evolve the product through the accumulation of these small features, we gain experience and feedback, which we can apply to the design and development of subsequent releases.

Put simply, the answer to the question, “how much up-front design work should we do?” is that we should do just enough to enable us to build the small feature we are currently focused on. No more, no less.

Obviously, dependencies between features within our product may well exist, so extra consideration must be put into the design of these parts. Often it can make sense to prioritise our backlog of work to ensure we build these dependencies in a sensible order.

Gathering Feedback

“Move fast, break things” was famously the mantra of Facebook for many years. The spirit behind this phrase was that new tools and features on the platform might not be perfect, but speed of creation was vital, even if there were some missteps along the way. This is clearly a great way to get new software products and features into the hands of users, but it relies on a responsive product development team that is set up to gather feedback and respond quickly to it.

When releasing new features and products to users, ensure that you have sufficient processes in place to gather their feedback and respond to it. It is to your huge advantage to make it as easy as possible for your users to give you their opinions, but be sure to respond to them, both in terms of a direct response to thank them for their feedback and by investigating and prioritising work to address their concerns as necessary.

In most cases, users, with perhaps the exception of your biggest fans, will simply move to a competitor’s product if yours is failing to fulfil their needs and they see no apparent improvement in the pipeline.

Let’s break down the Facebook mantra into its two constituent parts; moving fast and breaking things.

Moving Fast

Of course, the desire to “move fast” requires that you have sufficient processes and infrastructure in place to support this aim. Moving fast necessitates a quick and efficient way to release new versions of your product and reprioritise the items on which product developers are working. A big up-front plan for product development won’t work here. You must adopt an Agile mindset.

Much has been written about the seventeen people who met in a Snowbird ski resort in February 2001, their motives and their work to create the Agile Manifesto. I will not spend the time here to outline the manifesto itself. There is plenty of material available both online and in books, but it is essential to recognise that, to achieve Agility, you must focus on fast feedback and responsiveness to change at every level of your organisation.

I have witnessed first-hand the failure of startups who have waited to deliver the grand vision of a big up-front design instead of getting initial versions of products into the hands of users early to gather feedback and make refinements.

If you are building a software product, I highly recommend reading Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and David Farley. This book will guide you through the principles and techniques needed to enable rapid and incremental delivery of valuable new functionality to your users.

Breaking Things

"Breaking things" does not mean that you should release low-quality products. You should never send out untested products to users. However, with the right processes and infrastructure in place to enable rapid fix-and-release cycles (and maybe the odd rollback), you should have the courage to gather feedback on new functionality, communicate with your customers and release updated and improved versions quickly.

This is the key to Agility and hence the key to a successful, responsive, iterative product development strategy.

The Importance of Vision

Whilst low-level design is best done as close as possible to implementation, there is a potential pitfall to avoid - lack of vision.

Working continuously on small iterations of a product can result in an incohesive or incomplete product design. Building iteratively on small features, growing it from the inside-out, can lead us down "rabbit holes" where some parts are built out in depth while other essential aspects are less developed. Ultimately, this can lead to an inconsistent and frustrating user experience.

In addition to this, it will be very hard for team members to make sound tactical decisions on the design of the low-level components without knowledge of the vision for the future of the product. This can lead to designs which, although perfectly sensible for the current understanding of the system, may not be suitable for building on in later iterations. Such a mistake can result in expensive rework or a decrease in future productivity.

With this in mind, it is important that a high-level vision and roadmap for the product is created, maintained and communicated to all levels of the organisation.

Some of the links to products that I have provided in this article are affiliate links. This means that the supplier may pay me a small amount of money if you use the link. This will have absolutely no impact on the amount you pay.