False Barriers to Implementing Scrum – II

In a previous post, I described several barriers to implementing scrum. Recently, an additional example came to light similar to the mistake of elevating scrum or Agile to a philosophy.

In a conversation with a colleague, we were exploring ways on how we might drive interest for browsing the growing wealth of Agile related information being added to the company wiki.  It’s an impressive collection of experiences of how other teams have solved a wide array of interesting problems using Agile principles and practices. Knowing that we cannot personally attend to every need on every project team, we were talking through various ways to develop the capacity for exploration and self-education. I think I must have used the phrase “the information is out there and readily available” a couple of times to many because my colleague reacted to where I put the bar by comparing learning Agile to surgery.

Using the surgery metaphor, she pressed the comparison that all the information she needs about surgery is “out there and readily available” but even if she knew all that information she likely wouldn’t be a good surgeon. Fair point that experience and practice are important. And if that is the case, then everyone should be taking every opportunity they can to practice good agile rather than regressing to old habits.

More importantly, perhaps, is the misapplied metaphor. Practicing agile isn’t as complicated as surgery or rocket science or any other such endeavor that requires years of deep study and practice. Comparing it to something like that places the prospects of doing well in a short amount of time mentally beyond the reach of any potential practitioners.

Perhaps a better metaphor is the opening of a new rail line in the city. A good measure of effort needs to be expended to educate the public on the line’s availability, the schedules, how to purchase fares, where the connections are, what are the safety features, etc. Having done that, having “put the information out there where it is generally available,” it is a reasonable expectation that the public will make the effort to find it when they need it. It is unreasonable, and unscaleable, to build such a system and then expect that every passenger will be personally escorted from their front door to their seat on the train.

It is also interesting to consider what this does to the “empathy scale” when such an overextended metaphor is applied to efforts such as learning to practice Agile. If we frame learning Agile as similar to surgery then as people work to implement Agile are we more inclined to have an excessive amount of empathy for their struggles and be more accepting or accommodating of their short comings?

“Not to worry that you still don’t have a well formed product backlog. This is like surgery, after all.”

Are we as an organization and each of our employees better served by the application of a more appropriate metaphor, one that matches the skill and expectations of the task?

“We’ve provided instruction as to what a product backlog is and how to create one. We’ve guided you as you’ve practiced refining a product backlog. You know where to find suggestions for improving your skills for product backlog stewardship (wiki, books, colleagues, etc). Now role up your sleeves and do the work.”

Successful coaching for developing the ability in team members for actively seeking answers requires skillfully letting them struggle and fail in recoverable ways. It is possible to hold their hand too long. To use another metaphor, provide whatever guidance and instruction you need to so they know how to fish, then let them alone to practice casting their own line.

Photo credit: langll

Moving Past “I Don’t Know”

Recently I had the opportunity to attend the Mile High Agile 2015 conference in Denver where Mike Cohn delivered the morning keynote address: “Let Go of Knowing: How Holding onto Views May Be Holding You Back.” As you might expect from a seasoned professional, it was an excellent presentation and very well received. A collection of 250+ scrum masters, product owners, and agile coaches is no stranger to mistakes, failures, and terrifying moments of doubt.

As valuable as the ideas in Cohn’s presentation are, I want to take them further. Not further into the value of keeping our sense of sureness somewhat relaxed, rather onto some thoughts about what’s next. After we’ve reached a place of acknowledging we don’t know something and are less sure then we were just a moment before, where do we go from there? It’s an important question, because if you don’t have an answer, you’re open to trouble.

The “I Don’t Know” Vacuum

Humans are wired to find meaning in almost every pattern they experience. The cognitive vacuum created by doubt and uncertainty is so strong it will cause seemingly rational people to grasp at the most untenable of straws. It’s a difficult path, but developing the skill for being comfortable with moments of doubt and uncertainty can lead to new insights and deeper understanding if we give our brains a little time to search and explore. Hanging out in a space of doubt and uncertainty may be fine for a little while, but it isn’t a wise place to build a home.

After acknowledging we don’t know something or that we’ve  been wrong in our thinking, it’s important to make sure the question “What’s next?” doesn’t go begging. I’d wager we’ve all had the dubious pleasure of discovering what we don’t know in full view of others and in those situations the answer to this question becomes critical. It may not need an immediate answer, but it does need an answer. If you don’t work to fill the vacuum left by “I don’t know” or “I was wrong,” someone else surely will and it may not move the conversation in the direction you intended.

The phenomenon works like this. Bob, a capable scrum master, ends up in a situation that reveals a lack of experience or understanding with the scrum framework and doesn’t know what to do. Alice, maybe immediately or maybe later, moves into the ambiguity, assumes control, and tells the team what should be done. If Alice is wise in the ways of agile, this could end well. If command-and-control is her modus operandi in the defence of silos and waterfall, it probably won’t.

So how can an agile practitioner prepare themselves to respond effectively in situations of doubt and uncertainty? Here are a few things that have worked for me.

Feynman-ize the Conversation

In his book “Surely You’re Joking , Mr. Feynman!,” Nobel physicist Richard Feynman tells a story from his early career where several building engineers started reviewing blueprints with him, thinking he knew how to read them. He didn’t. Having been surprised by being placed in a position of assumed expertise, Feynman improvised by pointing at a mysterious but ubiquitous symbol on the blueprint and asking, “What if that sticks?” The engineers studied the blueprint in light of Feynman’s question and realized the plans had a critical flaw in a system of safety valves.

That’s how to Feynman-ize a conversation. Start asking questions about things you don’t understand in a manner that challenges those around you to seek the answer you need. In essence, it expands the sphere of doubt and uncertainty to include others in the situation. This tactic is particularly effective in situations where corporate politics are strong. Bringing the whole team into the uncertainty space helps neutralize unhelpful behaviors and increase the probability the best answer for the moment will be found. It is no longer just you who doesn’t know. It’s us that that don’t know. That’s a bigger vacuum in search of an answer. In short order, it’s likely one will be pulled in.

The Solution Menu

Thinking of the agile practitioners in my professional circle, they are all adept at generating possibilities and searching their experience reservoir for answers based on similar circumstances. When the creative juices or flow of answers from the past are somewhat parched by the current challenge, it is natural to project the appearance of not knowing. Unless you’ve drawn a complete blank, you can still use the less-than-ideal options that came to mind.

“I can think of several possible solutions,” you might say. “But I’m not yet sure how they can be adapted to this challenge.” Then offer your short list of items for consideration. One of those menu choices might be the spark that inspires a team members to think of a better idea. Someone else may find an innovative combination of menu choices that gets to the heart of the issue. I’ve even had someone mishear one of my menu choices such that what they thought they heard turned out to be the more viable solution. This is just another way to leverage the power of everyone’s innate drive for finding meaning.

Design an Experiment

If there is a glove that fits the “I don’t know” hand, it’s experimentation. I suppose you could work to stretch the guessing glove over “I don’t know.” But if your team is aware that you don’t know something, it’s worse if they know you’re pretending that you do. Challenges and problems are the situation’s way of asking you questions. If the answers aren’t apparent, form a solution hypothesis, set up a simple test, and evaluate the results. And as the shampoo bottle says: lather, rinse, repeat until the problem is washed away. It’s another way to expand the sphere of uncertainty to include the whole team and increase the creative power brought to bear on the problem. If your shampoo bottle is this agile, I’ve every confidence you can be, too.

Now I’m curious. What has helped you move past “I don’t know?”

This article was originally published by the Scrum Alliance under Member Articles.