At this point in its lifecycle, Agile is in the mass adoption phase. Whenever I’m in front of an audience or teaching a workshop and I ask, “How many of you work using Agile processes?” 100% of the hands in the room go up. The honest people in the room will still hold their hand up but will wave it from side to side indicating they’re doing something agile-ish.
(This post appeared first in my once-monthly newsletter. Sign up here and join 40k others.)
The majority of large companies employ at least a few agile coaches and scrum vocabulary is broadly adopted and commonplace. Everyone is “doing sprints”, “grooming backlogs” and holding “iteration planning meetings.” The next phase of increasing the agility of these organisations is to build in product discovery techniques. These techniques, including customer development, research, experimentation, objectives and key results (OKR), prototyping and hypothesis writing are also becoming part of the shared lexicon.
However, when it comes time to actually do the product discovery work, despite everyone being aware of the terminology and the work involved, many organisations come back with the classic rebuttal, “yes, we know we should do product discovery….but it won’t work here.” This argument reveals a cultural point of view where each of these companies believes they are a unique entity that can’t, won’t or doesn’t need to do product discovery. I set out to find out why these companies felt this way about these hugely valuable techniques. To do so, I turned to my research tool of choice — Twitter — and, wouldn’t you know it, I inadvertently started a fun, viral conversation that struck a nerve with many folks.
You can see the whole thread here.
My initial idea was to put together a “…but it won’t work here” Bingo-style board to help teams match excuses with rebuttals. The sheer scale of such a board became clear to me quickly and I had to abandon the idea of a board that covered every permutation of this argument. However, after a few attempts, I iterated my way to the chart you see below. It’s focused on 10 of these initial arguments. It is by no means complete and the rebuttals it offers are focused on a small subset of colleagues that may or not be relevant to your unique situation.
That said, it’s a starting point. It’s designed to help you start a conversation with one of the specified individuals in an effort to push back, respectfully, on the challenges to doing good, customer-centric agile software development and, in turn, making your colleague, team, company and customer more successful.
I’d also love to hear the arguments you get for why customer-centric, cross-functional agility won’t work in your organisation. Reply here and let me know.