In today’s blog, let’s dive into the limitations of agile frameworks and when they are useful. I’m going to be considering some of the more famous agile frameworks like Scrum, because let’s be honest, most agile frameworks are based on Scrum.
To start things off, let’s make sure we are on the same page of what frameworks are:
Frameworks frame the work, give steps, provide a structure for something (activities, tasks) to be executed.
Agile Frameworks are not useless or wrong, they have a place. The issue is that they’re just not enough. That being said, some frameworks are better than others, but by better, I mean more useful, precise, and fit for the context.
The problem then arises that the more complex the framework, the more difficult it is to adopt. So, you can start to see why people start to complain about frameworks like SAFe, although it has many benefits at the organizational level, and why people tend to love the simplicity of Scrum. But while simple is better, you shouldn’t be simpler than you need.
Watch my mini-class on the limitations of agile frameworks here:
The limitations of agile frameworks
1 – Too generic
Whether you’re talking simply about Scrum or the versions we have that are at scale, they may work, but they have limited power. Their ability to appeal to everyone is their limitation.
Technically, you can try to use Scrum to try to solve world hunger or a logistics problem. But should you? No! They are totally different problems with different strategies to fix them. With a logistics problem, you need lots of control, clear signals for synchronizing, and problems are solved in a continuum. They are complicated, but this is a domain full of well studied, highly specialized, mathematical models you can use.
In contrast, world hunger is not a straightforward problem to solve. You will need to probe, adapt, and then probe some more. You can try to put deadlines on this problem but you will blow every one because there are too many different levers to use. Although these are extreme examples, they show how completely different approaches are needed to solve different problems effectively.
2 – No management blueprint or focus
Frameworks can make “management” seem like a bad word, but managing the work, the flow, intake of requests, is what saves the day. It’s the bread and butter of organizations, operations, and innovations. There is no such thing as a million dollar idea, only a million dollar execution. Managing a project towards success truly depends on how you handle patterns of execution.
However, none of the famous frameworks connected to agile are concerned with that. They don’t offer anything to deal with this management. Real life happens in the gaps of what is offered in these frameworks. When a new request comes in after you’ve planned your sprint, do you take it or not? How do we decide? When do we decide? Current frameworks don’t give you clear instruction or insight about what to do, but this situation is a very common one. That is where management comes into play.
3 – Myopic team focus
Scrum started with a strong focus on the individual team and people have tried to scale it since. A company will always deal with inter-team, interdepartmental issues, dependencies, and solutions. Unless your company has a clear deficiency that happens only in a specific team that needs to be refactored, it is irrelevant to do tiny team adjustments.
Can teams improve things on their end? Absolutely, and they should. But it’s not uncommon that the team that uses Scrum feels they cannot advance because the rest of the organization doesn’t follow it. It’s great for your team, but as you evolve you think everybody else in your organization needs what you need, which more often than not, is’t true. You have a myopic, near sighted view that is your team.
4 – Lack of management buy-in or support
The above limitations of agile frameworks like the focus on the team, and no blueprint for management end up bringing many leadership teams to think that agile is just a thing that the team does and that they don’t have to do anything different. It is easy then to look at the work of a manager and say that they use obsolete approaches. Many of them do! But, no famous agile framework is offering concrete frames around new forms of management that can occur.
A lot of techniques, science, and knowledge around these things do exist, but none of that is incorporated in the famous agile frameworks. Managing in agile is actually about knowing and identifying effective and ineffective patterns of execution to correct the issues you encounter.
5 – Lack of technical and domain specificity
For the most part, there is a huge space for technical excellence no matter what your technology is. But, the domain matters in the technology we use to do our work. Whether you are in marketing or healthcare, you are using some kind of technology. Even within tech, a company developing an app will use different tech than a crypto company.
Yet, mastering the means of your production is usually what can accelerate and pave your way to better productive services. No amount of enthusiasm and collaboration creates solid, scalable, maintainable, reliable products. It’s a hard pill to swallow, but look at the state of agile and the decline after this huge agile transformation as a result of a lack of concrete results and higher ROI. I don’t remember seeing a lot of conversations about the technical aspects of how we produce what we produce.
Feedback plays a key role in frameworks and sprint reviews are probably the archetype of this feedback, especially as far as products go in scrum based frameworks. Understanding your technology can help you use a variety of forms of data collection to understand how people use your product. You could be collecting these insights more consistently, outside of only sprint reviews, allowing you to better serve your stakeholders. But how many coaches are prepared to start having these technical conversations? Maybe not many, but it is required.
6 – Not personalized to your culture, context, or problem-fit
One of the biggest limitations of agile frameworks out there is that they are one-size-fits-all. They try to sell to most people and don’t acknowledge the differences around context, or the if, then, else. What do you do if you can’t adopt a practice? How do you decide what to change without losing the overall benefits? The frameworks don’t address this.
As an example, think about a huge company like General Electric compared to a small start up. Do they have the same context? Definitely not! Some companies work internationally with peers in different cultures, time zones, and ways of working. How do you offset this? No agile frameworks tell you how.
7 – Over reliance on collaboration
Most agile frameworks were created to rely on collaboration, but, while this one may be a bit controversial among coaches, you don’t need all work to be collaborative. It’s important to understand if collaboration is not how your work or your culture is structured, you don’t have to change it to succeed. In fact, even if you are collaborative, it is important to have an equilibrium because everyone can’t do everything together all of the time.
If how you develop your product has worked wonderfully so far and you just want to scale, don’t ruin what you have to fit into a framework and collaborate. An example of this is how NASA works. They have a few teams of highly technically skilled people that they bring in depending on the issue at hand. They put people into context quickly and produce results quickly. This is very different from the “must collaborate all the time” approach and it works for them. Constant synchronization and collaboration can be very difficult.
Using a prefabricated framework is just like buying clothes ready-to-wear: It fits some people better than others and for some people won’t fit at all. And that’s okay. The best clothes you’ll ever wear are tailor made to your body, your taste, and your budget.
Where and how famous agile frameworks can still be useful
If you don’t use one, you don’t need to! But if you do, you don’t need to undo the changes you already have.
1 – Easy way to “taste” agile
Frameworks are a fantastic entry way to agile if you have no basis. Whatever framework you get, it gives you some place to start. It is easier to critique what you don’t like than have to invent from the get go.
2 – Small organizations with Scrum
For small organizations, scrum does work wonderfully. It can produce great results.
In fact, scrum was invented for teams, and that’s where they produced its good initial results. It’s surprisingly generic for bigger organizations, but if your team is small, collaborative, and ideally collocated, chances are you’ll be positively surprised in using it.
3 – Specific needs such as eXtreme Programming and Disciplined Agile
As soon as you start getting more specific, you start to get better results. eXtreme Programming and Disciplined Agile are both for agile software development. People either love or hate them. It’s a matter of taste. But they do offer much better results for software development than say scrum.
The key things is that those more specific frameworks will tell you how to structure the planning, the management, & even the technology practices around. It was, in fact, what brought a lot of the early success in agile frameworks. Then scrum made it a bit more flaccid, to appeal to more general audiences.
In Conclusion
The existing famous agile frameworks can provide some insight into gaining agility, mostly for teams. But they are limited in what they can do for your organization, since your context is unique.
The best agile framework will always be the one you create tailored to your specific context, your company culture, your types of work, and your business needs.
So yes, you can and should create your own agile framework. We’ll be talking a lot more about how to do it in upcoming posts.
If you are interested in growing your agile skills, other than the blog and videos, consider joining the newsletter Agile Circle. It’s totally free, and you’ll receive insights in your inbox, be invited to events and workshops in our community of practice, The LAB of All Things Agile, and get first word in discounts for our paid programs and coaching.
