Successfully Integrating the Design Sprint into a Software Development Team

Warming Up for the Design Sprint

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 new projects is the Design Sprint. 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.)

Want to discover how we build strong pre-sprint and post-sprint strategies to allow the team to make the most out of the Design Sprint recipe? Keep reading!

A Super Broad View: Design Sprints + MVP Development

When Icalia Labs starts working on the software development for a company, 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 the above, at its core, represents a very mature state of how we offer an 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, 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 boiler plates– 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 Boiler plates

Since the Design Sprint is practically a recipe, it’s best 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 boiler plates, 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
  

These templates represent an iterative set of tools that make every sprinter’s life easier while evolving 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 tend to 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 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 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

Now you know how we leverage the Design Sprint at Icalia. 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)

If you want more information on 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