When my old firm first introduced us all to the Agile software development process – which is a kind of kissing cousin of Design Thinking – we found the whole thing very fuzzy and amorphous, like trying to catch a cloud and tie it to a chair. There were many moments when we came up against a knotty problem and realized that we were supposed to resolve this as a team, rather than looking to one person in authority to hand down a decision.
This was always a slightly scary moment – the authoritarian structure to which we were all accustomed had morphed into a cloud-like structure with no support. Agile calls these issues “Spikes” and we assigned the task of researching our options to a single individual, sometimes at random and sometimes because that person understood the problem slightly better than the rest of us. The Spike was “timeboxed” – enclosed by a strict time limit – and typically did not exceed four hours of research.
Beyond this minimal, restricted effort, there was no real process for finalizing our conclusions other than debating it in rather confused fashion during our Sprint Planning sessions. As often as not, the VP of Development would hear of our dilemma, swoop down, issue an edict and zoom off, leaving us feeling as if the entire Agile process had been hijacked and many important points left unaddressed.
A potential solution to this ongoing head-scratching, Design Thinking encourages a creative mindset that includes elements like empathy for the user, broad-based experimentation and the open acceptance of failure as essential parts of the process. Design Sprints are the practical extension of Design Thinking and are the obvious solution to design dilemmas, large and small, encountered so frequently in workplaces where engineering, designing, and creating are central to success. Versatile enough to resolve many a problem well beyond the narrower limits of the software problems addressed by Agile,
Producing solutions iteratively is, of course, a key component of Agile, as are Sprints. Moving through iterations to reach a definitive solution feels like a very natural process to human beings, and would seem to describe how we do our best work – gradually, in stages of insight and discovery, rather than planning and then producing a perfectly finished product or idea in one dramatic wave of the wand.
Diversity, collaboration, and viewing problems from the user’s perspective (another basic principle of Agile) are self-evidently critical to a process where the essential idea is to brainstorm as creatively as possible. Ideally, you want people thinking outside the box as you work to ideate creative solutions, and the best place to find such folks are outside your box – someone from another industry entirely, or from outside any industry entirely, such as an academic or a member of the military or the government. You also want these folks collaborating with each other comfortably, and you want a proven structure that will produce one or more brilliant, outside-the-box solutions once the sprint is complete.
Design Sprints can be any length, from a few hours to a week or even an entire semester. Learn more about the proven structure of Design Sprints, and how they really work, by checking out our blog post Design Sprints: A Winning Idea.
Not only does C-TRAC assist and support the US Air Force’s highly-successful Design Sprint program, CyberWorx, but C-TRAC is also a leading facilitator of Design Sprints for any industry or organization with a difficult problem needing a solution. Contact C-TRAC today at info@C-TRAC.org to learn how we can help you creatively solve your most perplexing issues.