Jeff Gothelf’s new book, Lean vs. Agile vs. Design Thinking
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.