Modern Agile meets Design Thinking

This is a guest post by Sigrun Tallungs (@tallungs). The original was written in Swedish and published on this blog earlier. That post, in turn, was a response to my post on Modern Agile.

What I like about Modern Agile is that it shines a light on what really hurts today, beyond the traditional focus on pumping out software features. Modern Agile aims to understand how we create value. Here’s how: Someone has to love what we create (”Make people awesome”). And for us to succeed we need to feel safe and reduce the risks involved (”Make safety a prerequisite”). Since we cannot figure out in advance what people really need, the way to go is to carry out a great number of experiments. That’s is basically all Modern Agile is – but that’s a lot!

Since its birth, the agile movement has engaged software developers but relatively few others. To face the challenges of today we need to involve all parties in the business surrounding the service or service eco-system we are developing. It is the co-operation of all these people that needs to be agile.

Unfortunately, the Agile Manifesto doesn’t really speak to people outside software. It was and is still an amazing story. A call to action that gave birth to a movement that changed the whole software industry. But as a platform for today it needs to be extended. Modern Agile is a good initiative that has gained recognition over the last year.

In his blog post My Take on Modern Agile, Joakim Manding Holm challenges the two vertically positioned sections of the Modern Agile model, i.e. ”Make people awesome” and ”Make safety a prerequisite”. The sections I want to discuss are the other two: ”Experiment and learn rapidly” and ”Deliver value continuously”. I view them as two sides of the same. The one goes with the other. When launching a service two things happen: 1. you get value, and 2. you learn a lot. Or you fail – and surely there’s valuable learning in that too.

What I feel is missing is an important element from Design Thinking movement: Empathy. This principle means going out into the real world to gain understanding of the problem space before narrowing on a solution. Walking in the users’ shoes. It’s about continuous learning that fuels the array of experiments we want to make so that we can view the services we create in use and learn from what we see.

Or the same thought put in other wording: Discovery and Delivery.  ”Discovery” (to study a problem space) and ”Delivery” (to make a change). Together these make up a continuous organisational learning circle, well-known amongst those who are studying how organisations evolve effectively.


In my opinion Design Thinking offers some of the most important ideas to adopt in modern development work. Before and during every initiative. It’s a way to find both the opportunities and the problems that we need to address. Make sure you have these skills in reach for every development initiative because every kind of development initiative can gain from the Design Thinking perspective.

So, in my version of Modern Agile, I would let the insights of Design Thinking complete the circle in some way. I believe the discovery/empathise part is too weak in Modern Agile as it is now. We could adopt into the agile movement what we have learned in other fields today.

To conclude, I think Modern Agile is a very interesting approach and hope it is a start on something that will grow and mature to an expanding community. Maybe in the future, the agile movement can join the user experience movement and others and learn how we can make users awesome in a safe way, via empathy and experiments. In my eyes, this would indeed be a good future.

I’d love to hear your thoughts on this. Do you also like Modern Agile? Do you think the empathise/discover parts should be strengthened?

6 thoughts on “Modern Agile meets Design Thinking

  1. Hey! Love what this post is getting at.

    We implement agile, but until a couple of months ago, our design process had never really gotten any love. Now, we spend time to group and prioritize larger pieces of work as Epics, and we’ve formalized what is required before we start breaking Epics into stories and official design UIs. This usually involves interviews, problem definitions, goals, success metrics, concepts, workflows and sketches. We’re hoping this more formulated process with our product team will be adapted by our market and operations groups. What does the design process look like for your company?

    • I think you are very right in not diving just into a solution and instead stepping up a level, trying to describe WHY and WHO.

      Development often has a starting point in a solution to be built that, assuming that the solution will solve a certain problem or fill a need.

      As a “design thinker” (it´s not a role, it´s a way of thinking and doing) you take a step back and move the starting point a bit earlier. Start without perceived assumptions about problems and opportunities. Very often you find that you have to adjust the preconditions. The problem was different and there were other opportunities. Lucky to find early! So, always mind the starting point and go see with the eyes of a design thinker.

      Visualizing and describing insights is an important part. To share, discuss and remember. I think epics, as you say, is one good way. They describe the “why” in the form of a story about the users needs, and stories creates empathy. I also like other forms of storytelling, beyond artificial personas. Also, it´s a good idea to describe a customer journey, with pain points etc.

      I like that you work with metrics. Metrics are good for learning (but are often misused to prove how successful you are and has therefore bad reputation of unreliability). When shipping a product, it is necessary to understand if works in a way you like (both business and users), or if you should redo something, iterate, change direction. Without putting effort in these observations, you will only end up doing increments in a direction that could be wrong.

      Design is by its nature an iterative process and the capacity to iterate is heart in both agile and design thinking. But it´s not very easy to measure in a reliable way that you can take actions from. To be more sure you mix quantitative metrics (data) and qualitative (observing asking“How did this help you to achieve your goals?”). UX-people are usually good at it and should be there to do this job.

      As a design thinker, you don´t believe in big deliveries, not even for your own insight work. Real world problems are wicked, so you cannot find the right solution only by thinking and even by prototyping, you have also to learn by observing in real use. To get more insights that feed next iteration. That’s way capacity for rapid delivery is so important.

      I don’t know if some of this was helpful to you? I don´t know your role, but aparently agile design thinker 😉 The process is never ready, just continue improving it like I understand that you already do, it´s also part of the discovery travel. I wish you great luck with your process and product!

  2. Thanks for all the great feedback! I love getting the perspective of other people in the field. I’m one of a few product managers who report up to a chief product owner, so lots of applicable insight. Thanks again.

  3. I see that if you’re delivering constant small experimental, incremental improvements, you need to be quite sure your stakeholders are with you every step of the way.

    • Good point. Rapid iterations are very important. It´s how you learn about user’s real behavior and real effects. It´s heart of modern development and heart of design. But it´s doesn´t solve all problems.

      A typical problem is that we tend to start building the proposed solution without actually knowing that it is the right solution. Too often it isn´t. It´s rather easy find out if you make some research, observe people in real world to find out about problems and opportunities. It usually gives a new understanding of which solution to build, and it´s a lot cheaper than shipping the first iteration of a product that nobody really needs.

      Design Thinkers are just people that ask why and who, seeking for proof in real people in real world. Stakeholdes usually can´t answer because they don´t know – and they are not always aware of this way of working. But usually vey satisfied after being shown this way – it saves money and gives better results.

      I hope I did I understand you comment right by the way ;-). Please tell me if I didn´t.

Comments are closed.