Lean: Purity vs. Pragmatism

“That’s not Agile and Lean!”

“We’re not being lean enough.”

“We’re not supposed to make deliverables!”

Sound familiar?

I hear these statements all the time from teams moving towards a more evidence-based approach to product discovery, conception, and production. Somewhere, someone made a decision for the teams to now “do Agile & Lean” and so, books were bought, conferences attended and index cards purchased. The teams set off with a healthy mix of trepidation and optimism and began practicing the newly learned processes – visions of stand-ups, post-it notes, IPM’s and validated learning in their heads.

Except it’s never that clean.

Something gets in the way. Something gets in the way – reality. Reality consists of:

• The client (or stakeholder) who doesn’t really understand what being agile actually means demanding roadmaps, and sitemaps, and journey maps and story maps.
• The project budget, which is allocated not just for discovery but also for actual production of a software application.
• Distributed teams who struggle to maintain transparency and real-time conversation.
• Experiment results that don’t give a clear indication of next steps.
• Technological constraints that won’t allow production-level scaling of the optimal solution.
• A corporate culture that frowns on failure and makes collaboration difficult

And so much more…

What is the newly minted Agile/Lean team to do when faced with these harsh realities?

Do you push through, sticking only to the fundamentals in the books and tutorials hoping things will work out? Or do you take the pragmatic approach and adjust as needed to accommodate the realities on the ground?

The answer, of course, is the pragmatic route. Each project, team, product, company, industry and market brings with it its own context. These contexts demand a unique approach that can’t be predicted in a book or manifesto. The frameworks articulated in those books are starting points. Once they get wrapped in these contexts they will inevitably morph.

And that’s OK.

Ultimately, what you really need is to ship product. Lean and Agile will help you gather evidence, determine more successful paths, produce working software faster and build a shared understanding between your teammates, clients and stakeholders. Start with these philosophies. Use them to build evidence, insight, direction, learning and value. But keep this in mind – there is no scale for agility or lean-ness. There is no such thing as not being “lean enough” or “agile enough.”

This blog article is reprinted with permission by Lean UX author, Jeff Gothelf.

Jeff Gothelf is an agile product designer, teacher, writer and team leader. He is one of the leading voices on the topic of Agile UX and Lean UX. In addition, Jeff is the author of the O’Reilly book (2013), Lean UX: Applying lean principles to improve the user experience. He is a highly sought-after international keynote speaker, workshop leader and trainer. Currently, Jeff is a Principal at Neo Innovation in New York City.