A Complementary Approach in Software Development: How to Combine Design Thinking, Lean Startup and Agile Methodologies for Outstanding Innovation
Nowadays’ business jargon has been steadily nourished with the introduction of several methodologies and philosophies that have gained remarkable renown throughout the past few years: Design Thinking, Lean Startup and Agile. More and more companies are waking up and starting to acknowledge the multitude of possibilities and benefits over business performance offered by the application of these methodologies throughout the innovation process.
Nevertheless, understanding each of these three methodologies and their potential implementation yet remains a struggle for many companies. As with anything in life, the more choices we have, the harder it becomes to make sense out of everything and smartly prioritize what works best at a specific moment and under explicit circumstances. Applied to a software development context, the broad portfolio of processes, methods and tools from Design Thinking, Lean Startup and Agile offers almost unlimited opportunities for combination and exploitation.
Even though at first glance they might be perceived as incompatible, by steadily applying those methodologies during the development of a wide range of projects, I came to truly believe that each of them contributes to the innovation process in its own way. Once teams are open to understanding and embracing those practices, their complementary value becomes evident.
So, what are the basic foundations behind each methodology, and how do they differ and resemble? How do they all fit together to achieve the desired outcome, and in which part of the innovation process do they have the biggest impact and provide the most substantial value? While there are no one-size-fits-all process or rules, in this post I will share the process I have mastered and followed in multiple projects.
Design Thinking
Origins
Although it is widely agreed that Tim Brown coined the term Design Thinking as we know it today, this way of problem-solving and thinking has existed and has been practiced since the 1960’s.
Purpose
Give answer to any complex problem within any aspect of life.
Approach
- User-centered: Putting the users’ needs and requirements in the spotlight as a central point to the process. The team steps into the users’ shoes, involving them throughout the entire innovation process by the application of methods such as interviews, observations in their natural context and of their product and service interactions, as well as co-creative techniques.
- Divergent and convergent thinking: Design Thinking encourages the use of divergent thinking for the generation of as many solutions as possible for giving answer to a specific problem, and then convergent thinking for narrowing them down to the final most optimal solution. Few or no limits must be given to breadth during divergent idea generation, so that to foster a creative and outside-the-box thinking for finding the solution to any wicked problem.
- It brings together and considers user desirability, financial viability, and technical feasibility as criteria for definition and development of solutions.
Stages
The most-widely spread version of any Design Thinking process is composed by the five stages of Empathize, Define, Ideate, Prototype and Validate. Although represented as a linear process, the essence of Design Thinking relies on a flexible and non-linear iteration, being the outcome and learnings of each stage a pivotal moment to go back to any of the prior stages.
- Empathize: Gain a deep understanding of the problem to be solved. The foundations of Design Thinking are on leaving aside any prior assumptions regarding the specific problem and user. This first stage involves an in-depth comprehension of the context of the problem, which can be achieved by, for example, observing and talking to your users. Focus on the What is?
- Define: Synthetize the set of insights gained during the previous stage, so that to identify and clearly phrase the problem to be solved with your solution in a human-centered way. Focus on the What should?
- Ideate: Generate as many creative solutions as possible for giving answer to that problem. Foster outside-the-box and crazy ideas through techniques such as Brainstorm. Focus on the What if?
- Prototype: Experimental stage to create several low-cost solutions to make the previous ideas tangible and to move forward onto the following validation stage. Focus on the What wows?
- Validate: Test the prototyped solutions with end-users to identify the best solution, and to further iteratively improve it based on user feedback. Focus on the What works?
Lean Startup
Origins
The term was first proposed by Eric Ries in 2008, as a translation of lean management principles to high-tech startup companies based on his own personal experience.
Purpose
Develop new businesses and products under conditions of extreme uncertainty and minimize waste.
Approach
- Iterative product releases: Following a feedback loop of turning ideas into products, measuring how customers respond and then learning whether to pivot or persevere.
- Validated learning and business-hypothesis-driven experimentation: “Startups exist not to make stuff, make money, or serve customers. They exist to learn how to build a sustainable business. This learning can be validated scientifically, by running experiments that allow us to test each element of our vision.” Eric Ries.
- Innovation accounting: Measuring progress, setting up milestones and prioritizing work.
Stages
The fundamental activity of a startup is to build ideas into products, measure how customers respond by collecting data (feedback), and then learn whether to pivot or persevere.
- Build: The first step is to start building the idea and turning it into a Minimum Viable Product (MVP). The MVP is not the cheapest or smallest version of your product but rather the simplest version and the one that lacks the highest amount of effort and development time. In other words, the fastest way to get your assumptions tested.
- Measure if the product development efforts are leading to real progress by collecting quantitative and qualitative data on your MVP.
- Learn from the data collected and decide whether to pivot or persevere with the original strategy. In this stage, you will see if the assumptions you departed from are false or true, and hence make a concordant decision.
Agile
Origins
This term was coined in early 2001 when 17 software development practitioners gathered in Snowbird, Utah, discussing their shared values, ideas and approaches to software development. The outcome of this was the Agile Manifesto and its corresponding 12 principles.
Purpose
Create and respond to change for succeeding in an uncertain and unstable environment.
Approach
Agile is represented through the following four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Stages
Agile is a group of software development methodologies, being SCRUM the most widely-used process framework for agile development. SCRUM is composed by the following standard phases:
- Product backlog creation (or revision): A product backlog (PB) is a list of features to be built in the product during the development process, presented in priority order. Every team will have their own PB and will use it as direction for deciding what needs to be built.
- Sprint planning and sprint backlog creation: The Product Owner (PO) presents the product backlog items (PBIs) with highest priority and discusses with the development team how many items they can commit to build during the sprint (which normally lasts 2 weeks).
- Working on the sprint (Daily SCRUM): The goal of these meetings is to daily track the progress and status of the project. During these meetings, every team member shares the tasks finished, the upcoming tasks, and which problems he or she has faced during the work.
- Sprint review: Every sprint ends in a product demonstration, where the SCRUM team reviews and demonstrates the results of their work. This can ultimately lead to changes in the product and to the PB.
- Sprint retrospective: The team discusses the results and learnings of this sprint, and determines how to improve the entire process during future interactions.
What are the main differences and similarities between the three methodologies?
Design Thinking is how we explore and solve problems; Lean is our framework for testing our beliefs and learning our way to the right outcomes; and Agile is how we adapt to changing conditions with software.
How to get the best out of each of the three methodologies?
The answer is not whether to use one or the other, but one and another. The real benefits come when we combine them and exploit the benefits they offer at each specific point of the innovation process:
Based on my own and my peers’ experiences, I summarized some good practices for applying Design Thinking, Lean Startup and Agile:
1. Clearly identify your purpose
That is the belief that steers everything that you do. All the decisions made and the actions taken in our team are driven by the mission we have in place, which represents the ultimate role we have and the contribution to the world we want to achieve through the development of our mobile app(s). Having this purpose on the spotlight will continuously guide you towards the right direction for the definition of new strategies and the development of new products and functionalities.
2. Build multidisciplinary teams
Work with people from varied disciplines, so that to achieve a wide array of knowledge and skills and that everyone brings their own expertise to the table. However, since people tend to have their own focus, make sure roles are assigned clearly and specify who is ultimately accountable for which decisions. Solution teams should be generally composed by at least one person belonging to the roles of User Experience, Product Marketing and Product Management, or alike. The latter also oversees the collaboration and integration with the development team. Furthermore, as every project is different and hence involves a diverse set of stakeholders, it is crucial that we involve the experience and skills of everyone that can have an impact on the project and hence make it a success (e.g. people from a different team or department not directly linked to your core team).
3. Adopt an open and hands-on approach
Build fast, learn even faster. All team members must embrace change, tangible results, and the philosophy that failing is a tactic for ultimate learning and innovation. Therefore, MVPs play such an important role, as the faster you test your assumptions (whether it is from your vision or your value proposition), the faster and the better your product will be built. For our latest mobile app, the team took a 2-week sprint to make the functionality available as basic as possible. Right after that, we started user validation while the development team kept concurrently working on improving the offering based on the collected user feedback.
Building a product is a lot like a combat mission. A team of skilled people operate in conditions of high uncertainty; a commander sets clear outcomes with some guiding principles; but we expect the unexpected; and, we’re trained to take best action, responding to new information as the situation unfolds.
4. Constantly involve your users
People tend to make the mistake of confusing assumptions with real facts. Do not take for granted that you know everything about your users and about what they need and do not leave all decisions depending solely on internal criteria. Your users are the experts of their own experience, being the ones making use of your products and the ones who will truly benefit or suffer with them. Therefore, base your decisions on feedback and contribution from your users. Involve them for understanding the context of their problems, but also for constantly validating that you are correctly moving through each of the stages. You can also use co-creative methods to design solutions together with your users.
5. Make decisions based on learning
Define the beliefs and assumptions you are building your product around, as well as the desired learnings and which experiments will ultimately deliver them. It is important that every time you start a new project, you recognize and specify which assumptions about the user, market and technology you have, so that to validate them and subsequently adapt and make the necessary changes for business success.
6. Iteratively revise your process
Nothing works for everyone and there are many factors affecting the specific performance of each project, such as the dynamics of the team, how many and which stakeholders are involved or the complexity and the width of the project. It is important that every time a team delivers a project and has gone through the complete process, all members reflect and conclude the main learnings of that experience. This way, it is possible to draw conclusions regarding possible influencers and what can be done better next time. This is given special importance with the Agile methodology through the Sprint Retrospective stage. However, this is focussed solely on the development part of the innovation process, in other words, the prototype stage. It is essential that the team evaluates each of the stages, in terms of performance and outcomes. There is no rule of thumb for when to best do this, but I believe a monthly or bi-weekly team review moment works best to assess the progress and performance and share individual opinions regarding each of the projects the team is simultaneously working on.
7. Understand a topic in-depth but do not get too lost in the details
Gather a wide array of insights and soak up into them so that to gain empathic understanding of the user problem(s). However, you also must learn when to stop the research phase. A tip here is to establish a deadline for when to finish gathering insights, as well as to make the decision to stop when you realize you are hearing and observing similar things from multiple users. You will always learn something new from each of the users but the key is to have a clear overview of all the insights you have collected from the research (i.e. user interviews or observations) and how those are helping you to understand better and to draw a clear map of the context of the project.
8. Adapt your research techniques to the situation
Plan beforehand which insights you are aiming for, to map out how to best gather those. You can use the following guidance for determining the most suitable technique for collecting user insights, based on the type of knowledge you want to achieve and depending on the action of the user:
Thanks for reading! Are you familiar with these methodologies? Do you have any experiences with implementing them in your own projects and work? I’d love to hear about them, so please share your comments and remarks below!
