Agile is misunderstood. The question I wrestle with — is Agile misunderstood because it has been distorted, or has Agile been distorted because it is misunderstood? As I make the case in my book, Pursuing Timeless Agility, what many organizations are doing, what is often taught, does not align with the intent of Agile. The question is, did this occur by accident or on purpose? I believe this is a case of unintentional intent to distort. Let me explain.
The Challenge
If you are in management or part of a leadership team, you know how hard it is to propagate your values down into the organization. Despite having organizational rank and authority, it is still challenging to get everyone to embrace the same mindset and act accordingly. How much more so is the challenge to push a mindset change upward into and throughout the management team without the influence of rank and authority?
Respondents of the VersionOne 12th Annual State of Agile Report cited two challenges that directly relates to this distortion issue.
- Organizational culture at odds with agile values
- Inadequate management support and sponsorship
What these responses tell me is that management may be in favor of their development teams “doing agile,” but lack the understanding that Agile transformation requires a mindset shift throughout the organization. Management claims successful Agile transformation while not embracing much of the intent of Agile. It becomes Agile on their terms.
Agile transformation often takes root at the team level and then tries to push those values and principles upward into the management layer. This is why transformation can be so difficult. Many times that wall is too high to get over and culture remains the obstacle to genuine Agile transformation. A team may become more Agile in isolation, and within its own context, but that is not Agile transformation.
The Compromise
In order to proceed with this new way of working, early adopters conceded they must still provide management with traditional output-focused metrics and accommodate traditional command and control style management. Despite being contrary to true Agile, teams compromised, feeling that something was better than nothing. This still happens today as well, but I am trying to give it a historical cause and effect context.
Management’s lack of understanding and willingness to transform how work was done and measured opened the door for compromise. As more organizations became open to the idea of exploring Agile, training and certification companies provided offerings that straddled this compromise. So, in essence, the distortion was propagated intentionally in order to sell it and allow at least pieces of Agile to enter. The “Certification Economy” grew while true Agile suffered.
The organizations that brought in Agile practices on their own terms never really understood or embraced what Agile really intended to provide, so misunderstanding propagated within their walls. Training and certification organizations accommodated this cultural compromise and their teaching reflected this distorted understanding. This is seen in the common metrics mistakes.
What Many Are Calling Agile Is Not Agile
Organizations wanting to learn Agile, perhaps with the right intent, were taught the wrong things — and still are today. They are taught that Agile thinking is for development and delivery teams only. They are taught that Agile is about being more productive and better at being on time. They are taught that using popular tools, writing user stories, working in Sprints, and having daily stand up meetings makes them Agile.
Coaching is now prevalent and accepted, yet what many coaches are teaching is faux Agile — ideas based on a misunderstanding rooted in the unintentional intentional distortion of Agile. This misunderstanding across industry has grown exponentially.
Many organizations do not even recognize this dilemma. This misunderstanding is sending organizations down the wrong path, or I can at least suggest it is a less effective path. The downstream impacts of misunderstanding are cascading.
Increasing the productivity of every team seems to be the primary goal, so processes and practices that support more outputs are standardized and pushed to all teams. This is otherwise known as scaling. Yet none of that has anything to do with the intent of the Agile Manifesto.
Misunderstanding Leads to Misapplication
When I ask folks to tell me what success looks like with Agile, the response is often around how well the team delivers the committed scope each Sprint — on time and on budget. When I ask how they know when a team or organization is Agile, the response is often that the teams are holding daily standup meetings, doing routine backlog grooming, Sprint Planning, Sprint Reviews, Retrospectives, and other Scrum-related activities. Many are not able to articulate the difference between Agile and Scrum. There is a widespread misunderstanding of what Agile really is.
As you seek Agile transformation, what is it exactly you are aiming to transform? Agile transformation is only as good as what Agile is to you. If your understanding is wrong, you will seek to transform the wrong things. If your understanding is incomplete, you will fall short on attaining all the intended benefits. Either way, organizational agility will remain out of reach, or incomplete at best.
Making It Right
If you see the distortion at work in your organization, do not dispair. You can make it right. I spend the entire back half of my book, Pursuing Timeless Agility: the Path to Lasting Agile Transformation, walking through addressing the problem, but I can offer a view points here.
Understand Your Starting Point
An organization that is far down the wrong path is not necessarily harder to transform than one that is new to the concepts altogether. It is important you assess the organization’s current position and readiness for real Agile, and approach the transformation appropriately. Regardless, pushing forward poorly is still better than not going there at all.
Is Agile really what the organization wants and is leadership ready to make the cultural changes necessary to see the fruits of the transformation? In short, do they value an empirical process — short learning cycles of do something small, experience the results, learn from that experience, and then adjust? If an empirical approach is ever rejected as a viable method for your organization, then Agile is not fit for purpose. Therefore, you must first seek to understand how your organization receives working empirically, and then if the corresponding values, principles, and concepts resonate.
Starting Smart
You can’t hurry the harvest by flooding the fields. An empirical approach is about trying something, learning from it, and adjusting. The same holds true for Agile transformation. You cannot implement or adopt Agile. Change occurs most successfully in small bites with repetition. Find one thing you can change that will make a difference. Change that, let it settle in, and move on to the next right thing to change.
Put Frameworks In Their Place
Frameworks are great starting places to help teach new concepts and put them into practice. The caveat is that it is far too easy for teams to get stuck inside a framework and specific tools.
Do not let this keep you from using Scrum or other frameworks. Use what works from the framework, learn how non-framework practices can fit your team and situation better, and just continuously seek to live out Agile values, principles, and concepts in ways that make sense for each team respectively. Keep filling the gaps.
I think it is more important to understand what frameworks offer and how to leverage what you need, when you need it, than to get caught up in trying to adopt or implement anything specific wholeheartedly. This is easier said than done because it requires someone who understands this to lead the teams. Helping the team determine what it should do, and how, is what coaches do. My advice to you is do not get caught up into the “Certification Economy” or feel the need to use popular tools. Do what makes sense for your teams, as they need it. Stay aligned with Agile, and you will be fine.