HOW BLENDING LEAN, AGILE, AND DESIGN THINKING

WILL TRANSFORM YOUR TEAM

By Jeff Gothelf

The following is an adapted excerpt from Lean vs. Agile vs. Design
Thinking by designer, team leader, and business coach Jeff Gothelf.

In 2016, I was preparing with clients for an upcoming training workshop focused on coaching a cross-functional
team of designers, software engineers, product managers, and business stakeholders on integrating product
discovery practices into their delivery cadences. During our conversation, my client said to me, “Our tech teams
are learning Agile. Our product teams are learning Lean, and our design teams are learning Design Thinking.
Which one is right?”

The client found the different disciplines at odds because these seemingly complementary practices forced each
discipline into different cadences, with different practices and vocabularies targeting different measures of
success.

The engineering teams, using Agile, were focused on shipping bug-free code in regular release cycles (many
teams call these “sprints”). Their ultimate goal was an increased velocity — the quantity of code they could ship
in each sprint. Product managers, using Lean, were most interested in driving efficiency, quality, and reduction
of waste through tactical backlog prioritization and grooming techniques.

Not to be left out, the designers sought to bring the customer front and center by validating problem-solution fit
with Design Thinking activities. Yet their activities, like up-front research and design exercises, were perceived
as time-consuming, delaying the deployment of new code. Each discipline was working through its own
ceremonies and tactics, targeting an ideal state of success unique to them. The collaboration, shared
understanding, and increased productivity they were all promised was nowhere to be found.

“So what?” they asked. Each discipline should work in whatever way is best for them, right? No. Without
clearly understanding the problem the teams are trying to solve for the business or customer, a core concept
across Lean, Agile and Design Thinking, product managers optimized backlogs of work based on gut instinct
and subjective preference from stakeholders. Without a clear understanding of the customer, especially key in
Design Thinking, engineers focused on simply shipping features — the more, the better — without a sense of
whether they helped to solve a real customer need in an effective way. And without any sense of the feasibility
or strategic alignment of their prescribed solutions, an aspect of Agile, designers came up with ideas that never
stood a chance of seeing the light of day.

With such differing practices, motivations, and measures of success, is it any wonder organizations find it
difficult to reconcile these processes and create highly productive, creative, balanced teams?

In my book, Lean vs. Agile vs. Design Thinking, I delve into all three of these popular practices and outline
how they work, as there are valuable components of each. As an organization seeking to leverage the benefits of
continuous improvement and a digital product offering, your job is to pick and choose the specific elements
from each practice that work well for your teams and the brand values you’re trying to convey.

I’ve found that a few core practices serve as effective starting points for cross-functional teams to integrate
components of each discipline. You can learn more about these and other strategies in my book.

WORK IN SHORT CYCLES.

Assuming you know exactly how people will respond to change is the same as assuming you can predict the
end state of a piece of software — impossible.
Since you cannot predict how people will react to this change, making these assumptions is highly risky. To
reduce the risk of implementing sweeping process changes that fail, take small steps, a key component of Agile
and Lean. Pick a new idea or practice and try it with a subset of your teams. Present this new practice as a
“process experiment.” Let the team try it for a limited amount of time (e.g., two sprints) and see how it works. If
it fails, the team has invested very little time and effort in this change, but (hopefully) they’ve learned a lot. If it
succeeds, the team keeps the practice, improves on it, and the organization rolls it out to more teams.

HOLD REGULAR RETROSPECTIVES.

Retrospectives are the heart of continuous improvement. Used frequently in Agile, they are a regular
opportunity for the team to consider their current practice, evaluate its efficacy, and determine how to progress.
Initial retros are uncomfortable and often feel like nothing more than venting sessions. Even teams who hold
these sessions regularly often generate so much improvement material that it feels like very little is actually
getting better.

At the end of each sprint, encourage your teams to get together for an hour, review what worked well during
that cycle, what didn’t go well, and commit to improving one or two key things each time. Oftentimes this will
feel awkward at first but, after a few retrospectives, teams begin to open up more freely and address the core
issues hurting their collaboration. If this fails to occur, offer teams an outside facilitator for these meetings.
Someone without anything at stake in the retrospective will do a better job probing for root causes and
solutions.

DO LESS RESEARCH, MORE OFTEN.

User research has been around a long time. As a tool in the arsenal of design teams, it was traditionally wielded
with the subtlety of a giant hammer. Regardless of what was being tested (or what the team needed to learn), it
often required at least two days offsite, in a facility stocked with candy, a dozen test participants or more, and a
broad array of team members checking in and out as their calendars dictated. With a competent moderator and
reasonable testing script, almost every major issue was revealed within the first five test participants. Every
subsequent one yielded little additional value and cemented the perception in almost every attendee’s mind that
this was a colossal waste of time. The worst part? They were right. It was a waste of time.

Now, don’t get me wrong. I am a huge advocate for user research. However, having been the victim of many of
these sessions, I know how much waste is involved in each. In addition, I’ve witnessed firsthand how attendees,
who were convinced that this was an essential use of their time, lost faith in the process and the technique.

To avoid this, I recommend continuing to practice user research with a cross-functional team in attendance, but
simply do less of it, more often. Instead of testing 12 people, test three. Take the learning from that, and then do
the test again the next week. Don’t go offsite. Work in the office to ensure maximum participation. Most
important, broadcast your findings broadly immediately after the test. Show the value of the exercise, reduce the
commitment for participation, as well as the cost, and you’ll find an increased level of organizational buy-in for
this classic product discovery technique.

WORK (AND TRAIN) AS ONE BALANCED TEAM.

The client quote that precipitated the writing of this book highlighted the discipline-based divisions at the root
of that team’s dysfunction (and that of others). Part of the reason each discipline is training in a different
methodology is because, while their vocabulary may have shifted, the way they work hasn’t. They continue to
work in silos, handing off items from discipline to discipline. They are not working together on the same things
at the same time.

To combat this tendency, reconsider how you staff projects. The atomic unit of planning for any project is the
team. The team is made up of designers, software engineers, and product managers at the very least. There is no
“engineering team” or “design team” at the project level. These balanced teams provide the expertise,
perspectives, and skill sets necessary for all aspects of a project.
When structured this way, it doesn’t make sense to train different members of the team in different ways. There
is no difference in the cadence of engineering, design, nor product management on balanced teams. Their
efforts have to be coordinated, aligned, and targeted at the same learning and delivery goals. Balanced teams
choose the best parts of Lean, Agile, and Design Thinking and apply them as needed in a tight collaboration.

PRIORITIZE PRODUCT DISCOVERY AND DELIVERY WORK EQUALLY.

One symptom that seems to manifest consistently across organizations is that the work that gets visualized is the
work that gets done. Agile, particularly, has very clear directions, ceremonies, and rituals around visualizing
work. This is why, in most companies practicing some form of Agile, you’ll see physical boards or monitors
displaying the teams’ work in JIRA or other digital project management tools.

Agile advocates continuous learning. So does Lean Startup. Design Thinking focuses on learning as well. Yet,
there is no clear process or ritual linked to visualizing learning work. The delivery aspects of Agile get
visualized, measured, and executed. In this situation, Agile “wins” because the (valuable) activities of Lean
Startup and Design Thinking rarely find their way into the same tools as the Agile activities. The result of this is
that this work doesn’t get treated the same way as delivery work. It marginalizes the effort and allows it to be
cut in the event of a time or scope crunch. Team members, often asked to meticulously track their time and
effort on delivery tasks, are left to find time for discovery work “in the cracks” of their calendar.

To avoid this, product discovery work must become a first-class citizen of the backlog. It must be visualized
along with the delivery tasks. It must be prioritized against them and assigned to specific members of the team.
It must be tracked like delivery tasks, and the implications of the discovery work have to be taken seriously. In
many cases, learning will reveal gaps in your backlog or a poor prioritization decision. Changing your plans in
reaction to these learnings is agility. It’s the whole reason to adopt this way of working and is the key to
building responsive teams and organizations.

REVIEW YOUR INCENTIVE STRUCTURE (AND PERFORMANCE MANAGEMENT CRITERIA).

This is perhaps the most important criteria for ensuring your teams choose the most productive amalgamation of
these philosophies to work with. Teams will optimize the work they’re incentivized to achieve. If you
incentivize velocity, teams will work on getting more features out to market. If you incentivize learning, teams
will build better product discovery processes.

These same incentives must be reflected in your company’s performance management criteria. If you want to
build collaboration and learning, employees must be assessed on the efficacy of their collaboration and their
ability to build continuous learning into their work. For example, velocity is only rewarded if user satisfaction
reflects value in the features shipped. Incentives like these force the kind of self-organization Agile teams are
famous for. Knowing that their company values these behaviors motivates teams to figure out which pieces of
Agile, Lean, or Design Thinking will best help them achieve that.

Dive into Lean, Agile, Design Thinking, and more in General Assembly’s leading-edge workshops and courses.
In our coding, design, and product management programs, you’ll learn strategies to improve workflow and
collaboration between developers, designers, and product managers. For employers seeking to build and
transform teams, GA offers assessment, training, and talent development solutions for organizations of all sizes
across the globe.

ABOUT JEFF GOTHELF Jeff Gothelf is an author, speaker, and executive coach. He co-founded Neo
Innovation in New York City and helped build it into one of the most recognized brands in modern product
strategy, development, and design. He is the co-author of Sense and Respond (HBR Press), Lean UX (O'Reilly),
and Lean vs. Agile vs. Design Thinking (S&R Press). Recently, Jeff co-founded Sense & Respond Press, a
publishing house for modern, transformational business books. You can find him on Twitter at @jboogie.