Most teams I meet these days are not new to Agile.

But few have seen It really work. The challenge, therefore, is not learning Agile. The challenge is unlearning how Agile was implemented in various work environments over the years.

Dave, my 41 year old software developer friend with two decades of experience (ten of those years doing “Agile” at three jobs, and one year of consulting), described his experience as follows:

It always made intuitive sense. Release often. Learn quickly. Care about quality. Cross-functional teams, and self-organization. But what we did never seemed to match what I imagined it to be. I feel like we only scratched the surface. Over the years I’ve become skeptical.So what had left Dave skeptical? Why had Agile failed to deliver on its promise? According to Dave….

We felt poked, prodded, micro-managed, and our every move measured. There was constant pressure to go faster, and it was hard to be proud of our work. Product basically treated us like order-takers. All the old habits and toxic stuff remained, but just in a new form, with new names. Time sheets and guessing? …Story points! Project Managers? …Scrum Masters and the PO! Deadlines? …Sprint commitments. Status checks? …Standup. I’ve been dealing with this shit for years John. The process asked so much of me, but did not give much in return.Dave is a smart person. He’s able to differentiate between the design of a framework, and the intent/context of his various jobs and teams. But he’s not an Agile historian (a perspective that many of my Agile historians friends have a tough time relating to).

When I explained that story-points are optional (for example), he was surprised. When I shared some personal experiences working on Agile teams — eliminating sprints, more experiment focused, less of a project factory, sharing the Scrum Master role, more attention to benefits/outcomes, fewer handoffs, a product manager who provided context and got out of the way, etc. — he seemed to genuinely light up. “See, that’s the kind of stuff I thought was possible!”

The kicker, for me, was when Dave went on to describe a bevy of advanced technical practices his team was using. “Oh but that’s not really Agile, is it? This is more like some of that XP stuff, and the other things are more DevOps inspired.” Doh! I wish Ron Jeffries or Kent Beck had been there.

Turns out the rest of the world doesn’t mind-map frameworks and methodologies for fun, read “the history”, and think about this all day, every day! Note to self.

Here’s what I am getting at.

I get into lots of debates on Twitter about prescriptive vs. “open” interpretations of Agile. But I realized recently that my personal challenge, albeit biased, is to help teams unlearn a history of crappy experiences with Agile (and heaps of skepticism). That is my 80% …not “transitioning” teams to Agile from waterfall. “Fresh” teams lack the experience, but they also don’t have the baggage. The money is in moving the needle for big later adopters. That’s not my world.

Coaches will be quick to say “but what Dave experienced is not real Agile!” And they are right…kind of. But from the perspective of the user (Dave), can you truly decouple the experience of the thing, from the thing? Can you blame Dave for being skeptical? He understands that Agile isn’t to blame, but still has a bad taste in his mouth. Is “real Agile” even a thing? Isn’t real Agile our experience with Agile? We can’t always blame the org and user.

This seems insanely obvious, but it seems like we don’t differentiate between these two problems (newcomers vs. unlearning). And in 2017, I’m guessing that I’m not as biased as I think I might be. Meanwhile Agile is a moving target. Agile exists in the current practices, teams, conferences, books, organizations, Meetup, YouTube videos, etc. As the first line of the Agile Manifesto goes:

We are uncovering better ways of developing software by doing it and helping others do it.Which is what I’d like to end with. How do we approach the problem of unlearning “Agile” and helping folks adopt a more helpful version of Agile? Do we need “training wheels”? How do we prevent the organization from simply grafting the “old way” on the “new way”? Do two-day certifications help? Because the challenge IS different.