Jeff Gothelf - Lean vs. Agile vs. Design Thinking: What You Really Need to Know to Build High-Performing Digital Product Teams

P rinciples for the Next Century of Work

Sense & Respond Press publishes short, beautiful, actionable books on topics related to innovation, digital transformation, product management, and design. Our readers are smart, busy, practical innovators. Our authors are experts working in the fields they write about .

The goal of every book in our series is to solve a real-world problem for our readers. Whether that be understanding a complex and emerging topic, or something as concrete (and difficult) as hiring innovation leaders, our books help working professionals get better at their jobs, quickly .

Jeff Gothelf & Josh Seiden

Series co-editors Jeff Gothelf and Josh Seiden wrote Lean UX (OReilly) and Sense & Respond (Harvard Business Review Press) together. They were co-founding principals of Neo Innovation (sold to Pivotal Labs) in New York City and helped build it into one of the most recognized brands in modern product strategy, development, and design. In 2017 they were short-listed for the Thinkers50 award for their contributions to innovation leadership. Learn more about Jeff and Josh at www.jeffgothelf.com and www.joshseiden.com .

C opyright 2017 by Jeff Gothelf

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher .

Issued in print and electronic formats .

ISBN 978-0999476918 ( paperback ).

ISBN 978-0999476901 ( epub ).

Editor: Victoria Olsen

Designer: Mimi O Chun

Interior typesetting: Jennifer Blais

Author photograph: Dailon Weiss

Published in the United States by Sense & Respond Press

senseandrespondpress.com

Printed and bound in the United States .

1234201918

Created with Vellum

J eff Gothelf

Lean vs. Agile vs. Design Thinking

What you really need to know to build high-performing digital product teams

T heres an unforgettable scene in my favorite movie, Goodfellas, where Joe Pesci, Robert DeNiro and Ray Liotta, after an eventful evening, pay a late-night visit to Pescis mom. The purpose of the visit was simply to pick up a knife to help them get the hoof of a deer they struck off the bumper of their car (or so they say). Despite their best efforts to get the knife and leave quickly, she convinces them to stay for a bit and have something to eat .

During the late-night meal, conversation turns to a unique painting they spot in her kitchen. Its of a bearded, white-haired man in a boat with two dogs .

They pass the painting around remarking on its uniqueness and the seemingly odd scene it depicts. When the painting gets to Pesci, he utters one of the most memorable lines of the movie, One dogs going one way. One dogs going the other way. And this guys saying, Hey, what do you want from me ?

The men explode into laughter remarking how the guy in the picture reminded them of somebody they ran into earlier that evening (and who currently occupied the trunk of Liottas car ).

I experienced a similar, albeit less Goodfellas, moment with a client of mine in 2016. We were preparing 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, they 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 targeting different measures of success .

The engineering teams were focused on shipping bug-free code in regular release cycles (many teams call these sprints, though the term release train has grown in use with the rising popularity of SAFethe Scaled Agile Framework). Product managers were most interested in driving efficiency, quality, and reduction of waste through tactical backlog prioritization and grooming techniques. The rationale behind these practices emerged from Lean thinking but, in practice, had nothing to do it. 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 were perceived as lengthy, up-front research and design exercises that delayed product launch. 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 a clear understanding of the problem, product managers optimized backlogs of work based on gut instinct and subjective preference from stakeholders. Without a clear understanding of the customer, engineers focused on simply shipping featuresthe more, the betterwithout 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, designers came up with ideas that never stood a chance of seeing the light of day .

How did this come to be ?

Unfortunately, this was not the first time Id come across this situation. Agile, conceived originally to bring a more responsive, evidence-based, customer-centric way of working to software engineering, has been productized in recent years. This productization has changed the intended goal of the Agile work philosophy. Instead of focusing on the responsiveness of the soft-ware engineering teams,i.e., how quickly a team could react in the face of uncertain market conditions, software complexity, evolving customer behavior, et al., Agile is being hired today to drive velocity. The only goal that matters to most Agile software teams is the efficient delivery of high quality code. Coaches, trainers, workshops, books, webinars, and blogs extol the efficiency virtues of Agile, promising greater predictability, throughput, and productivity by limiting customer feedback to the stakeholder, not the end user, while relegating design to nothing more than a final coat of aesthetics .