Agile software development has proven to be a major benefit to various teams, but it can affect businesses differently depending on their size and how they integrate the methodology into their operations. Although agile can yield significant advantages, the journey is not always easy. In fact, in a survey by Dr. Dobb's Journal, 68.6 percent were involved in a project that they knew would fail from the start. However, agile projects found a 71.5 percent success rate, compared with only 62.8 percent of traditional methods. It's important to understand the root cause of these problems in order to better prepare your own organization for agile projects. In this article, we explore some common areas which impact the adoption of agile development process in large enterprises:
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.
In an interview with StickyMinds, Leading Agile president and CEO Mike Cottmeyer noted that one of the most common challenges is forming complete cross-functional agile project teams and ensuring that these groups are able to clear backlog.
"At scale in larger organizations, it's incredibly difficult to find a pattern that allows teams to be able to come together and stay together and be held accountable and establish stable velocity and all that kind of stuff," Cottmeyer wrote. "We look for places to align business process and technology and teams into these units that can ultimately become agile teams and become more loosely coupled from the rest of the organization."
Teams can be brought together through the clarity of information sharing. Whatever tools are chosen must bolster this significant asset. These types of resources will better support agile development efforts.
It is 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 that need information about the progress. Of course, it's a plus if this tool can be integrated with the agile test management tool.
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 lead to agile failure. According to the ninth annual State of Agile survey by VersionOne, 42 percent of participants noted that their company culture was at odds with core agile values, and 37 percent felt pressure to follow traditional waterfall processes. To make things worse, participants cited lack of management support and unwillingness of team to follow agile as reasons their agile projects failed.
Since agile entails considerable changes like faster release cycles and continuous development, having resources and support is critical to its success. However, as the survey revealed, 44 percent of respondents cited that ability to change organizational culture as the biggest barrier to further agile adoption, while 32 percent believed pre-existing rigid/waterfall frameworks are to blame.
"We know that agile is first about ‘how you think’ and then about 'what you do,'" Agile Alliance wrote in response to the VersionOne survey. "If your organization's culture is either ignorant of or outright hostile to agile principles and values, the prospect of success beyond isolated pockets of agile teams are slim. Understanding that agile impacts organizational values and facilitating that transformation is the first step to having a broader adoption of agile, and more success with agile as a means to successful delivery."
Inadequate experience with agile
Possibly the biggest reason why agile projects fail in large enterprises is the fact that people just don't have experience with the methodology or how to integrate it. In fact, it was the top cause of agile project failure, cited by 44 percent of participants, according to the VersionOne survey. For this reason, organizations should create a game plan and provide experience through pilot programs and coaching.
In his interview, Cottmeyer noted that enterprises often try to take small projects within a larger context or transform large projects into agile initiatives. However, without the adequate knowledge, chances of failure in these cases are much higher.
This is a really important point that is often underestimated in many Agile transformations. How do roles change within this new approach to developing software? What does it mean to work in iterations? By training the many roles which come into the formation of cross-functional teams, they will be better able to leverage agile testing methodologies and ensure that their projects succeed under the new approach.
Managers should also be included in the training because their roles and responsibilities will change radically when using Agile. They need to understand how self-organization works and how to set up an environment where self-organization can thrive. They also need to understand the new metrics they should be considering and how to obtain them.
Lack of collaboration in teams composed by different companies
Another problem, which is related to the first described problem, 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. There is not one cooperative game but many games and the different games have different objectives. Team members need to respond to project objectives as well as those put forth by their own organization. However, the latter may not be aligned with the goals of other subcontractors working on the same project. To make matters worse, in many occasions a company is subcontracted to fulfill all positions in an area of expertise (e.g. subcontracting a company to do the testing). As we all know, quality is the responsibility of the whole team, but when there are disagreements, it is between the areas of expertise and the companies.
Of course, this is not a problem of Agile per se, but in Agile environments where short iterations during which all members need to interact and actively collaborate this can become a major problem. In this context, building a team that shares the same objectives and where members really collaborate is a major challenge, and we know that effective collaboration is important to project success.
Lack of a Testing Strategy
One of the most misunderstood areas in Agile transformations is how testing is performed. 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.
Failure to understand this is a major cause of disappointment in many agile transformation endeavors. As stated before, adequate training for QA personnel and the selection of a good agile test management tool is of utmost importance.
Lack of alignment in other areas of the enterprise
It is very common in large enterprises that, while some areas work with Agile methodologies some others do not. The problem arises when theses 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 and does not understand that by not providing what is needed, the Agile team won't be able to complete the work for which it committed, there is a problem. It is a common error in big enterprises to think that this interaction will be possible and will work smoothly. In many occasions, it doesn't.
Modifying the structure of the teams should be the long term goal. As Mike Cottmeyer says in the forehead mentioned paper "True Agility is about breaking dependencies across the entire organization". In the meantime, aim to get business units aligned and ensure that managers of areas not working with Agile understand the implications of interacting with teams that do work in the new way.
Larger teams and big pyramid structures
It is 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 structures tend to induce the creation of bigger teams, because of culture or simply because large enterprises have many employees. The problem gets even worse when those team members are partially assigned to the project as the commitment is not the same. Added to this, there's 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.
Another situation that teams in larger enterprises need to deal with is having many bosses inside the team. While Scrum encourages the team to self organize and each team member to be brave and help decide what is the best task they can collaborate with, having a boss inside the team (e.g his development tech lead or architect) discourages it. Innovative teams have flat structures and more often than not, this is not the case in large enterprises.
Many large enterprises, of which the most relevant one may be Amazon, are organized into autonomous teams no bigger than 10 members. Amazon called this rule the "two-pizza team" as the ideal team should be small enough that its members can be fed with two pizzas.
Not changing the objectives
One of the points that Jim Highsmith makes in his Agile Project Management book is "If change, adaption and flexibility are the trademarks of agile projects and conforming to plan is the trademark of traditional projects, then why do we still measure success on agile projects using the traditional frameworks?"
Radically changing the development approach should encompass changing the performance management objectives of the organization if they are not 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 measure the team on overall outcomes, not individual activity.
Conclusion
Larger enterprises often deal with bigger and more complex problems than small ones. They have more employees, subcontracting companies, different business units, more processes and a strong culture that defines how things are done. At the same time, they need to be able to deliver results in an ever-changing business environment. They need to be Agile.
Large enterprises that are doing 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 will help businesses plan better for their transition to agile operations and boost their chances of successful projects.
About the Author
Sanjay Zalavadia is the VP of Client Service for Zephyr, Sanjay brings over 15 years of leadership experience in IT and Technical Support Services. Throughout his career, Sanjay has successfully established and grown premier IT and Support Services teams across multiple geographies for both large and small companies. Most recently, he was Associate Vice President at Patni Computers (NYSE: PTI) responsible for the Telecoms IT Managed Services Practice where he established IT Operations teams supporting Virgin Mobile, ESPN Mobile, Disney Mobile and Carphone Warehouse. Prior to this Sanjay was responsible for Global Technical Support at Bay Networks, a leading routing and switching vendor, which was acquired by Nortel. Sanjay has also held management positions in Support Service organizations at start-up Silicon Valley Networks, a vendor of Test Management software, and SynOptics.