Purity vs. Pragmatism

 

religion“That’s not Agile!”

 

“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 – 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.”

 

 

 

 

About Jeff Gothelf

Jeff Gothelf is a lean thinking and design evangelist, spreading the gospel of great team collaboration, product innovation and evidence-based decision making. Jeff is an author, speaker and thought leader on the future of product development and design, often teaching workshops or giving talks on building cultures that support teamwork and innovation. Jeff co-founded Neo Innovation, a lean/agile product firm in NYC. Prior to that, he led the UX design teams at TheLadders and Web Trends. Earlier he worked with and led small teams of software designers at AOL. He is the co-author (with Josh Seiden) of Lean UX: Applying Lean Principles to Improve User Experience and the upcoming (Harvard, 2016) Sense and Respond (sensingbook.com).
This entry was posted in agile, design, enterprise, lean startup, Lean UX, Research, startups, work ethic. Bookmark the permalink.