Agile - Is it Real or is it Fake?

At the World Agility Forum in Lisbon Portugal on September 29, a panel of leading Agilists focused on “Shifting perspectives to know what is Real (agile)” The panel was made up of Chet Hendrickson, Steve Denning, Nigel Thurlow, and Mario Moreira.  We discussed “What is fake Agile? What is real Agile?”

What is real Agile?  It starts with an alignment to the Agile Values and Principles.  Without understanding and embracing the values and principles, whatever a company is doing is certainly something but can it really be considered real agile?

Agile is more than mechanically applying Agile processes. This I refer to as “doing Agile”. More important than choosing a particular process of Agile, is the art of learning how to live Agile values and principles, to transform Agile mechanics into Agile mindset. This is what I call “being Agile.” 

Steve shared that fake Agile is really a reference to “Agile in name only”.  Since many companies want the badge, he indicated that to understand if companies are Agile, you need to look beyond what they are saying and look at what they are doing.

Nigel discussed how companies feel the need to get on the Agile bandwagon and do Agile as it is the trend.  He stressed the importance of understanding the benefits that Agile can bring and focusing on this instead of Agile itself.

Chet shared that there may be something much worse than fake Agile and that is “dark Agile”.  This is using Agile as pressure to get more work done or impose Agile on a team and not remove any of the constraints leading to numerous anti-patterns. 

Mario talked about a concept akin to fake Agile which I call “FrAgile”. This is when Agile is so minutely applied with little focus on the Agile Values and Principles that it quickly becomes brittle, lacks vigor, and shatters once there is tension applied, leading to a regression to old ways of working.

It was a healthy and collaborative discussion leading to a clear awareness of how fake Agile is damaging the good name of Agile.  Instead, it is time to bring pointed awareness of what is and isn’t agile and advocate for “being Agile” and the outcomes it can bring.

For more on Fake Agile, consider reading:

• Understanding Fake Agile by Steve Denning  
• You may be FrAgile if… by Mario Moreira 

Have you Crossed the Agile Chasm?

In 1991, Geoffrey Moore refined the classic technology adoption model with an additional element he called the “chasm.”[1] He advanced a proposition specific to disruptive innovation that there is a significant shift in mentality to be crossed between the early adopter and the early majority groups. Disruptive innovation is the development of new values that forces a significant change of behavior to the culture adopting it. In this case, Agile is that disruptive force that insists on applying a set of values and principles within a specific culture of “being Agile” to be successful and for the organization to realize the full business benefits of Agile.

At first glance, it would appear that many companies have adopted Agile. I believe, however, that this perception is specious, in view of the further observation that the majority of companies that are “doing” Agile have not actually adopted the new values and principles and not made the cultural shift to actually “being” Agile. Such companies look at Agile as a set of skills, tools, and procedural changes and not the integrated behavioral and cultural change it truly is. In other words, they think they have crossed the chasm, but they have not made the significant change of behavior required to make the leap.

My experience in the field leads me to posit a refinement on Moore's chasm concept as applied to Agile. First, there is the real Agile chasm between those on the left side who have made the organic behavioral changes consistent with the values of being Agile―and those on the right side who are just doing” Agile mechanically. Second, there is a fake chasm, which many organizations pride themselves on having crossed by virtue of adopting some mechanical features of Agile, whereas they have not been willing or able to make the behavioral changes and adopt the values required to cross the real chasm. Although many companies say that they are doing Agile in some form, a large proportion of these are actually doing Fragile ("fake Agile") or some other hybrid variant that cannot deliver the business benefits of Agile.

I cannot overstate this point: many companies and their teams are mechanically doing some form of Agile without having actually crossed the Agile chasm, not discarding the behavioral baggage that is keeping them from behaviorally and culturally being Agile. Until a team attains the state of being Agile, the business benefits that Agile can provide will be elusive. I contend that the industry has barely entered the early majority of true Agile cultural transformation, and many companies continue to struggle to leap the Agile chasm.  What have you noticed across the Agile landscape?  Have companies crossed the Agile chasm?

Note: If you are looking for more insight in crossing the Agile chasm, consider reading the book Being Agile. This book lays the foundation for those who want to cross the Agile cultural chasm, understand the behaviors that need to change, and gauge progress along the way. It provides an Agile transformation roadmap to the destination of achieving better business results.

---

[1] Geoffrey A. Moore, Crossing the Chasm (New York: Harper Business Essentials, 1991).

You may be FrAgile if...

Moving to the Agile can be challenging.  It implies a behavioral change to the Agile mindset supported by the Agile Principles found in the Agile Manifesto. However,  many find themselves in the land of FrAgile (i.e., fake Agile), Scrumbut (i.e., we are doing Scrum but not some of the practices), Scrumfall (i.e., some elements of scrum within a waterfall lifecycle), and even Kantban (i.e., Kanban without respecting the queues). 

What is FrAgile? This is where there either isn't really a commitment to go Agile, there isn't an understanding of what "being Agile" means, there isn't the talent like an Agile Coach to help bring about that change, or an incremental deployment approach stalls along the way. And most importantly, frAgile is when Agile very quickly becomes brittle, lacking in vigor, and shatters once there is tension applied leading to a regression to past ways of working.    

When "Fragile" happens...

Some may ask, “why do I care if Agile is not quite right”.  When a form of Fragile is applied, you will not gain the business benefits of aligning better with customer value and the many other benefits Agile can bring. When you see that you are not gaining the business benefits of Agile, instead of blaming Agile, look to see how you have implemented Agile and whether you are really aligning with its values and principles. 

In honor of Jeff Foxworthy and his "You might be a Redneck if" routine, I thought I would adapt his saying to fit the Agile message of this article.  I present several areas which can be problematic if they are not in place and you are serious about Agile.  So without further ado, "You may be FrAgile if": 

• ...you do not want to hire or identify a Product Owner (or similar) who works with both the customers to gather requirements and Engineering team to describe the requirements in more detail.  The result is that there engineering will build what they think the customer wants and then you will wonder why the customer doesn't want it.  
• ...you continue to have the Project Manager or Functional Manager assign the work to the Team.  The result is that your team will not be self-organizing and you will wonder why your team members are not engaged.  
• ...you continue to collect your requirements upfront and lock them in for the remainder of the project.  The result is that you may build the wrong thing for the customer and you will wonder why the customers are not very excited about the release and few are buying or upgrading to it. 
• ...you do not want to have a healthy balance of test/QA minded folks on the team.  The result is that the testing activities will become the bottleneck or worse yet, the testing aspects will become watered down (i.e., skip testing steps), ergo releasing a product with low quality and subject to many defects.  
• ...you mechanically know how to do the Scrum and XP events and practices but can't remember any of the Agile values nor any of the 12 Agile principles.  

Let me know what you think about the results of "You may be FrAgile if".  If you believe there are other Fragile, Scrumbut, Scrumfall, Kantban, and other related Agile challenges that could be non-starters or significantly impact the ability to "be Agile", please feel free to share.