In Agile Coaching we always talk about transformation, changing the entire structure and the ways in which a company organizes itself.
When I started in this field more than a decade ago, we were passionate but humble, almost no one had proper experiences of how these huge changes worked and what Agile ways of working could mean for every part of the organization. We baby-stepped forward, fully believing the Agile Manifesto would properly guide us. Those were fun times, sometimes frustrating, but we did learn a lot. And by “we,” I actually mean the entire Agile community, which got a lot of traction and a well established knowledge exchange that became the primary source of learning for us.
A common pitfall was that organizations didn’t let us rock the boat too much. We were perhaps allowed to go “Agile” or Scrum with one team, almost always an IT engineering team, and whenever we touched the perimeters of the rest of the company we were asked “Do we really need this much Agility?”
Over time best practices established themselves, failures were taken into consideration and we became bolder. We wanted it all…
It is absolutely correct to point out that if you want to truly transform your organization, you need to be courageous enough to change some fundamentals. Agile Coaches became stronger minded with an increasing “you can do it like this, but then you won’t be Agile” attitude. This was a healthy development. We needed to make clear that a new coat of paint on a rotten foundation would only work as a short term detraction for employees or investors alike.
A new breed of coaches evolved out of this attitude; the ones that always go for the jugular. “We have to change this and this and that. If you don’t do ‘THIS’ thing you will never be Agile.”
While this can add value to an organization, I have come to the conclusion that a generic approach like this is actually detrimental to change, and most importantly, to building trust. The less trust in us, the less trust in major changes.
We are rather often asked to consult or coach companies that have not only already gone through several (failed) transformations, but also companies embedded in larger and more rigid structures, such as subsidiaries of huge corporations and the like.
My experience is that most coaches who go to the client with the best of intentions, and challenge everything, quite bluntly, will probably be perceived as annoying, possibly even unhelpful; simply not get a continuous engagement or even be let go before the end of the contract.
Some of us Agile Coaches are large household names and have some leverage with their track record and might be able to pull it off by sheer power of reputation. But I pity the fool in their first year of consulting who thinks they can turn a huge oil tanker around by the mere power of thinking that they’re right about their assumptions.
To be honest, most of these structures don’t want a huge change, nor are they often capable of doing so due to a myriad of dependencies within their setup.
So what do we do here? Go in everytime and tell everyone constantly that their ways of working are wrong? What do you think will happen? Even the developers will be fed up at one point because simply demanding the big change does not address their everyday problems.
So, pick your battles! A company is running in some weird Kanban-ish mode, but without WIP limits, not even doing retrospectives or any kind of Deming-Cycle appropriation? Telling them that this is not Kanban won’t help. They probably know that deep within themselves. Talk to them. Get a feeling for them. Figure out the next step that would not need too much convincing. Work your way up until they are ok with you running retrospectives for them. That’s the jackpot, because without pushing for a framework or using buzzwords, people will bring their problems to you. Sometimes even prioritized (depends on how you run retros), and then you can tap into your vast toolkit and provide suggestions.
Sometimes I even refrain from using buzzwords because some of them were already tainted in that company. We don’t “estimate,” we “size” stories. We don’t do “reviews,” we do “demo time.” We call it an “improvement session,” instead of a “retro”, albeit always sticking to the purpose these rituals or artifacts were meant to have.
The more trust you build with tiny wins, the more people will be willing to swallow the more bitter pills when you challenge other aspects of that company.
Over time you will reach a level of improvement that, by itself, will challenge the entire organization and then the wheat separates itself from the chaff. If an organization is willing to adapt, you can use all the small wins as winning examples to sell more Agility to management and get them onboard as sponsors. If not and they’re unwilling, you know you reached the peak of what you can achieve in this company, which is also an important clarity of vision.
I’m afraid the latter will be more frequent and it can be frustrating sometimes, but don’t forget that you made a lot of people’s lives a bit easier and demonstrated the practicality of Agile in the real world. That’s worth something.
But to reach even this point, you need to be patient, humble and diplomatic. You have to be able to quickly evaluate the situation at hand and then pick the right battles.