Note: This is the 3rd and final post in a series about how to truly adopt agility. The first post defined the problem pattern, the second post proposed the root cause. In this final post, we propose some ideas that may help.

Picking up from the last thread: how do you “be” agile? How do you do it at scale?

My own philosophy is to not reach for quick-fix solutions too soon. The inside-out route, though slower, yields better results over the long run.

Story Time

In 2006, Martin Fowler wrote a post titled Semantic Diffusion, about how the essence of Agile software development is getting lost in all the hoopla. I entered the industry around the same time. I didn’t know who Fowler was, or what he was writing, but Agile was certainly a hot buzzword at the time. Over the next few years I absorbed, through observation and osmosis, all the semantically-diffused (watered down) best practices of how to do Agile software development. So when I started leading my first teams, I did it the “Agile” way as I understood it.

My first client presentation on Agile, circa 2008-09

my first agile presentation

Boy, did I know it all. Iterations, standups, velocity, even the chickens-and-pigs joke which I thought was particularly funny.

And for a while it worked. My projects ran and finished successfully.

But no success goes unpunished.

Responsiblities grew. Projects grew more complex. Timelines grew shorter. Clients got more unreasonable. And my success turned to failures. Missed deadlines. Team not happy. Client not happy. I was doing the same things as before, even got Scrum certified! but it wasn’t helping.

At about this time, I met an amazing mentor. He observed what I was doing for a few weeks, asked lots of questions, and he gave me a diagnosis.

Here were 3 things he said I needed to fix:

  1. Stop avoiding conflict
  2. Really listen and seek to understand
  3. Learn to ask for help

Hmm. “Ok,” I said, “how do you do that?” Being a book-smarts guy, I was looking for a recipe. A book to read. A “best practice” to follow.

But he said, “No. Forget the books. You need to rewire your brain to really get this.”

  • You have a problem with conflict avoidance. Go learn Jiu Jitsu.
  • Read the Crucial Conversations book. Then go have a difficult conversation with a different person every. single. day. Report back to me the next morning.
  • Active listening: you’re reaching so fast for a solution, that you’re not really getting to the true problem. You’re only solving the surface level symptoms because that’s all you hear. Learn to truly listen without solving. Ask 5 whys.
  • Record EVERY single meeting you have. Then right after, write down what you thought you heard. Then listen to the actual recording. Work on reducing the difference.

Now to be honest… It was NOT fun. But over time, slowly but surely, I started to get it. My brain was getting rewired.

You see, what we were doing has a name. In self-help books, in performance improvement circles. It’s called Deliberate Practice. By practicing these core things over and over, I didn’t just learn a new skill. I learnt new values.

So why is this relevant?

Changing culture is hard!

At their core, the principles of Agile, Lean, DevOps (or DevSecOps if you prefer), Kanban, Scrum, etc. are very similar. There are some fundamental, universal truths that they are all trying to achieve very similar things.

Early, fast, continuous value to clients. Cross-functional teams that trust each other. Good, timely, effective communication.

And yet, doing these things are hard. They will forever be hard to do, because we are humans.

And it is especially hard to do from the outside-in. “Fake it till you make it” sounds good as a nostrum, but it hinders long-term progress.

Going Inside-Out

Once you’ve internalize the values, the practices matter much less. Which gives you much more flexibility in effecting change.

For instance: the key to effective standups and retrospectives is good communication. So as a leader, once you’ve learnt the nuances of active listening, it doesn’t really matter what format you choose for your standups and retrospectives. Regular standups, “hot potato” standups, plank standups, whatever. Your ears will be tuned to look for communication issues. Silence and violence. Avoidance. Missed committments. True content v/s empty words.

It won’t matter whether you do Pull Requests or Code reviews or Pair programming. The concepts of fast feedback, and feedback from the right source, will be ingrained in you, so you can adjust accordingly.

And you can do all this easily, because it’s within your sphere of influence.

Your Sphere of Influence

We’re so intent on scaling things fast these days. Take a page from Peter Norvig’s book, who wrote “Learn To Program in 10 Years.”

Take the time. Work on yourself first.

Then work on your coaching skills. Start with people around you.

Be a coach. Write and speak more. Learn the skills of influencing. Slowly, over time, you’ll start to make real progress in your organization. And it’ll be the kind of progress that lasts.