Agile has become a popular buzzword in the IT industry, and many companies try to integrate this methodology into their processes. This includes enterprises who dream of being “the next Spotify” – the music streaming giant is one of the examples of successful Agile implementations in a truly large organization.
However, in reality, things aren’t that simple. While Agile practices work great in a small or medium company, scaling them to fit an enterprise-grade business can be problematic. You can encounter many issues, and in this article, I’ll analyze some of them based on my experience with large IT projects for such companies.
Image source: Pexels.
Before we focus on problems, let’s first define the advantages – the reasons why you’d want to use the Agile methodology in a huge business in the first place.
Image source: Pexels.
As you can see, there are several significant advantages to consider. However, the Agile methodology wasn’t created with corporations in mind, and there are some issues you can encounter while scaling it to the needs of such organizations. What are the problems?
Some companies see value in the buzz around the Agile methodology and only implement it to brag about it on their websites and social media channels (or even to have something to blame bad decisions or inefficiency on). In such cases, the management tends to ignore the framework’s rules whenever it suits particular goals – which, obviously, means it doesn’t work well (or at all).
For example, sometimes managers delegate ad hoc tasks, ignoring the fact that a sprint was already planned. It means developers must stop what they’re doing and focus on something completely different. It’s very inefficient – it’s pretty likely the developer won’t finish the original task, possibly creating problems for other team members involved in the same sprint.
There are also cases when companies go the opposite way and treat the rules behind the Agile methodology as untouchable. It’s not an optimal approach either. Agility is all about being flexible, so bending or changing a few rules to suit your company’s nature better is not only acceptable but recommended.
For example, what’s the point of having developers on all of the meetings, even ones outside of their specialization?
Another case is creating teams that are too big to be Agile (like 30+ people strong), but still expecting everyone to take part in meetings. In some scenarios developers spend only half their time working on software, and half on attending meetings – which, I’m sure you’ll agree, really isn’t optimal.
Adherence to Agile rules is fine, but if you’re gonna be strict with them, do it on all fronts (like the team size) – otherwise you’re bound to create problems.
Your company’s new organizational structure should align with the requirements of the Agile framework and your specific needs – and not the individual interests of managers.
For example, in one of the projects I was involved in, during the transition to the Agile methodology, the management created too many tribes because they wanted to give every manager a similar job they had before, and didn’t want to fire any of the management staff. It wasn’t an optimal choice in terms of effectiveness.
It’s also important to understand that not every person is well-suited for Agile methodology. It requires a particular mindset. It’s one of the reasons why it’s so important to have people in all the teams and tribes that understand the framework and can guide others who don’t operate in it as well as them.
The Agile methodology can make coordination difficult in enterprises with many teams or tribes that work on the same project portfolio simultaneously. The teams tend to focus on tasks outlined in their sprints, which aren’t always well-aligned with other teams’ responsibilities. You can avoid some problems with good planning, but it isn’t always possible.
Numbers, predetermined budgets, calculations, etc,. are crucialin corporations. Setting the price for a project may be challenging if you work in the Agile framework because the scope of work fluctuates between sprints – sometimes a lot. The price is influenced by the time and scope of the project, and these are 2 factors that are variable when working on sprints. It means the initial estimates may differ substantially from the final costs. Managing project finances in an Agile environment requires flexibility and continuous tracking to stay aligned with evolving scope. However, I can tell you from experience that such estimations aren’t entirely impossible if you have a well-planned and detailed backlog.
Another factor is the existing architecture. Using the Agile framework will be hard if it’s really complex or problematic (e.g., so-called “spaghetti architecture”). Organizations based on domain microservices are easier to work with because you can separate teams responsible for one domain and the delivery of one specific part. Also, in the case of some legacy technologies, it may not be possible to technically separate domains and divide work on them into specific teams.
Most companies have some kind of assets – often employees – considered rare. For example, in a bank, these can be specialists who use the transaction system, and in a telecom company, people who take care of billing. It may be difficult or impossible to build multiple teams with equal access to these critical assets, creating bottlenecks – sometimes a team will have to wait before they can progress with a task because they can’t get the help they need in a given moment.
Image source: Pexels.
Thankfully, there are some things you can do and tips you can follow to make the Agile framework more suitable for an enterprise.
To find even more good Agile-scaling practices for enterprises, you can check this article on The New Stack: Principles of Good Large-Scale Agile.
Is large scale Agile a good idea? It really depends on many things, such as the nature of the company, and the mindsets of its employees. Speaking from my own experience, I can say that one of the most important things to consider here is the kind of projects or work you do. The Agile methodology works well when you have a specific product you want to develop and maintain – or even a few of them. However, if you focus on more general R&D (research & development), you probably won’t get as much out of it as you hope. An alternative methodology to Agile could be Lean, especially if the emphasis in the enterprise is on process improvement and waste reduction. In this article on Lean Methodology you can read more about its benefits.
Consider your company’s actual needs, and don’t look too much at the example of other organizations because you don’t have a guarantee that you’ll achieve similar results. If you do choose to “go Agile” make sure it’s not just for show, and plan the company’s structure and leadership accordingly. Have someone who has a bird’s eye view of your organization and can point out some things that may not be obvious to people inside it. Finally, stay flexible and change things if you deem it necessary. After all, this is what agility is really all about, isn’t it?
And if you want to capitalize on some of the Agile framework’s advantages, but without turning your entire company on its head, consider outsourcing your project to an outside team who can work in this methodology. At Pretius, we have many such experts, and we always provide top-notch project management. Write us at hello@pretius.com or use the contact form below – we’ll get back to you and tell you what we can do to help.
Some people believe that Scrum can only be successfully used in one team and isn’t suitable for larger projects. It’s not true – the framework can be scaled.
Yes, there are some large scale Scrum frameworks you can use such as LeSS.
It depends on the particular framework. For example, the rules of the Large Scale Scrum (LeSS) framework advise to up to eight teams (specifically two to eight teams).
A Product Owner is a member of a Scrum team responsible for the final outcome of the project – the product itself.
