The absurdity of agile transformations
Photo by Olga Guryanova on Unsplash
Imagine taking a seat in the office of your local doctor and telling her that you are experiencing abdominal pain and asking for an appendectomy.
Absurd, right?
Okay, instead, imagine that you describe your symptoms as frequent headaches, nausea, diarrhoea, tinnitus and that you have trouble sleeping. And then your doctor books you in for an appendectomy.
Equally absurd, right?
So, why — oh why? — do we treat business the same way?
As an agile coach for over a decade, the opening two absurd scenarios are analogous to the role I have been asked to play many times. It usually goes something like:
“I just need someone to teach my teams how to do Scrum.”
Or:
“I have 7 different stakeholders each demanding that their pet project is the most urgent, most important thing there is, and my chances of a promotion are nil if any of them complains that I, or my teams, are falling behind on any of them. I have had 5 people leave one team just this year alone, and the support demands are crippling us. Can you help?”
“Sure. I will start with training all your teams in agile fundamentals, teach them to adopt Scrum and then coach the Product Owners and Scrum Masters, help them with metrics, facilitate their ceremonies and monitor their maturity.”
Are either of these any less absurd?
For years, I have been tasked with implementing agile frameworks, without any real context. With little or no organisational support or consideration of the impact of disruptive change, and with no compelling reason for doing so.
I accept that compelling reasons usually existed at one point. Discussed and documented, no doubt, by Sales people and client executives. But then, largely forgotten. The development teams who have Scrum Masters or Coaches imposed on them know nothing of this. They are faced with having to balance the competing demands of their management and stakeholders who simply want their projects delivered on time — all of them — with the outsider telling them their roles have changed, they now need to have new meetings, and that all their ways of working, evolved over months, if not years, must now change. Without understanding why.
No wonder so many agile coaches talk about resistance to change!
The Team Coach is often in an unenviable position, at least as challenging as the development teams themselves. The Enterprise Coach is often no better off, because he has to balance the competing demands of what he (probably) knows the organisation needs, with the changes the executives he reports to will actually endorse. And what they endorse is all-too-often everything except what is really needed.
No, I am not having a go at Scrum or any other framework. They have their place and they are effective in that place.
What I am having a go at is the way that so-called ‘transformations’ are often conducted. And the industry only has itself to blame, because the competence of agile coaches is so often decided by the number of certifications they hold! That is what they know, so that is what they do. It’s akin to teaching doctors how to do surgeries, without teaching them anything about diagnosing the root cause of the patient’s symptoms.
I decided many years ago — in 2017, actually — that, whenever it was in my power to do so, I was not going to simply implement (impose) an agile framework on anyone.
That I would first ask what problems the organisation expected to be solved. To understand the causes and contexts around these issues, to speak to teams and their stakeholders, as well as the person engaging my services. To then propose — and obtain agreement for — a plan of action that may or may not involve an agile framework.
With very little time available, I once had success with teaching a small management team a handful of key principles and asking them if they could help and support their teams to meet those principles in the best way they could, and to continue to improve how they did it.
Change for change’s sake is not the answer. Before we start thinking about agile practices and frameworks — even principles — let’s start asking about the organisation’s challenges and their objectives. Because no two organisations are the same. Then we figure out what needs to change in order to meet those objectives.
If you or your organisation would like to discuss your challenges and objectives, please contact us for a confidential no-obligation discussion.