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.

Large scale Agile development – advantages

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.

• Project transparency and predictability – if you plan ahead and create a master backlog – which is pretty much necessary – you can achieve good project transparency/visibility. It helps the entire team and/or company understand the scope of the project and the tasks that need to be completed
• Great time-to-market – well-implemented Agile methodology allows you to boost time-to-market substantially. For example, during one of the projects I know about, three teams worked on a solution at the same time, which essentially translated into around 2,5 times faster development time
• A better solution – when you have several teams that work on pieces of a solution, you can iterate, fix problems, and make changes as necessary much more quickly and efficiently. In the end, it often means your IT solution will be better
• Lower risk – since you can easily make changes as the project progresses, you can adapt to the changes in technology, scope, requirements, etc. It means there’s less risk of delivering a suboptimal or unusable product or solution
• Better alignment – thanks to the focus on self-organizing and good, frequent communication, the Agile methodology helps boost internal (inside the team or company) and external (with the customer) alignment

Why agile methods may not be suitable for large companies? Here are some common challenges

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?

Ignoring Agile rules

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.

Too strict approach to Agile

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.

Focus on individual interests

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.

Wrong mindset and company organization

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.

Problems with cross-team projects

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.

Pricing evaluations

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.

Legacy technology and convoluted architecture

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.

Issues with rare assets

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.

Scaling Agile for enterprises – good practices

Thankfully, there are some things you can do and tips you can follow to make the Agile framework more suitable for an enterprise.

1. Create transparent and logical processes – so that everyone understands how they are supposed to operate. One way to achieve this is by conducting daily standups to ensure everyone is aligned on their tasks
2. Create a “master product backlog” – to have an overview of the whole project and make it easier for “cross-functional” teams to perform tasks and understand at what stage other teams are. Constant product backlog refinement is essential
3. Plan the company’s structure correctly – consider which processes and structures will work well in the Agile methodology (for example, divide your departments into smaller subdivisions, and think beforehand about their integration). Focus on transparency, both when it comes to roles and processes. Also, try to decentralize decision-making whenever possible
4. Ensure strong leadership – at first glance, it may seem contradictory to the previous point, but it really isn’t. With many decentralized, autonomous teams in a large organization, someone must have the last word when conflicts or differences arise. This person needs to have a strong focus on the project’s well-being, and enough authority and personal charisma to enforce their decisions successfully. However, this leader must also understand the Agile framework and be willing to work in such a structure, respecting different teams’ autonomy and intervening only when necessary
5. Create and support a collaborative culture in the company – break down silos, eliminate misunderstandings, support constructive criticism, choose the right team leaders, and improve communication between them and employees
6. Focus on short sprints – during sprint planning, focus on shorter periods. This will allow you to introduce changes before the consequences of mistakes become too severe and, for example, affect another team
7. Introduce the Agile methodology gradually – don’t do everything at once. Start with a few tribes/teams, then divide them into further ones, ensuring each has several people well-versed in the Agile ways
8. Support the development of Agile competencies – train your employees and help them understand Agile methodology. It’ll allow them to be more effective
9. Get outside help – in many cases understanding on the individual or small team level won’t be enough. You need someone who can see the entire company and project from a perspective and can point out things you won’t be able to notice. Often, the best way to achieve this is by hiring a consulting agency (note that it doesn’t have to be one of the major players). If you do so, ask the company to help not just during the initial Agile implementation but throughout the entire project, so that you’re not left without guidance at a critical moment. Introducing the framework is not enough – your people need time to learn how to use it in practice
10. Adopt a customer-centric approach – considering customers’ needs helps guide the product or solution in the right direction. Focusing on the users’ perspective allows teams to see what’s truly important, which means they can better capitalize on the advantages of increased agility (the Agile framework makes introducing changes easier, and customer centricity ensures they’re the right changes)
11. Verify Agile maturity and don’t be afraid of change – you should frequently verify your company’s agile maturity level. It’ll allow you to verify how effective the methodology is in your organization, and give you some idea of things you can do to improve
12. Make use of feedback – you can use it to both shape project milestones, and facilitate continuous improvement of Agile-related processes
13. Use specialized Agile frameworks – you should also consider using one of the specialized Agile frameworks for enterprises, such as Scale Agile Framework (SAFe), Large Scale Scrum (LeSS), or Disciplined Agile (DA)

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? Pros and cons of Agile methodology for enterprises

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.

Large Scale Agile FAQ

What is single team Scrum?

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.

Is scaling Scrum possible?

Yes, there are some large scale Scrum frameworks you can use such as LeSS.

How many Agile teams should a company have?

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).

Who is a Product Owner?

A Product Owner is a member of a Scrum team responsible for the final outcome of the project – the product itself.