Too often, we emphasize the name of a thing over the potential outcome of the thing. We assume that when we exercise our understanding of the agile terrain via terminology that others have the same, rich mental models we do. I’m also sure many of us feel that using agile terminology lends us a bit of credibility. However, it’s not knowledge or buzz words that makes us credible. That’s earned by helping those around us solve challenging problems. To that end, let’s try a different approach:
Stop looking down at the map for answers. Instead, look up at your surroundings and talk to the natives.
To emphasize my point, have you ever told a team that we’re going to give Scrum a go and heard something like this?
We tried Scrum in my last organization, and it went miserably. I don’t want to live through that crap again.
Like me, I’d venture to guess you began asking more questions. As I did, I usually discovered they weren’t talking about Scrum at all but a cargo cult or possibly Dark Scrum. No wonder they hated it. Based on their stories, I would too!
I think it’s about time we put agile terminology aside–avoid it even–and simply begin helping others. With that in mind, I’d like to take two common terms and demonstrate how to weave them into conversation with organizations and with teams without using the words themselves.
This is one of those terms I see thrown around the community like a sailor throws around four letter words, and I think the concept is largely misunderstood. It is also the impetus behind this blog post, and it looks like this in conversation:
- “What can I do to make your job easier?” (This is often the last thing I say after talking with team members, my own reports, and even the founder of our company.)
- “Grant, you’ve been kicking ass getting the deploy out today. Want me to grab you something from the kitchen?”
- “Look. You can expect I’ll pull you in a room and tell you if I see something that concerns me. I’ll probably be blunt about it so I hope you return the favor if you see me slacking. I’m human just like the rest of us.”
- “The best ideas are never be mine. You live and breathe this every day. You all just keep me around because I sometimes ask some interesting questions.”
T-shaped means that a team member excels at one activity but is also capable of performing other activities that benefit the team. That’s not to say that everyone on the team can excel at every activity equally. Instead, it means that there’s a great deal of overlap in skills across the team to mitigate bottlenecks and to foster a common language. Below are a few ways to weave this concept into conversation:
- “Frank seems like he holds a rather pivotal role on our team. What happens if he’s sick or wants to take some time off?”
- “Linda, I know how much you enjoy designing, but have you thought about helping the team test by beating up on the implementation of your designs? That way, it’ll give us time to shore up any problems before we go live.”
- “Can we stop talking about how we should just focus on the stuff we’re good at? Look at all the confusion last sprint. Am I the only one who thinks hand offs are expensive? How could we quantify that cost?”
- “You’re looking for something to do today? Are you interested in pairing with Jack? It sounds like he was looking for a second set of eyes.”
- “Bill, I don’t want you checking email while you’re on vacation. You earned some time to relax and recuperate. We got this, and even if we don’t, maybe we should feel it. How’s that sound?”
The idea of avoiding agile terminology isn’t new. In fact, many have begun to call this notion Undercover Agile. Take a moment with me and appreciate the irony of naming a thing that’s adverse to talking about the names of things. Let me know in the comments below if the break down of the two terms above was useful. If so, I’ll do a series of similar posts.
Until next time.
Do you want to get notified when new posts are published? Leave your email below.
4 thoughts on “The Map Is Not The Territory”
Similarly, the project plan and the metrics are not the territory either. Agile is about empowering the people working where the tire meets the road to iteratively figure out how to best meet the objectives, regardless of the initial plan, requirements, and KPIs.
So many organizations giving teams the responsibility to deliver without the authority, support, communication, feedback, facilitation, freedom and trust to learn to fulfill that responsibility is what gives Scrum and Agile a bad reputation.
It is not hard to see why people that have lived that nightmare are reluctant to trust Scrum again.
So true! And great to see you again, Steve. I hope your teams are treating you well, my friend.
Great work! I find the word “servant-leadership” has become a cliche that drags a world of eye-rolls from executives…and is a bit self-conscious. I doubt a center on a football team thinks of himself as a “servant leader” but instead is clear about his role and the impact and importance to the team.
Thanks, Scott. And agreed. It has become a bit cliche, which is too bad. I remember the first time I learned about servant leadership and thought …. Is there any other kind? I had a laugh when Brian Rivera told a similar story on LinkedIn a while back.