I recently came across a particularly insightful articles written by Sanjay Zalavadia of Zephyr. In the article, Zalavadia explains that while agile has by and large proven a major benefit, it affects businesses differently depending on their size and how they integrate the methodology into their operations.

Zalavadia provides eight common causes which adversely impact the agile development process in large enterprises:

1.  Lack of Clarity

Large enterprises often include big teams that may consist of remote members. Under agile strategies, it’s important to have everybody involved in the project collaborate. So if remote workers aren’t able to easily communicate, it will be difficult to contribute.

<< Level Up Your Agile Game! Beware of DevOps Misconceptions As You Master These DevOps Best Practices! >>

It’s also important to select an agile project management tool that provides clarity for the whole team (especially when it’s a distributed team) and the managers.

2.  Continual Reliance on Legacy Methods

When you transition to agile, it requires a significant shift in culture. However, some teams still use waterfall and other legacy strategies for certain operations, which can explain why half-hearted agile projects falter.

A lack of managerial support and unwillingness of teams to fully embrace agile are some of the main reasons that agile projects fail.

3.  Inadequate Experience with Agile

Possibly the biggest reason why agile projects falter in large enterprises is the fact that people just don’t have experience with the methodology or how to integrate it. For this reason, organizations should create a game plan and provide experience through pilot programs and coaching. Managers should also be included in the training because their roles and responsibilities will change radically when using agile.

4.  Lack of Collaboration in Inter-Company Teams

Another problem (related to the first)  is the lack of collaboration within teams composed of members representing different subcontracted organizations. In this context, the team is not really a team, sharing the same objectives and the same plan.

CollaborationThere is not one cooperative gameplan but many, each with its own objectives. Team members need to respond to project objectives as well as those put forth by their own organization. This creates an environment vulnerable to asynchronicity; where conflicting or totally unrelated goals can be pursued in the name of the same project.

5.  Lack of Testing Strategy

The role of the tester changes and so the required skills to fulfill this role, equally changes. Testing needs to be done iteratively over features that, looking at them with an old fashion mind, are not fully completed.

Moreover, regression testing is needed to continually assure that already built features keep working. It is clear that this implies deep changes for quality assurance teams.

6.  Lack of Alignment with Other Areas of the Enterprise

It is very common in large enterprises that, while some departments or teams work according to agile methodologies, others do not. The problem arises when these areas need to interact.

When an agile team needs something from another group during an iteration, and that other group works in a different way, has a different schedule, or doesn’t understand the involved dependencies between teams, there’s a problem. It’s a common error in big enterprises to think that this interaction will be possible and will work smoothly. In many occasions, it doesn’t.

7.  Larger Teams and Big Pyramid Structures

It’s clear that teams should be approximately the same size regardless of the size of the enterprise, with the ideal number hovering around seven team members. However, it is often the case that the number of teams working together end up being larger than what is really needed for the project.

This could happen because of the restructuring of teams, because pyramid hierarchies tend to engender bigger teams, because of culture or simply because large enterprises have many employees. The problem is compounded when  team members are only partially assigned to projects, as their commitment isn’t the same.

Of course, there’s also the problem of middle managers that participate in the project from an even more external perspective. The price to pay for overstaffed teams is having more complexity, larger meetings and lowered productivity.

8.  Not Changing the Objectives

Radically changing the development approach should encompass changing the performance management objectives of the organization, if they’re not already aligned. Otherwise, the development team would be working against one set of objectives while the management team against another.

Also, consider the impact of individual performance metrics on teamwork. It’s important to measure the team on overall outcomes, not individual activity.

Excelling Where Others Falter: Putting It All Together

Large enterprises that are undertaking an agile transformation should learn from the many other companies that have already gone down this path.

Agile can take time to get right, but by understanding the challenges other organizations faced, they can take these lessons into account for their own strategies.

This perspective and its corresponding approach will help businesses plan better for their transition to agile operations and boost their chances of successful projects.

Do you know these 10 things? Check out our agile development infographic.