When Agile first started, it was a grassroots movement. A rebellion against the heavy-handed waterfall/project management processes that were common at the time. It was about getting things done and working more efficiently.
Fast forward to today: Agile has gone mainstream, and with that comes all the baggage and politics of big business. Some leading frameworks have emerged to bring Agile to the enterprise level. But is it really the best option for enterprises?
Leading Frameworks Misinterpret Core Agile Principals
One of the Agile principles is “the Agile team self-organises to determine how best to accomplish their work, rather than being directed by others outside the team.”
Leading frameworks eliminate this principle by specifying every role and responsibility on an Agile team in excruciating detail. There is no room for self-organisation when you have a prescribed process that dictates how everyone must work.
Another Agile principle is “responding to change over following a plan.” This means that if something comes up that needs to be addressed, the team should adjust their plans accordingly.
Leading frameworks go against this principle by having teams create extensive plans upfront before starting work on a project. These plans are then supposed to be followed to the letter, with no deviations.
The Agile principle of “working software over comprehensive documentation” is also disregarded by leading frameworks. In order to complete the release planning process, teams are required to produce a huge amount of documentation. This goes against the Agile principle of valuing working software over comprehensive documentation.
Theorists Are in Control with Leading Frameworks
Leading frameworks were created by people who come from a traditional business background. It’s not surprising then that it takes a top-down, command-and-control approach to Agile.
This might work in some cases, but it goes against the very principles that Agile was founded on. Agile is supposed to be about empowering teams and giving them the freedom to self-organise and make decisions. Leading frameworks restrict teams and tells them what they can and can’t do.
Leading frameworks introduce a lot of new Agile roles, like the Release Train Engineer and the Solution Architect. These roles didn’t exist in Agile before, and they just add more bureaucracy.
Agile is supposed to be about empowering teams and giving them the freedom to self-organise and make decisions. Leading frameworks favour bureaucracy which returns to the outdated mindset that an Agile team is a delivery function. The upper management makes the decisions, and the low-level teams just execute.
Leading Frameworks Add Gaping Holes to Agile Governance
Leading frameworks and dependencies do not mix well together because some of these frameworks are so rigid towards them. A dependency is something that your team must wait to be completed before their own work can commence.
If one team is working on a project and they rely on another team to deliver something, that dependency needs to be tracked and managed. But leading frameworks do not have a great way to do that. Following leading frameworks means there is an overabundance of planning, processing, standardisation, and lots of meetings.
All of the red tape and bureaucracy lead to Agile teams feeling frustrated because they are not able to move as quickly as they want. And when Agile teams are slowed down, it defeats the purpose of Agile.
Leading frameworks do not account for the fact that Agile teams are constantly changing and evolving. The framework is too rigid to change with the Agile teams, which leads to more frustration. There is less commitment to continuous improvement when compared to other Agile frameworks.
Since the decision-makers won’t be involved at the ground level, they won’t have the knowledge to benefit from retrospectives. As a result, the Agile team won’t be able to improve and will become stuck adhering to processes laid out by the theorists.
Leading Frameworks Forget About Culture
The Agile culture is all about collaboration, trust, and transparency. But leading frameworks go against this by having too many rules and hierarchies. When you have a lot of rules, it breeds fear instead of trust. And when you have hierarchies, it creates silos instead of transparency.
Leading frameworks don’t encourage Agile teams to experiment and take risks. In fact, it does the opposite by telling teams to play it safe. This goes against the Agile principle of “fail fast, fail often.” Teams learn by making mistakes, reflecting on things, and working together to figure out a solution for next time.
All of these factors lead to an Agile team that feels like they are being micro-managed instead of empowered. And when an Agile team feels micro-managed, it leads to them being less productive.
Follow your own path
Leading frameworks might work for some organisations, but it’s not the right fit for everyone. If you want to do Agile, maybe don’t play it safe.
If you’re going Agile, learn how to minimise risk by checking out this PMI article!
Contact us so we can help you create a straightforward, results-oriented framework that connects governance, delivery, and culture to help you thrive and organise.
If you’d like to engage Fatimah as a coach/advisor for your organisation to help you make sense of the chaos, then you can reach out to her by email at Fatimah.a@agilemanagementoffice.com