We Need to Talk About Design Sprints
Everyone seems to be doing ‘Design Sprints’ and proclaiming the life changing techniques and evangelical product output they’ve achieved.
Design Sprints are all the rage at the moment. Yet often, I’ve witnessed their ineffectiveness or even worse their tendency to hinder or damage current design and development processes.
Just to be clear, it’s not that I dislike the Google Design Sprint model, they certainly have a place, but really they’re nothing new and the excitement around them can be damaging. The team should already have an ongoing design process similar to this anyway, giving it a title and a specific place in that full process can be valuable however it’s important to be careful when implementing them.
Design Sprints shouldn’t replace the design process
The team should already be employing a design process and whether they’re working with a designer embedded within an Agile development squad or with a designer in moderate isolation the process should be something they hold dear.
Design can seem quite mystical to some and Design Sprints do help to clear the muddy waters and get more people involved. Understanding the complexity and creativity required to be a designer is important and Design Sprints can help with that.
The danger is that people in other disciplines start to regard design as an isolated, time-boxed process with tangible and actionable output every time.That’s just not reality; product design and development should be continuous, not relegated to one week every few months.
A more effective long term way to open up the design process would be to have fully embedded designers, allowing developers to get involved more often with the product design and decision making. Lean UX is a great starting point for that and if used correctly can lead to design playing a crucial part of the Agile development process.
Design Sprints are not the design equivalent of Development Sprints
Generally development sprints run for one to two weeks and a Scrum Master (or Agile Coach) along with developers will plan features that can be completed in each sprint, based on the Product Owners priority backlog. This is a continuous process and releases should happen at the end of every sprint, with showcases and retros included to review work and discuss what went well and not so well.
This is nothing like a Design Sprint and using the same terminology could be confusing for both the team and the business. If they want to use terminology rooted in Agile development practices then ‘spike’ is much more relevant.
A development spike is when the team identifies a particular issue that needs to be resolved in a time-boxed period outside of the sprint. The spike will be focused on investigating, discussing and testing concepts to solve that issue and it doesn’t have to involve the whole development team.
This should be the same for designers; using integrated spikes in the development sprint when particularly complex design related issues are raised by the team. Or by initialising a spike separate to the development sprint to investigate product issues highlighted by qualitative feedback or quantitative data.
The latter does run the risk of becoming iterations of waterfall design within Agile sprints so be careful not to fall into that trap. Two weeks of isolated design work before a development sprint isn’t Agile and won’t solve any of the inherent problems of waterfall software development. Instead ensure that the team are focused on user issues to form a product backlog, issues that aren’t directly related to upcoming development sprints and include developers where possible.
Design Sprints can get business stakeholders overexcited
It’s great that business stakeholders are interested in design, even more so that they’re interested in new processes to achieve great product results. However I’ve often seen them get a little overexcited, throwing Design Sprints around like the often ill-fated developer Hackathon (pizza and coke do not a Hackathon make).
A Design Sprint should be initialised by the team just like a development spike. They should be empowered to highlight areas of poor product performance or functional complexity and suggest a sprint to investigate without the direct instruction of a business stakeholder.
Can stakeholders be involved in the sprint? Sure they can, just like any other discipline! But they can’t take control of the session like they might in business meetings. In a Design Sprint everyone is equal and it’s not a place for a stakeholder to push certain political objectives or product ideas, the session should be facilitated by the designer and all attendees should adhere to the sprint ground rules they set.
If the Design Sprint is being organised by a business stakeholder and not a designer or the development team then it should be obvious they’re on the wrong track and should quickly highlight their concerns. Unless that stakeholder is very accustomed to how the sprint should be facilitated and the exact area of focus the team should question what the focus of the Design Sprint is and why it’s even taking place at all.
Design Sprints often suffer from a lack of focus
Often, sometimes due to the above, Design Sprints can begin, or eventually become, unfocused. The aim of the sprint should be to target a particular product feature or functionality that isn’t performing how the team wanted or expected. The sprint focus should be based on quantitative data or qualitative feedback as the team needs to know why the feature isn’t effective and they should be using this time to investigate how it could be fixed.
Lack of, or blurry, focus ensures that the Design Sprint will either fail or be very ineffective. Even worse, if the team have been tasked with using the sprint to ‘brainstorm’ as many feature ideas as possible to solve a particular business problem. For example “We need to integrate our new recruitment partner’s data with cool new customer focused features and tools!” This is far too open and this kind of request isn’t the purpose of a Design Sprint, another workshop framework that is specific to idea generation should be used.
With this disregard for clear focus comes lack of tangible output, the team may have a long list of innovative new features but if they’re not solving a specific user issue then they’ll be placed far down on the priority backlog and most likely will never be spoken of again.
Design Sprints often include the wrong people
If a Design Sprint is instigated by a business stakeholder or the focus is unclear then inevitably the wrong people will be invited and the sprint process and ground rules probably won’t have been fully articulated to them.
When that happens there may be people involved who don’t understand the sprint requires their undivided attention for a whole week. If people are invited and say “I’ll come for the first couple of days” or “I might have to duck out for a bit” it should be clear that Design Sprint is doomed to failure.
Invite people from all around the business, even those that might not have a full understanding of the product or feature set as his can be incredibly valuable. They do however need to understand that Design Sprints are hard work and all attendees should be prepared to give their full attention to the week-long process.
They need to understand the procedures, rules and sprint focus before confirming their attendance. A sure way to break the process and to sour the opinion of Design Sprints throughout the business is having people attend who come and go when they please or take phone calls throughout because they’re too important.
Design Sprints need clear and actionable output
Finally and most importantly there needs to be a plan in place detailing exactly what actions the team are going to take after the sprint. If they’ve managed to avoid the pitfalls above then they should have been able to isolate the issue(s) and defined and tested the solution. This then needs to be built.
How quickly the team can do that will depend on the backlog priorities and level of effort required to develop the new features. This is a good place to be as it shows that they’ve managed the risks and the Design Sprint has been effective.
If they don’t have this, then what exactly was the output? What have the team achieved and how are they going to measure the success? If the output is a long list of possible new product ideas that can’t be built without further design or development work then the Design Sprint has been a failure.
Even worse a business stakeholder insists on a PowerPoint presentation of high fidelity design ideas for an internal showcase. At this point it should be crystal clear; the team should know for sure that they’ve totally wasted everyone’s time.
Design Sprint risks needs to be managed
If these risks aren’t managed then Design Sprints will be, at best; an ineffective method of implementing design within an Agile environment. At worst; they will be dangerous to the perception of design within that business and could help to undermine the integrity of a solid ongoing design process.
Although this could be the case, if the team has been able to closely manage the sprint and avoid the above risks then the Design Spike (as it should be called) can be valuable to the business and produce effective and measurable product features that solve real user issues.
I’m a Product Enablement & Ops Consultant with over a decade working in technology organisations, enabling product leadership to maximise their performance and impact.
Visit chriscompston.com to find out more.
