When I lead public workshops, I ask people what their experience with with agile is. In the past, if I asked people if they were experienced with agile, their answers were reliable. Now, not so much.
People think if they can spell agile, they are agile. If they sometimes use timeboxes, they are agile. If they stage integration, they think they are agile. If they assign tasks to specialists, they are agile. If they work in 4-week timeboxes on epics, because they break their stories into tasks, they are agile. If they perform retrospectives, even if they never change or learn from their retrospectives, they are agile.
I could go on, but I’ll save us, because we all have better things to do today.
The word agile has clearly crossed the chasm. And, with all the emphasis on certification, that word is only going to become more resume-valuable with time. And that’s a damn shame.
Because true agility, the kind where you do some work, and get some feedback, first from your team and then from your customer—that’s so valuable that it’s hard to believe organizations are not embracing it. But the problem is they don’t really know what agile is. All they know is the word.
So, what am I doing about it? Well, I’m glad you asked. I’m writing, speaking, teaching, and consulting. I’m correcting—gently, I hope—the people with whom I connect. I’m avoiding the overemphasis on certification, and emphasizing the values and the principles behind agile.
I’m helping my clients start from where they are and learn how to take those first steps. For some, that means using timeboxes. For some, that means using a kanban board. For almost all of them, it means ending the multitasking. For many of them, it means breaking down those large tasks into much smaller chunks of work.
When people ask questions about how to use cards and stickies instead of tools, it means not jumping down their throats, because they have not seen agile, and I suspect they literally cannot conceive of another way to work. (When I teach traditional project management, I still teach how to start a project with yellow stickies, no matter whether you decide to manage with a Gantt somehow.)
To make Agile cross the chasm, we have to keep showing that agile works. That means we keep working by attraction in our organizations. We keep writing, talking. We keep correcting the misconceptions. We keep running simulations in public helping people feel what it’s like to work in an agile environment. And, we know that not everyone will move to agile.
Not every team is suited to agile, because agile requires real teamwork. Not every manager is ready for the transparency and leadership challenge agile brings. Those organizations who do embrace real agile, not just agile-the-word will discover significant productivity gains.
In the meantime, I’m going to find another way to learn about my participants’ experience with agile. It certainly won’t be asking them about their certifications. It won’t be asking them any questions. I will be doing something experiential. After all, what better way to uncover agile experience, than to use experience to do so?
At some point, agile will cross the chasm, and more people will have real experience with it. Until then, I’ll rely on quick feedback in my workshops. That way, I can inspect and adapt as needed.
