I can’t sell Agile to you (And nobody else can either)

There is no magic way to change your beliefs. Here’s how to see the value in Agile fast.

I had tried everything in my coaching arsenal to no avail.

My team started its journey in January of this year. The team now has several Sprints under its belt. One behavior has been difficult to adopt: achieving focus and flow.

It feels great when I make a compelling argument that convinces others to try a new way of working. But all the methods I tried were falling flat with this team.

How I tried to sell my team on focus and flow

My team started its journey by attending Agile and Scrum training. Following the general training was team formation, chartering, and deep-dive training exercises. Achieving focus and flow to meet the Definition of Done was a core aspect of the team’s preparation.

Yet, as the team started Sprinting, several undesirable behaviors appeared:

• Each team member worked alone on his or her Product Backlog Item
• Team members considered an item done when code complete rather than when usable
• Defects and obstacles went into a pile to fix later
• Instead of fixing obstacles impeding a Product Backlog Item, the team started new work
• No working, usable Product Increments by the end of the Sprint
• Unmet Sprint Goals

Many times leading up to the first Sprint and during the Sprints, I coached against this behavior. I suggested the team limit its work-in-progress by working as a team on one Product Backlog Item at a time. I coached them to “stop the line” when obstacles or defects popped up. We discussed the importance of done increments.

Nothing worked.

I explained the benefits of these approaches to looks of skepticism. Successes by other teams were not convincing and shrugged off as “not the same as our situation.” Analogies and metaphors gave some insight, but the team found loopholes. Retrospectives reflected on the current results, but the team took no corrective action.

None of these selling tactics worked to change the team’s behavior or beliefs. Years of ingrained, opposite behavior strengthened the aversion to focus and flow. The methods familiar to the team didn’t use rapid feedback and cross-functional teams. Behaviors for focus and flow were foreign.

As I was contemplating my next move to sway my team to change, a fortunate thing happened. A few members requested I walk them step-by-step through a technique to achieve flow.

This was the way in. I had the team’s desire to try something new.

What did sell my team on focus and flow

I decided the technique we would use would be Mobbing. The team members had high skill specialization. And limiting work-in-progress was an unfamiliar concept.

I knew Mobbing would allow all team members to see every step of moving a Product Backlog Item to done. And there are few better techniques to focus a team than putting all minds on one task at a time. Mobbing is an extreme step into flow, but I took the risk since the team was willing.

Mobbing has one driver at a keyboard and many navigators directing the driver what to type. I sometimes describe Mobbing as “many minds, one keyboard, one task.” Mobbing is a technique created by Woody Zuill, and you can read a great post by him on the approach here.

So after a quick introduction to Mobbing, we dove into trying it. The team’s reactions to the intensity of the technique blew my mind. The team experienced light bulb moment after light bulb moment.

• “You mean to be done, not only do we have to create the database, but we have to build the user interface to present the data?”
• “Let’s discuss the different test cases for this before we build it.”
• “Do we need to document our test cases? How should we do this in a simple way? Should we automate them?”
• “I thought we were going to test in one big batch once we were code complete with the entire backlog.”
• “While we could create this service in case we need it, I suppose it can wait until we need it.”
• “I now realize I don’t understand how to use this tool. I need an overview of how it works.”
• “Does the user need this or should we wait?”
• “Could you show me how to do this in the tool?”
• “That looks like a defect we missed. We should fix it now.”
• “I can see how getting things done in lock-step can make development more sustainable.”
• “This is a new test case we had not considered earlier.”

As a coach, this was a memorable moment. It was also salient for the team. Everything was starting to come into focus and make sense.

I realized the wasted effort in the months of trying to sell the team on focus and flow. One day of trying to practice focus and flow using Mobbing showed the team different results. And most important, these results were the team’s results.

I won’t again forget the power of “try” anytime soon.

Sometimes a coach needs to be reminded of what works

I’ve known for a while how difficult it is to change beliefs. I’ve tried logic, training, debate, analogies, and examples of how others do it. None of these work any better than the others to make change happen.

As an Agile coach, changing minds is part of my job description. But this does not mean the journey of change is not at times frustrating.

You may be familiar with: “You have to say something twelve times in twelve different ways before it sinks in.” When I am trying to change ingrained beliefs, this is what it feels like. But even if I perform this twelve by twelve system, the stubborn, existing behaviors often stay put.

To my delight, the experience with my team reminded me of what does work to change beliefs. And it is dead simple. This was a good wake-up call to stop trying so hard to sell change.

Act yourself into a new way of thinking

The human brain loves habits. If something works for you, you will repeat the behavior until it is an automatic habit. Your beliefs become solidified when you get consistent results from your repeated behavior.

And your steadfast beliefs and habits will carry on unless disrupted. To induce change, you have to interrupt the cycle. Without new experiences to see new results, your belief system will not change.

“It’s easier to act your way into a new way of thinking than think your way into a new way of acting.”

— Jerry Sternin

We often make the mistake of trying to change our beliefs without the benefit of new experiences. Changing a belief system requires a deliberate, sustained change in our behavior. When we see new results from new behaviors, we will start the process of changing our mindset.

Your results from trying a new behavior are the best way to sell it to your mind. Trying the new behavior is what worked for my team in the end. And I have seen it work with many other teams in many other scenarios.

Teams: Have the courage to try, and don’t ask to be sold

Trying something new can be scary. It takes courage. And it takes the support of management and the guidance of a coach to help learn a new technique.

The courage to try is often dampened when no room is made for improvement or when improvement is seen as a cost and not an investment. When teams don’t feel support for improvement, they will not take the risk of trying something new.

By verbally making change a priority, a manager can create a safe environment for teams to experiment with new methods. Sometimes all it takes is asking your manager to make the room for improvement. Once you have space to change, the next step is up to you.

My team is still not completely convinced with the value of its new behaviors. But now it is practicing the technique. Over time, different results will shift beliefs about focus and flow. It will be tedious and frustrating at times, but that is the thrill of the journey.

So don’t ask your coach to sell you on something new. Instead, take a step into unknown territory. You will see new results if you keep at it. Before long, your mindset will shift, and your Agile journey will find its stride.

Let your motto be: “Let’s try it.”

For more content like this on my pursuit of Lean Leverage, delivered to your inbox, you can just join my email list. Or see my other related posts below to dive even deeper.

A special thanks goes to Maarten Dalmijn for his thoughtful review and editorial contributions to this post.

Related Posts

For posts similar to this one, check out the ones below: