My 3 most common Agile pitfalls
Hello, curious individuals and fellow agilists.
The success or failure of an Agile transformation is driven by a number of factors, and these elements can interact in complicated ways. Consequently, it is difficult to establish precise percentages for the failure of Agile transformations attributable to specific areas. Additionally, failure may come in various and often distinct ways. That being said, we know that to evaluate it is not a straightforward simple science.
With this in mind, today I want to focus on three of the usual suspects, also known as frequent pitfalls, that I have personally been experiencing while participating in Agile Transformations over the years I have been involved in such endeavours. These are, in my view, the most common, and worst pitfalls of any Agile transformation.
Limiting the Transformation
The boundaries established from an early stage have been one of the themes that have come up repeatedly on various companies that I have had the pleasure and luck of working with.
I make an effort to speak with as many stakeholders as I can during my first few weeks at a new organisation to get a sense of their realities, their worries, their aspirations, and their general perspectives on Agile. Of course, this also applies to anyone who is superior than me in the overall vertical structure of any organisation. And the subject frequently comes up in discussion along the lines of:
“Welcome. We’re depending on your knowledge to support us through this transformation. What are your ideas on the next steps?”
I then make my comments in light of what I have noticed and how I believe we can proceed. Then it dawns on me…
“Yes, I concur that we need to reform everything. However, let’s concentrate on this first because changing this or that is impractical. As you can see, we are a business that…”
In the end, all they really want is for their IT teams to work in Scrum and perhaps use Jira, if they can afford it. Yes, we recruit Scrum Masters and offer Agile, Scrum, and, on occasion, if you’re lucky, Kanban training. We might even outline a general vision for the transformation, but it is a given that we will be blocked from discussing any issue that even suggests altering anything other than how the IT teams conduct their business. God forbid if we advise that upper-level management should also undergo transformation.
Personally I believe this to be the main problem with ongoing “Agile transformations”. The next two pitfalls are actually a bit of a twist to this one, but merit the mention on their own.
Follow a transformation effort as a project
Assuming you have overcome the first impact of knowing what the real playing field is, if you are anything like me, you’ll draft something regarding the transformation, identifying key players, topics to focus on, ways to improve focus, flow, predictability, etc. These may include ideas on capacity management, dependency management, relationship with stakeholders, so on and so forth. And also topics related with psychological safety, trust and efficient/effective communication. But more often than not you’ll receive a request: “Please present a plan for the next quarter/year. Include costs and resources.”. At that moment, you know your transformation is most likely headed for doom, as it will probably be treated as a program/project. It is not.
An Agile transformation is never ending. We should be constantly evolving, changing, growing. An Agile transformation is a set of different endeavours, that may encompass training, staffing, setting up tools and processes, but is not limited by that. An Agile Transformation impacts an organisation culture, behaviours, and as such is constantly morphing.
An Agile transformation needs to become a part of who you are. Agile is not the end, it’s the way.
领英推荐
Lack of real commitment and support from the leadership
We’ll finish with the issue that most Agile coaches point to as the one that sums it all up.
As an organisation decides to embark on an Agile transformation, declaring that “we are going to be Agile” or that “we support Agile” by management is undoubtedly insufficient. In many cases, if not most, C-Level leadership provides “support” through various speeches and declarations, but don’t follow through with actions, nor even understand the implications of what they just declared.
Maybe this is due to a misunderstanding of what an Agile transformation encompasses. If this is the case, who would be responsible? The person of people who decided to start the effort without enough information? The consultant or consultancy firm hired to overview said effort?
Worse, considering an Agile transformation just an aspect of a Digital Transformation? It’s not even close. Completely different topics, often wrongfully mixed.
How about when they focus on changing, but just a little bit? Maybe having the teams working with Jira will suffice?
It could be misunderstanding or any other possible number of reasons. The thing is that if you wish to start an Agile transformation in your company, you first need to understand a couple of things:
My personal take on this? If you don’t know (or don’t want to know) the real honest answers to these three questions, do not even bother to start. You’re not ready.
Agile is not something that miraculously brings more income. Agile is not putting your teams working with Scrum and expecting super mega productivity. In fact, you may have all your IT teams well organised working with Scrum (or whatever framework you choose) and Jira (or any other tool) with all the bells and whistles and that, on its own, down not mean they are Agile. And surely not your company.
Also, Agile impacts the whole, not just sections of you organisation. If you are focused on building products, as an example, it’s not something that only the team building or executing. It includes the very early stages, from inception, all the way until after the product is out there.
In Conclusion
If you want to start an Agile transformation, do it properly. Understand that it affects your whole organisation, and that you need the buy in from all, but also the commitment to embrace it as becoming who you are, not just what you do.
Beware of the companies and/or professionals you hire for the job. If they want to sell you ready made solutions, don’t. Just don’t.
There are several articles that focus on the reasons on why Agile fails. I am listing just a few. As you will see, or at least this is my interpretation, regardless of the approach or the description presented, it all comes down to one thing, and one thing only: they want to change but down’t know how and are not willing to sacrifice the established status quo for something new. After all, change is hard. Yes, it is. But it is needed. Otherwise we will become obsolete. People and organisations.
As a final note: one size does NOT fit all.