Challenges Integrating Design Thinking and Agile Development Practices
Have you ever seen rabbits in the clouds? Or perhaps a face in the flames? Psychology dictates that in our constant search for patterns, humans look for context and meaning in the most insignificant of constructs.
There is an element of order in building software. Design and architectural patterns help us avoid the same old pitfalls. The old ways must make way for new inventions. Out of the box thinking is the sole method of solving new problems. Mechanisms that encourage innovative thinking can stop us seeking patterns and ignite ingenious ideas.
Design Thinking is regularly touted as a process for the development of innovative solutions by designers. Yet integration with software development practices are critical to ensure the successful adoption of the solution. As we embark on our latest development journey, I ponder the potential for integrating Design Thinking and Agile practices, reflecting on my recent readings and challenges.
Think Again
One key concern with utilisation of Design Thinking is the premise that it allows definition of a full solution upfront. Locking in every requirement upfront, regardless of the published format, doesn’t allow for lessons to be learned.
As illustrated above, Design Thinking is an iterative circle, not a fixed length line. It doesn’t have to be weeks of upfront workshops. Iterative development must start from the beginning, in the empathy stages. Some teams have had success with using Sprint Zero workshops to establish common ground and agree the required high engagement levels between technologists and business. Where all parties identify the challenges and the initial story set sounds like an ideal compromise.
Utilising a cyclic method in both Design Thinking and Agile practices allows not only the product definition to evolve. Knowledge of user processes is not static. Our education undergoes peaks and troughs not only as features are adopted, but also as they change to address new challenges. Having an initial empathy gathering stage prevents the identification of additional walls that are built as user processes mutate.
Think How It’s Gonna Be
There is a common misconception that exercising agility means you are mindlessly react to new requests. Some think it is a reactionary journey, where teams take every turn on the route, rather than driving straight down the motorway. At times I have felt our journey has turned into blind country backroad turns taking us further into darkness.
Building a solution to such complex business problems needs us to understand where we are going and how it will solve our clients problems. A product strategy serves as the GPS on our Agile journey. Identification of challenges and high level themes using the empathy and define stages. As stated previously, precise stories can be defined over time in line with our goals, over an initial big bang approach.
The definition of hills may provide a mapping between these processes. Recent reading this week helped me discover these tools for defining the identified problem, with a corresponding user outcome. Peering at the above example, doesn’t the who, what, wow format appears surprisingly familiar to our favourite user story format? Given this similarity, formulating a journey using user story mapping techniques can help you identify a product strategy.
Think of Tomorrow
Designers are often the primary facilitators driving Design Thinking processes. A common challenge discussed online is how to foster collaboration between software developers and designers. Programmers, designers and business users alike all speak different languages. Nevertheless, early engagement with all three parties will establish the required communication channels.
Although blue sky thinking is important for ideation, how do you assess the technical feasibility? In the dream evolutionary paradigm, new ideas to solutions will need to integrate with the existing software.
By excluding technology from the table, technical feasibility of any solutions is not considered. Designers and users require early engagement from technologists to help advise on the product details pre-prototyping stage. Software engineers need to meet them half way to collaborate to build the best possible product.
Think it Over
We have been travelling down the Agile road for several years now. Clearly this is the start of our ongoing journey with Design Thinking. Musing over any identified obstacles in our software development has always helped us employ continuous improvement. Ownership of your process means we must strive to make things better.
Integration with Design Thinking has presented blockages in our process as we wait for stories to begin prioritisation. Regardless of the above musings, it is vital to consider this the start of the road. This is a great opportunity to learn best practices of design to improve system workflow.
Collective ownership by clients, software developers and designers is vital to ensure the success of our latest endeavour. Continuing the conversation will ensure we address some of our challenges in defining our solutions together.
Thanks for reading!
Carly Richmond 