Beyond Lean and Agile

I have been working exclusively with technology product teams now for a full 35 years, and I’ve seen countless processes, methodologies and techniques come and go.

In large part that’s the nature of the beast.  People are always searching for a silver bullet, and there is always a willing industry, ready and waiting to serve with books, coaching, training, and consulting.  But of course there is no silver bullet, and inevitably people figure this out, and then the backlash comes.  As I write this, it’s in vogue to criticize both Lean and Agile.

I have no doubt that many people and teams are in some measure disappointed with the results from their adoption of both Lean and Agile. And I believe I understand the reasons for this.  That said, I am convinced that both Lean Startup and Agile values and principles are actually here to stay.  Not so much the particular manifestations of these methods that many teams use today, but the core principles behind them.  I would argue that they both represent meaningful progress, and I for one would never want to go backwards on those two fronts.

But as I said, they are not silver bullets either, and as with any tool, you have to be smart about how you use it.  I meet countless teams that claim to be following Lean principles, yet they work for months on what they call an “MVP” and they really don’t know what they have, and whether it will sell, until they’ve spent substantial time and money; hardly in the spirit of Lean.  Or they go way overboard and think you have to test and validate everything, so they go nowhere fast.

And of course if you’ve read any of my articles, you hopefully know that the way Agile is actually practiced in most product companies is hardly Agile in any meaningful sense.

So in this article, I’d like to talk about what’s beyond Lean and Agile.  I believe that the best product teams have in fact already moved past how most teams practice these principles – leveraging the best of Lean and Agile, but raising the bar on what they’re trying to achieve and how they work.

When I see these teams, they may frame the issues a little different, and sometimes use different nomenclature, but at the heart I see three fundamental principles at work:

1. Risks are tackled up front, rather than at the end.  In modern teams, we tackle these risks prior to deciding to build anything.  These risks include value risk (whether people will buy it), usability risk (whether people can figure out how to use it), feasibility risk (whether our engineers can build what we need with the time, skills and technology we have), and business risk (whether this solution also works for the various aspects of our business).

2. Products are defined and designed collaboratively, rather than sequentially.  They have finally moved beyond the old model where a product manager defines requirements, a designer designs a solution that delivers on those requirements, and then engineering implements those requirements, with each person living with the constraints and decisions of the ones that preceded.  In strong teams, product, design and engineering work side-by-side, in a give and take, to come up with technology-powered solutions that our customers love, and that work for our business.

3. Finally, it’s all about solving problems, not implementing features.  Conventional product roadmaps are all about output.  Strong teams know it’s not only about implementing a solution; they must ensure that solution actually solves the underlying problem.  It’s about results.

The “dual track” model of continuous discovery work running in parallel with continuous delivery is predicated on these three principles.  Discovery is all about tackling the various risks before we write a line of production software.  Discovery is very much about the intense collaboration of product management, user experience design, and engineering.  And discovery is all about discovering solutions to the business problems we are assigned in our objectives (rather than implementing features on a roadmap).

You will also find the same three core principles behind design thinking and design sprints in parallel with delivery sprints, customer development running in parallel with product development, and the “build things that don’t scale” first mantra of Y Combinator.

So however you and your team care to visualize or describe how your work, what’s critically important is that you:

1. Tackle the big risks early – especially value risk and business risk

2. Figure out solutions collaboratively – engineering, design, and product, working side-by-side

3. Focus on solving problems – it’s not about features or a roadmap; it’s about delivering results

Keep these points in mind on your next effort and see if you can’t raise the bar on your results.