How to combine Design Thinking and Agile in practice
Author: Tom Roach
“Innovation is no longer just about new technology per se. It is about new models of organisation. Design is no longer just about form anymore but is a method of thinking that can let you to see around corners. And the high tech breakthroughs that do count today are not about speed and performance but about collaboration, conversation and co-creation.”
Bruce Nussbaum
Many of the people and companies I talk to about Design are grappling with applying design at scale. They want to hire designers like crazy, and they are open to change, or as open as you can be before culture change really takes place. What’s holding most of them up is lack of familiarity with how to apply theory to practice.
The other thing that is holding them up is a lack of clarity about what practices to apply.
I know about Design Thinking, but we are struggling to actually apply it in practice
My Development team is trying to be agile, but we are not really there
In other words: How do you work out which frameworks, organisational models and activities will get you from the products and services of today to those of tomorrow?
Trying to reconcile all the different options feels like trying to reconcile Gravity with Quantum Mechanics.
We have good independent theories, but we are trying to figure out a mix that works for the whole of a project, not just some part of the process, or part of the team. We’ve got compelling theories for different pieces, but figuring out how to combine them together is really hard!
I spent this week in Raleigh, NC facilitating a workshop for IBM bringing together IBM’s take on Design Thinking and Agile. We took teams through both approaches over two days to show how you could seamlessly blend the two for a creative, empathetic and implementable approach. So for this article I thought I would share a lot of what we recommended there. I’ve bolded certain words throughout when I’m referring to a specific activity we had the team do. For most you can find a lot of information online about how to conduct them.
Design Thinking at Scale
The video above gives a basic cross section of Design Thinking as IBM practices it, but obviously there is much more detail when you start to apply it to real people. What makes for a good value statement? How do I help a team of 6 people brainstorm options? How do we validate our best ideas with a potential user? There is a lot of material out there, and a whole buffet of potential activities to apply. Search for Journey Maps, Empathy Maps, Ideation, Personas, Paper Prototyping to see just a few.
Agile
Agile has been around for almost 15 years and has its own philosophy and practices. Agile is intended to emphasize maximising value creation by de-emphasizing up front specification and process in favour of front loading value.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Like Design Thinking, Agile emphasizes collaboration and individuals, but it has its own language and methodologies. The core manifesto outlines some key principles, and then teams typically use methodologies like Scrum, Sprints, Retrospectives to execute. The two don’t exactly conflict, but they don’t mesh seamlessly either. Agile is usually contrasted with waterfall and so teams using Agile often feel a great deal of restlessness to “just start coding”. Teams trying to mix Agile and Design Thinking often run into some tension about how much time to spend on the Design Thinking part, and when it’s time to start coding. In the worse case, where different parts of the team are following different frameworks, there can be serious conflict. There doesn’t have to be though, and so we wanted to show in the workshop a selection of practices from each which are complimentary.
Aside Both Design Thinking and Agile emphasize people over processes, and so I would always recommend only following the activities here to the extent that they work for you and your team. I want to provide a really specific example of how the practices can be applied, but I don’t want teams to think that this is the only way to do it. I would always encourage teams to deviate in an instant if they think another activity or practice would be more helpful at a particular moment.
Day 1, Workshop Agenda & Design Thinking
Just a bit of context — The workshop I facilitated had 8 teams attending with a cross functional group of about 12 people in each group including Design, Development and Product Management (what we call “3 in a box”). Some groups also had Sales and Marketing (what we call “5 in a box”) to round out some other perspectives. These teams had mostly new projects, although in some cases they were existing projects beginning a new cycle making it an appropriate time for them to revisit their practices. The workshop itself was 2 days giving just enough time for a taster of some different elements of IBM’s Design Thinking and Agile practices. If the activities described by the two frameworks are a buffet, the team had a chance to try a little spoonful from some of the menu items.
Because Design Thinking is fundamentally about user empathy we asked each group to arrive with some basic information about their existing or target user demographics.
Very specifically, we asked them to interview at least one user for an hour about their background, job role, responsibilities, workflow and challenges. Once the interview was completed, we asked the group to complete an Empathy Map in response to the interview. This helps the group synthesize all the information they gathered into key insights.
We also asked the group to catalog their core stakeholders, both within IBM (Executives for example) as well as in their user’s organisation (other job roles who interact with the product for example). This catalog was essentially a grouping of Proto-Personas. That is, not backed by research, but nonetheless a good initial way to align on who the players are and what future research may be needed.
With this pre-workshop homework in hand, we began the by asking the groups to do a small presentation on the material, and then create what we call a Project Rundown. On a sheet of paper we have the team place post-its on the topic of 1) their project name, 2) who their primary user is, 3) an analogy for the project appropriate for an 11 year old, 4) the problem today, 5) what the users ideal experience would be, and 6) how the project will benefit our business. This is primarily to help the other teams at the workshop understand what each other are working on, but it also helps the team get used to post-it exercises they will be doing throughout.
Once the Project Rundown is complete we moved on to a Journey Map exercise. Journey maps are a great way to capture what the team currently understand about their user’s existing experience, what we call the “as is” experience. Journey maps come in all shapes and sizes, and typically the ones which you will find online are more polished than necessary. Quite simply we ask the group to take a large wall space, and divide it into 3 horizontal sections labelled “Does”, “Thinks”, “Feels”. Then have the groups place post-its on the wall which break down all or part of their users experience with the product. If the team already have a product in the market, this is the user’s experience with it. If the team don’t yet have a product, if it’s a new project, then this is the experience their target demographic has today doing a roughly equivalent task. What actions does the user take throughout the user experience, and how do they think and feel at each step?
By “experience” I mean the full cross section. What IBM calls the “six experiences”. These include:
- Discover, Try and Buy How do people find, understand and acquire the product? That may mean buy from a shop, it may mean sign up online.
- Getting Started What is the first use experience for the product? That includes first set it up, or learning how to use it.
- Productive Use The day to day use of the product from day 2 to day 100. Including both occasional use and power users.
- Manage and Upgrade What do users need to do to keep the product or service going smoothly, and make changes to their usage — add team members, change their subscription and so forth.
- Leverage and Extend How do users take the product as is, and combine it with other products or services or make customization to it? That might mean using APIs for example to develop extensions.
- Get Support If users run into problems either of their own making or due to product deficiencies, how do they get help?
So teams map their customers existing journey across all, or just part of, these different facets of the user experience. This does a couple of things.
- It lets teams build empathy for the people who are trying to carry out these tasks. It’s an opportunity to think about parts of the experience they might have considered “not my problem”. Part of creating cross-functional teams (5 in a box) is it expands the team’s remit to own the entire experience. Design Thinking, and UX design in general is about taking responsibility for the whole experience, seeing our products and services as the user sees them, not based on internal team or organisational silos. If you don’t believe you have the remit to fix the Get Support experience, then find the people who do and bring them into the team.
- It also lets teams start to identify pain points, or opportunities to change user behavior. Perhaps users waste time at a particular step, or feel intimidated. Perhaps they have a misconception which we could help correct. There is a wide variety of different types of issues we could identify, and by looking at the complete cross section, as well as the users thoughts and feelings in addition to their actions, we can find core issues to focus on.
Once teams have identified key pain points they want to target, we engage in a round of Ideation or brainstorming of potential solutions. What are the big ideas which we can think of to solve for that pain? Start with a round of silent idea generation with team members contributing ideas to a wall on post-its. Once a good amount of ideas have been generated, a round of Voting using stickers lets our cross-functional team identify ideas which they think would be most impactful, and which are the most feasible. The very feasible and very impactful ideas are the ones to take forward.
Read full article: medium.com/startup-study-group/how-to-combine-design-thinking-and-agile-in-practice
Recent Comments