The following is excerpted from the book, Pursuing Timeless Agility: the Path to Lasting Agile Transformation.
Fit For Purpose
If your organization does software development and delivers software products of any kind, it seems obvious in 2019 that you should be “doing Agile.” It is obvious to me that software teams will benefit from following genuine Agile, but the data suggests you may want to assess this a little deeper for your organization.
In my book, I spend quite a bit of time demonstrating how many of the reasons why organizations choose Agile are for the wrong reasons as compared to the true meaning and intent of Agile. This decision is mainly based on a misunderstanding of what Agile actually is, and the results are disastrous.
For many people, they believe their organization can benefit from embracing the values, principles, and concepts of Agile – that Agile is fit for purpose. However, their organization is often not working in complete alignment with the intended purpose of Agile, nor attaining its intended benefits. If this describes your situation, it creates a dilemma for you to reconcile. Your organization is doing what it is doing, and has the culture it has, because either the organization rejects the true meaning and intent of Agile, or it merely misunderstands how to apply it.
If the collective mindset and culture of your organization is what it truly wants and needs, then you may have to consider that Agile is not fit for purpose to meet the organization’s objectives. Think about it, if the management culture is command and control, then Agile is not fit for purpose. If it is always imperative to deliver pre-planned work within pre-planned schedules, no matter what, then Agile is not fit for purpose. If standardizing processes, practices, and tools across all teams is engrained and desired, then Agile is not fit for purpose. Therefore, the only way you can move forward with Agile transformation is to believe that the actions you see are not what the organization really wants.
The Assessment
Before you embark on an Agile transformation, to change how the organization thinks and works, you must first understand what the organization is really trying to achieve by doing what it is doing. Does management really think people are not smart enough to accomplish organizational goals such that they need to standardize and tell people how to work, and then micromanage that work? Maybe…but assuming that is not true, what is really behind these actions?
What if traditional command and control, and enforcing standards, is nothing more than blindly following what has always been taught? Traditional management teaching suggests that managers must decide what is best and then manage teams around that. What if managers believe that relinquishing that responsibility means that they are no longer needed, so they hold onto this approach out of fear?
Effective transformation starts with understanding and accepting the centrality of an empirical approach.
I find it very hard for anyone to refute the value of an empirical approach, when they understand it. Once that concept is bought into, you can work backwards to demonstrate how certain ways of working support empirical thinking, and how certain methods impede it. Using this concept as a baseline objective will help you identify alignment, or lack thereof, for anything the organization does.
If the people within your organization cannot buy into the value of an empirical approach, then whatever you end up doing is not really aligned with Agile. Share on XIf 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.
Action: Discuss empirical thinking with teams and managers across the organization.
Observation: How well is an empirical approach received; is it desired?
Action: If an empirical approach is well received, discuss the Timeless Concepts from Chapter Two of the book, Pursuing Timeless Agility: the Path to Lasting Agile Transformation.