Successfully Integrating the Design Sprint into a Software Development Team

Young Design and Development Interns learning to run the Design Sprint during Icalia’s Summer Internship

Introduction

I currently lead the Design Team at Icalia Labs, and one of our most important duties as a Design Team is to collaborate closely with the Developers, building awesome platforms.

Currently, our power tool for kickstarting new projects is the Design Sprint. As I mentioned in a previous post, the Design Sprint recipe alone is not as powerful as a well-integrated, properly connected Digital Product Design process (with the Design Sprint at its heart, in this case.)

In this post, I’ll detail how we built strong pre-sprint and post-sprint strategies to allow the team to make the most out of the Design Sprint recipe.

This post is part three from a series of three pillars:

1. The first part covers general lessons learned from the Design Sprint and why is this relevant for Developers, Designers, and other disciplines involved in Digital Product and Software Development
2. Part two is about stuff going ‘under the hood’ not covered in the Design Sprint book
3. Part three provides a look at how to implement the Design Sprint in a more complete and integrated workflow of design and development (this post)

A Super broad view: Design Sprints + MVP development

If a firm hires Icalia Labs for software development, it is most likely the relationship would start with these key services:

• A two-hour long Discovery Workshop
• A one-week long Design Sprint (pretty much what the book states)
• A two-month long development process (focused on delivering a fully functional Minimum Viable Product)

All of the above, at its core, represents a very mature state of how Icalia offers Agile Development for our clients.

We make sure that the Design Sprint provides enough visibility for a quick and compact development exercise and repeat the cycle accordingly for continuously iterating the platforms we create, following simple principles:

1. We want all of our platforms to be co-designed with our clients
2. We want to focus on developing features that truly deliver value to the end-user
3. We want to make sure that any design we turn into code has been a) prototyped and b) properly tested with end-users

Most of the action happens during Sprint week, but the whole company supports this intensive effort.

With this in mind, the following practices across the entire company will make sense to you; and hopefully, these notes will spark ideas of how you can implement and extend processes like the Design Sprint in your own company.

Integrating the Design Sprint as a Company

As the Design Sprint grows in relevance as a service provided by Icalia Labs, the methodology obtains support from various departments, namely:

The Sales Team

• Engaging with new leads in rich conversations about Agile Development, and tools like the Design Sprint
• Delivering proper narratives communicated through our sales decks about the benefits of using such processes
• Running Discovery Workshops as a way to better scope the challenge to a Design Sprint + MVP exercise (more on this below)

The Happiness Manager (a.k.a. H.R.)

• Obtaining proper supplies and snacks for each Design Sprint
• Preparing the space at our HQ to shine when clients arrive
• Booking flights and hotels for traveling Sprinters

The Design Team

• Building general templates for typical deliveries before and after the Design Sprint week (more on this below)
• Expanding and adapting the recipe to fit specific needs (such as a more compact, 3-day Design Sprint; or a more dev-oriented Tech Sprint)
• Creating Design tools –such as UI boilerplates– to allow quick prototyping with high-fidelity
• And, of course, executing a lot of Design Sprints!

The Development Team

• Making occasional interventions during a Design Sprint, providing perspective on what the Sprint team is trying to accomplish (in terms of complexity and opportunities)
• Getting involved in early revisions of the post-sprint deliveries, ensuring that the proposed functionality considers feasible features (at least within our MVP development philosophy)
• Constantly providing feedback to the Sprinters about how to better scope and document functionality resulting from Design Sprint prototypes

A closer look at an integrated process

All the activities listed above describe the broad participation of different areas of the company. Nevertheless, we have a solid set of specific practices run with every Design Sprint.

Before the Sprint: Preparing a Common Ground

We found that jumping straight into the Design Sprint initially resulted in challenges related to scope definition. Clients would explore their visions freely on Monday morning (which is incredible) and then get frustrated by Monday afternoon (not so cool) when we would need to commit to a smaller part of that Bold Vision.

As an antidote to this, we created a Discovery Workshop. During the workshop, someone from the sales staff teams up with someone from operations (usually Designers) to facilitate a 2-hour first-dive into the project.

We take advantage of that initial contact with the client to get an overview of the project and the entrepreneur’s Vision for the next 5 years. The resulting conversation allows a facilitator to draw (usually on a large wall) a ‘map’ of the project, broken down into individual “chunks” of technology. After a large ‘tree’ is drawn and the project (superficial) complexity is revealed, we pick one of those ‘chunks’ (or branches) and suggest focusing on it during the Design Sprint.

This activity gives us a significant opportunity to:

• Validate with our clients that we understand and SEE their Vision
• Manage expectations in terms of what our first deliverable would look like (meaning: the MVP)
• Provide each party with clarity on how the project might evolve and develop a strong sense of ownership from both sides

By the end of the workshop, we grab our notes and fill out a Discovery Workshop Report, which will become a valuable tool for the team that will run the Design Sprint.

During the Sprint: Leveraging Repetition and Boilerplates

Since the Design Sprint is practically a recipe, it’s easy to plan ahead of time and develop some materials to avoid doing everything from scratch every time. We have created a lot of templates and boilerplates, for instance:

• Email templates for most common pre-sprint communication with clients
• Tools and guides for the facilitator
• Design assets in Sketch for Designers (mostly layouts and UI elements)
• Scripts for interviews with experts and testers
• We even have a favorite YouTube station for Tuesdays afternoon, when everyone is focused on their sketches ;)

These templates represent an iterative set of tools that make every sprinter’s life easier while evolving as sprinters happen after every Sprint.

After the Sprint: From thinking fast to thinking slow

During the Sprint, everything moves lightning-fast: each step forces the team to make decisions and take action. That is useful (and quite addictive) for a limited amount of time; but, after the Sprint, the team needs to shift gears into a more relaxed pace.

Many ideas spark during the Sprint week, and we try to capture them and turn each picture into an actionable item. The latter allows the sprinters to provide a smooth handover to the Development team and provide available evidence and documentation of everything the team learned during the Design Sprint.

Additionally, filling each of the pre-defined deliverables helps sprinters undergo a process of sense-making: revisiting the feedback from customers over the prototype; discussing in more detail design and development challenges; introducing the results to other technical and non-technical team members, and so on.

Among the most relevant documents we use to capture this learning, we have:

• A Design Sprint Insight Keynote, containing slides with practically all info generated (objectives, maps, How Might We notes, sketches) and general insight (mostly coming from customers’ feedback)
• A high-fidelity interactive prototype (nothing new here)
• A Post-Sprint Design Adjustments document, listing all relevant Design adjustments and requirements (think of this as our Design Backlog, considering that much Design work is needed after the Sprint)
• A Pre-MVP Technical Review Report, including commentaries from in-house developers about the technical challenges and scope estimates related to the results from the Sprint (very useful for Business Devs and our Operations Manager)
• A Detailed User Stories document, necessary for properly scoping the development work ahead
• And some other stuff still in the oven…

All of the deliverables listed above are now part of the Scope of Work negotiated with our clients and, more importantly, help us effectively move from an initial Design Stage to a Development process — with a more secure and stable base for the transition.

Moving into the Development stage

After every nut and bolt is in place, we move into a Development stage, as you might expect. What happens then is out of this post’s scope, but there’s still something important to clarify.

All of the practices and tools employed during the initial Design stage (Discovery Workshop + Design Sprint) allow our Development team to focus on delivering functional and usable platforms in record time. Keeping the promise of an aggressive time-to-market is not easy; we try to improve the tools and processes that support this strong execution with every iteration.

Some final notes

My main point with this post (as well as the other two in the series) is to provide other Product Designers with information about how we leverage the Design Sprint at Icalia.

I wanted to remind emerging Designers and Developers that, whichever the most trendy tool or methodology is out there for creating great software, what matters is a well-integrated collaboration process between Design and Development (and any other relevant area, as well).

Please consider reading part one and part two of this series for a broader understanding of this post, and please let me know if you found this post useful!

If I can help you better understand how to adapt a modern Digital Product Design Process in your team, or if you are interested in running a Design Sprint with my team, write us a line at weare@icalialabs.com