
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.)
When Icalia Labs starts working on the software development for a company, it is most likely the relationship would start with these key services:
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:
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.
As the Design Sprint grows in relevance, the methodology obtains support from various departments, namely:
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.
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:
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.
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:
These templates represent an iterative set of tools that make every sprinter’s life easier while evolving after every Sprint.
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:
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.
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.
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