You are currently viewing Why do scaled framework implementations feel like waterfall?

Why do scaled framework implementations feel like waterfall?

I was recently on a call with agile coaches worldwide for the Agile Alliance Coaching Network, and a discussion started brewing from a question that a participant asked. The question was, “We adopted one of the large scaled frameworks, but it still feels like we are doing waterfall. Is this supposed to be how it feels?”

Want to add a caption to this image? Click the Settings icon.

Many of the participants agreed that most of these frameworks are actually “waterfall in disguise”, and you can see many writings on the internet and books on the subject. Furthermore, we pointed out that agile is a mindset, and when you start implementing one of these framework that you are in fact implementing a top-down (bureaucratic) approach.

Agile is about creating customer delight. and working with self-organizing, autonomous teams in short cycles, and where the organization is working like a fluid network.

So, is it really the framework? One opinion was that if it feels like waterfall, then it is probably those who are involved with the day-to-day activities that are feeling this way. Perhaps we are coming from the whole manufacturing attitude where managers want to get involved without “working on the shop floor”, and that is why these managers are asking for frameworks.

Agile is also about creating the simplest thing that can possibly work, and so when we create these frameworks we are creating something that, in the end, will become something that is very large.

So what about the size of the organization? Does a framework start to feel waterfall-like because it starts to push against old structures? If so, how can it feel less waterfall? When asking this question, one should remember that an important quality of agile is the fact you have an opportunity to improve with regular retrospectives, so that an organization has an opportunity to learn something from the previous iteration. This type is setup is not for everyone, however, there needs to be a check for the reasons behind needing all this overhead. Perhaps a sense of security or trust is needed. In any event, assume best intent, but there needs to be some reasons for not “letting the teams go”.

Another point that was brought up is the need for organizations to adapt to changes that come about. This applies to the teams, but also managers in the way they manage teams, departments that partner with IT and others, etc. An organization that can change to interact with others in more efficient ways will succeed better than those that follow a framework like scripture.

A common interpretation from managers and leaders of agile might be that it is a threat to the control that they are accustomed. A common, natural, response to that threat is to have these structures, checks, systems, assessments, processes, etc.. A way that we can get through this feeling of being threatened is to build a culture of transparency, learning and trust. That’s all great, but how do you go about coaching an organization to build this trust through transparency? Simply making our work visible and available to those who are interested in it is a great start to break down these barriers. Simple tools like whiteboards or even electronic tools can accomplish this transparency. It’s definitely uncomfortable to reveal strategies right away because these are usually kept close to oneself, but the way to build this trust is to have the willingness to make your work transparent.

One important point to remember is that if you are thinking of scaling agile, you are already thinking of things the wrong way. In a large organization, you should be thinking about de-scaling big problems and breaking them up into small pieces. If you are trying to build up large teams into a already huge structure, then eventually you will come to some kind of difference.

Note that one thing that scaled frameworks do uphold is the need for teams to be on the same cadence to integrate all work. Integration is one step that is commonly and incorrectly ignored when implementing frameworks, because in the past, integration was not necessary since thinks usually came together nicely. If you ignore that need, then you are setting yourself up for bigger problems. Data has shown that successful agile implementations are seen in those organizations that grow agile organically, that is, start with small teams, get support from the top-level of the organizations, and eventually embrace handling larger efforts that are more comfortable to the organization using terms that are familiar to the organizations. Call it agile, call it something else. What is important is that the implementation is in the spirit of agile. Another important note with that statement is that before an organization rules out a particular implementation, spend enough time on the looking at the mindset rather than looking at the methods or details of doing the motions of a framework correctly. If you are using the same methods over and over again and its not working, then you are possibly not as agile as you think.

After I got off the call, my feeling of frameworks had not really changed, however it was actually strengthened by others on the call. Agile, in any sense, is an mindset, and frameworks should be treated as such and nothing more. In essence, frameworks are just “suggestions”. They are a set of guardrails that have worked for others. No framework tells you how to be agile. The whole point is that you must experiment with the right framework according to how your organization works to truly become agile and create a growth mindset.