The REAL Gap in Agile Shops: Do You Grok?

In my IT career, I have spent a lot of time in and around various Agile frameworks and processes, primarily Scrum or ScrumBut methods. I'm currently a ScrumMaster (aka Technical Project Manager at my company, Ascend Learning), was a Product Owner for 3 years at RSA, and have taught Agile Fundamentals courses as a continuing education instructor. Recently, I've made a concerted effort to engage with other Agile practitioners through LinkedIn groups, conferences, and other means. If you do the same, you have almost certainly seen a dizzying array of articles with titles ranging from "Agile is the best thing in the Universe!" to "Agile is dead!" as well tons of discussions on the *exact best way* to do Agile. A lot of the most thought provoking articles claim to have found the ultimate reason why Agile is broken. I love those articles, because they force me to examine my assumptions about various aspects of Agile and how my teams execute Agile development. And also because, pretty much without fail, the assertions are WRONG. Why do I say that? Because I don't think Agile is broken. It's Agile practitioners that are the problem.

Why do I say that? Because far too few Agile Practitioners don't grok Agile.

If you are not sufficiently geeky to spend your spare time reading 1960s Science Fiction novels, you may think that I am making up words when you read the term "grok." I promise you, I'm not. Robert Heinlein made up that word for me in his 1961 book Stranger in a Strange Land. A quick look at dictionary.com provides the following definition:

grok:

1) (verb with object) to understand thoroughly and intuitively

2) (verb without object) to communicate sympathetically

That definition is a good start, but there is a lot more nuance to grok. Indeed, some people consider Heinlein's entire book to be an extended narrative definition of the term, which you can read about here. I consider it a beautiful word. I think of grokking something as understanding it at a soul level, so much that the principle becomes part of you.

And that is exactly what we, the Agile community, from team members to clients to executives, are NOT doing. We are not understanding Agile enough to make it part of ourselves.

A lot of you might think I am bananas for saying this. You might be leading a software engineering organization that has many Agile teams. You might have gotten your CSM credential and started working as a Scrum Master. You might be a developer who has been working in an Agile shop for years. You figure that your years of experience and the shiny letters behind your name mean that you understand Agile - and I hope that at least some of the people reading this actually DO. But I'm betting that many of you don't yet....and that is OK.

How can you tell if you, your organization, or someone in the Agile community doesn't grok Agile yet? Off the top of my head......

• They automatically associate Agile with Scrum. Nope, this doesn't work. There are a ton of Agile methodologies and frameworks. Scrum might be the most popular, but it isn't the only one and it wasn't even the first.
• They argue about "what role does which task" all the time. I see this all the time in LinkedIn discussion groups - people argue over who makes decisions, who is responsible for estimating, who sets a Definition of Done, and who is responsible for updating the $#@% ticket status in JIRA. From an individual team perspective, this matters *tremendously* because it plays into how a specific set of people can accomplish a specific set of work that delivers business value. From a big picture perspective, a lot of this stuff is borderline irrelevant.
• They spend a significant amount of time doing work without understanding the business value of their deliverables. Delivery of business value is one of the key tenets of Agile, so if the team doesn't understand this, something is missing.

and my personal favorite

• Trying to figure out how to compare velocity across teams. This one makes my head hurt and my soul die a little every time someone asks how to do it. (Simple answer - you don't.)

There are a thousand little ways in which Agile teams, Agile practitioners, and executives in Agile organizations demonstrate the degree to which they do or do not grok Agile on a daily basis. I plan to explore some of these in more detail in future blog posts, but for now I'd encourage you to look in yourself and ask "Am I really grokking Agile?" If you aren't, then I suggest that you go back to the basics.

Revisit the Agile Manifesto.

Think about your clients and what they need out of your products.

Challenge Agile Dogma when you see it.

Strive to deliver value, every single day.

Comment below if you can think of things that indicate a person or team might not be grokking Agile. Who knows, maybe I'll write about it!

-----------------------------------------------------------------

Diana Alt is a recovering product manager and current technical project manager who has 18 years of experience in IT shops ranging from Waterfall to ScrumFall to ScrumBut to Scrum with a little Kanban and a lot of Cowboy thrown in for good measure. She uses her skills in sorting out confusion and chaos both in her day job at Ascend Learning and as a career and networking coach. Some of her favorite words are "grok", "why", and "kaizen".