How to combine Design Thinking and Agile in practice

“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
Agile Manifesto

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?

Journey mapping

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.

  1. 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.
  2. 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.

Next is Storyboarding in which we have teams create short comic-strip style drawing of how they imagine the user’s experience once the big ideas is implemented. We do this individually and then come together as a group to see what each person has come up with. This activity helps align the team by having each member explain what the big idea means to them. If the team has broadly the same understanding of the big idea then the stories will look roughly similar, but the specific way each member envisions it, or even just the language they use, will help find subtle variations. Imagine the different user stories you could write about Facebook’s photo upload feature for example. Vacation snaps, missing pets, world news events. It’s all pictures, but the narratives and the value is subtly different, and may result in a very different product.

Once storyboarding is complete we have teams write Hills. Hills are an artifact which IBM contributes to the Design Thinking framework to help it scale to larger projects. They are best thought of as a the “commanders intent”, it’s a military metaphor to how a commander in the field doesn’t tell the team exactly what to do, but he expresses his key objectives which need to be achieved. Hills are the same, they are the key objectives for the release.

To keep them memorable and focused we have teams create three hills for a project release, written in the form of a statement of user value with a who a what and a wow element. Think of it like diagramming a sentence. To generate Hills I usually have teams do a silent post-it activity where members post up different examples of the who, what and wow which might best represent the big idea and value the team have identified through the earlier exercises. Once the team have a rough Hill worked out, they iterate to come up with a phrasing which is as clear, concise, memorable and above all empathetic as possible.

As an example, one team this week wanted their user in a manufacturing office to be able to gather specific information on part inventories in a much shorter time than it currently takes — down to just a few minutes.

Their first draft for a hill for one of their personas named Claire was:

Hill first draft. It contains all the elements, but could be more measurable and more empathetic.

This isn’t a bad start for a Hill, it is concise, reasonably memorable, and has the key Who, What and Wow elements. Nonetheless we talked a little about what exactly it was that made “minutes” the key metric. For a start, could we come up with something more measurable — not just minutes but 5 minutes. A more measurable success metric is always good because it helps set a constraint which can focus our design.

Okay, 5 minutes is a better metric, but why 5 minutes, why not 6, why is that amount of time really important to Claire? As we discussed it the team explained that the user they interviewed had a status meeting with their manager first thing in the morning, and wanted to be able to have this information available for the meeting. Time to gather that information was time she would have to arrive early in the morning. If it took 30 minutes she would have to be in work 30 minutes early to collect the information. This is a really valuable insight because it is much more empathetic to the user. What’s the difference between 5 minutes and 30 minutes? Not a lot, until you think of it as 25 minutes Claire could spend in bed in the morning, or 25 minutes more she could spend getting her children organised for school. The goal is the same, but we’ve arrived at a much more human understanding of it. So I encourage teams, and encourage you, to find the humanity in your hill statements. Your first drafts don’t need to be perfect, but I do encourage you throughout the project to search for ways to make your hills more and more respectful of your user’s humanity.

We wrapped up day 1 there. It was a tremendously dense day, but one which had taken our teams through a wide variety of Design Thinking activities and applied them to real project work. Day 2 would be about starting to apply some of the Agile toolkit to take our new understanding of our project, and start to think about how we can deliver it.

Day 2, Emphasizing Agile

Day 2 was a shift to agile, but I think without the labels you’d be hard pressed to see any real change in approach, the two blend together quite smoothly.

Day 2 began with taking our Hills and using them to create an Journey Map. This Journey Map looks very similar to the Journey Map from day 1, but this time it’s a future statement. How we want the users experience to look once our product or service is available. This means breaking down the tasks we want users to be able to achieve across a board (using post-its as always).

Brief Aside If we were not at a workshop with significant time constraints I would always advise teams to take a good amount of time here. At the point where you have written Hills it is a perfect time to go out to your broader team and build alignment around where the project is. Hills are great artifacts to take to stakeholders — both internal ones like executives as well as something you can put directly in front of target users to validate where you ended up. Ensure any assumptions are validated, talk to additional users to pitch your project and see if they would like to work with you more closely. Consider doing some Paper Prototyping to user test your basic approach. Don’t build more than necessary to test your ideas, and that includes don’t even go into Sprint 1 if you could have tested your idea whilst it is still just a drawing.
It’s also a good opportunity to do a wider exploration. Don’t take your Hills and build the first solution you can think of. There may be multiple different ways you could deliver the value described in the hill. Some might be better solutions, some might be cheaper. We could help Claire spend more time in bed if she had a dashboard to pull up the data for her meeting in just a few minutes. Or perhaps we could automate sending an email to Claire’s manager so that the meeting itself isn’t necessary. Sometimes it’s better to remove the problem than it is to solve it. So take some time here to brainstorm other ideas and find the design which works best. In the context of our workshop though, lets assume that this part has happened and move on to the next activity.

Taking the user-centric Journey Map the team has created we draw a literal line under it and switch to identifying the work we as a product team would need to implement to deliver that experience. What we call an Experience Roadmap. What product features would we need to design and implement? Catalog that work in terms of User Stories (the kind you would put in JIRA, or your project planning tool). The typical form of “As a <type of user>, I want <some goal> so that <some reason>”. Very similar to the Hills, but now we’re at the level of individual features to implement, so we probably have 20 to 30 user stories at this level.

The next step is to Prioritize them. The activity we used was to ask the teams to consider delivering their experience over a series of three releases, what we called a “Cupcake, Birthday Cake and Wedding Cake”. The analogy is to represent that the first release won’t contain everything, but it should be a satisfying piece of value on its own, at least for that group of people who only want “some kind of cake” and don’t actively need a wedding cake day 1.

Which User Stories need to be implemented first release, and which could we defer to later releases? This lets us roughly prioritize our work. The next step is to focus on the first release and prioritize our features into a Product Backlog. What is the highest impact user story, what is the second highest? We create an ordered list.

Once we have a Product Backlog, we had the team conduct a final exercise to size each story. Planning Poker is the activity we used to do this. Planning Poker has the team roughly size each story based on how much work they think it is using a series of numbered cards. Teams make hidden estimations of work, and then discuss and disagreements until a consensus is arrived at. Because we have cross functional teams, we’re estimating not just the code or test required to implement, but also the design, copy writing, photography, documentation, globalization and all other aspects needed to say a user story is “done”.

Planning Poker is a great approach because it sizes stories relative to each other, and doesn’t get into the political nightmare of deciding exactly how many man hours a story is. It helps focus the conversation on the work required, not the pressure to execute that work in a particular timeframe.

The end of day 2

At this point we have a prioritized backlog of work to do in order to execute the project vision we have come to. Using a specific set of activities we’ve gone from only a rough concept for what our project is, based on some initial user research, to a really specific set of prioritized work items on a product backlog which can be directly traced to user value. We’ve done 90% of the project work necessary to get us to start executing in small sprints. All that remains is to have the team take stories off the top of the prioritization backlog, design and implement them referencing the Hills, Research and Journey Mapping we have done, and release them to users.

As they do so teams should continue to validate their work doing user testing, A/B testing, gathering feedback and further refining the prioritization of the backlog. So we’re by no means done, but we’ve got to a point where we can get into a cadence of delivery, and use regular Retrospectives to track our progress and find ways to continually improve. Certainly my experience has been that in large organisations who are still learning how to apply Design Thinking and Agile, getting to this point is the hardest part for a project.

As I mentioned at the start, both Agile and Design Thinking emphasize people over process, and so if you are struggling with some element of the activities outlined I would encourage you to take a step back and do whatever you think is most useful for your team. There are far more activities within the Design Thinking and Agile frameworks than just those used here, but I wanted to provide at least one case study example of how that buffet of activities could be applied to help a team combine Agile and Design Thinking practices to get to good project execution.

Show your support

Clapping shows how much you appreciated Tom Roach’s story.