Recently I was reading a nice article written about a two-day seminar at George Washington University given by Dr. W. Edwards Deming near the end of his life and was inspired by the article to write an article about a similar subject. In the article the writer who was in the seminar for executives discussed Dr. Deming’s frustration with managers who refused to make factually based decisions and didn’t want to lead, at the end of the seminar Dr. Deming was pounding on the lectern asking the executives “where are the leaders going to come from”. This leads me into a similar subject that would have Dr. Deming if he was alive today pounding on the lectern again asking, “where are the leaders going to come from”. The subject is scaled agile frameworks.
I’m going to follow the lead of Dr. Deming and discuss factually why scaled agile frameworks are simply a way for management at large companies to duck out of their responsibility to be leaders and truly transform their companies.
While I have seen a few individuals willing to speak up about the issues with scaled agile frameworks, unfortunately most paper over them with some excuse such as well, at least scaled agile frameworks get the C-level people together with developers seated on the same table negotiating about what can be delivered. The reality is that scaled agile frameworks are simply a way for management to try and put off the comprehensive transformation needed and instead try and implement something they can label as “agile” while still having a traditional top down directive and no real change.
A couple of people willing to call out scaled agile frameworks for what they really are is Steve Denning and Jez Humble. In his article “For Agile, It’s The Best And The Worst Of Times” Steve Denning makes the following statements.
“In some cases, Agile is being implemented as a superficial patch on traditional management. The underlying management hasn’t changed.”
“As “scaling Agile” becomes the fashion, rather than descaling complex problems into manageable pieces of work, scaling frameworks are being sold that are in some cases just another name for bureaucracy.”
“For all the talk about Agile, only a small percentage—less than 10%— of Agile implementations are fully Agile in the true sense of the word.”
Jez Humble in his video “Why Scaling Agile Doesn’t Work” discusses the problem with scaling agile frameworks from the perspective of common organizational obstacles to moving fast at scale: governance, budgeting, and the project paradigm.
So, what is the real problem with scaled agile frameworks? If some of these scaled agile frameworks would have just remained as another methodology such as Scrum or Kanban trying to sell themselves as a means to implement Agile they would have probably been fine, but instead they have tried to sell themselves as more of a comprehensive transformation framework even though they don’t deal with the most fundamental transformation components. Below I will discuss just a few of the holes in scaled agile frameworks in terms of their short comings from a transformation perspective.
If we look at the readily available research on organizational change (yes, Agile is a change project) we see that historically 70% of all change projects fail due to one simple reason. The reason for this failure is that the management fails to deal with the corresponding organizational transition that must occur in order for the organizational change to succeed. If we take a look at Agile and even DevOps we see the failure rate is around 90%, this should be alarming to everyone. We need to understand that an organizational transition has three distinct phases that need to be dealt with, but unfortunately most scaled agile frameworks don’t even acknowledge the organizational transition that must occur.
Another component of transformations that we need to acknowledge and deal with is the culture change that needs to occur. If you listen to some of the companies worldwide who can be said to truly be doing Agile/DevOps they repeatedly discuss not only how they had to change their culture but how they had to start measuring it in order to make sure the culture was headed in the correct direction. We also need to look at research, which shows us that measuring culture is every bit as important as measuring ROI or Sales. If we look at the research on the DevOps side, we see the following from Gartner’s research – “90 Percent of I&O Organizations Attempting to Use DevOps Without Specifically Addressing their Cultural Foundations Will Fail” The way in which we measure our culture is through cultural surveys using various models such as the Westrum Model. Again, if we look at scaled agile frameworks we see that they fail to acknowledge the need to measure the culture on an ongoing basis.
If we look at some of the scaled agile frameworks we also see that as part of their sales pitch that they are a transformational framework they have added a box called DevOps. The problem with this is actually larger than the scaled agile frameworks, it is a problem in general with many in the Agile and DevOps communities. The issue is that there is a revolution occurring today and it is bigger then Agile or DevOps, it involves among others Digital, Big Data and even AI. If we look at some of the work of Gene Kim, we see that he does a great job of explaining this by comparing what is happening today with the Lean Manufacturing Revolution of the 1980’s. What this means is that Agile and DevOps are not in separate lanes but need to be pieces of the transformation as a whole. This means that scaled agile frameworks and others need to acknowledge that the transformation that needs to occur is bigger than their frameworks and be up front with companies about this. The bigger point here is that the Agile and DevOps communities need to come together and understand that they are just pieces of the transformation and not sperate change initiatives.
Another critical missing element of scaled agile frameworks is Learning. If we are honest and really sit back and evaluate what it is we are really doing with Agile or even DevOps, it’s about companies moving towards becoming continuous learning organizations. We need to be very clear that to move towards becoming a continuous learning organization is much bigger than any scaled agile framework and needs the components from DevOps and others. The first thing we need to remember is that organizational learning occurs though individuals, the more individuals learn the more the organizational learning as a whole increase. This leads us to question why many pushing scaled agile frameworks are not pushing companies towards models we see emerging on the DevOps side like the move towards autonomous teams in flat organizations using the squad and tribe model for example. In addition, we need to also acknowledge that Agile requires individuals to develop new skills, both hard and soft skills. We would normally use something like a learning map to determine the new skills that individuals would need. This is why you see some doing DevOps incorporate HR early in the process, so they can identify the new skills that will be needed. In most cases with organizational learning you would want to assess where the company is currently with learning and then put into place a plan to increase organizational learning. The problem with scaled agile frameworks is that they seem to believe this will somehow magically occur.
The last area I will discuss is the lack of recognition by the scaled agile frameworks of the importance of growing the grass roots efforts in an organization attempting a transformation. We know from research on the DevOps side that the majority of successful DevOps attempts have started as grass roots efforts and this holds true in most change projects of this nature. While we know that at some point to truly transform an organization we have to scale the transformation, it can not be understated how important it is for organizations to allow the grass roots effort to flourish prior to the scaling attempt. Of course, we also know from research that the majority of organizations are not very effective at growing grass roots efforts, but we still need to start the grass roots in order to start changing the culture, breaking down silos and instilling concepts such as Agile and MVP. A great example of this is what occurred at Target on their transformation journey.
There are a number of other holes in scaled agile frameworks we could discuss such as the need to understand the role sciences such as organizational behavior/development play in the success of Agile and DevOps or how traditional change tools should be used when you get the C-Level management together with developers, so we can truly surface the underlying issues in these companies that are going to serve as roadblocks to a true transformation. We’ll save all these for another day.