The History of Agile and the Unintended Consequences
The History of Agile and the Unintended Consequences
While there’s an endless supply of content discussing the benefits of adopting Agile workflows, little is said about the unintended consequences of the Agile approach.
A staggering 71% of companies say they use an Agile framework to support their software development process.
Why was Agile introduced?
The Agile framework was born in 2001 when 17 technologists published the Agile Manifesto. They wanted to experiment with shorter delivery cycles for developing software to more closely align with business objectives and priorities. Before Agile, development teams traditionally had long project cycles that were measured in months. However, with the high rates of project failure inherent in this approach, organizations needed a better and more efficient software delivery methodology.
In an attempt to improve project cycles, development teams tried to perfect their upfront planning with more thorough requirements in areas like data gathering and architecture design. However, with most applications, it’s not possible to know all the requirements until building begins and feedback is received. Without a complete understanding of application requirements, it’s not possible to preplan the architecture. Therefore, project cycles continued to fail at a high rate.
Agile addressed this dilemma by introducing the concept of shorter delivery cycles and the ethos of constantly building, validating, adjusting, and rebuilding. Since then, Agile has transformed the tech industry: development teams can experiment more freely and “fail fast.” Many organizations have also shifted their company structure by creating smaller development teams that can test and iterate more quickly as they build.
The speed and innovative possibilities of Agile are certainly valuable in development, but as cycles move faster, teams have experienced unexpected pitfalls.
What are the unintended consequences of Agile?
1. Siloed teams
In the Agile framework, a higher number of smaller teams work closely together, which means there aren’t many opportunities for cross-exchange of ideas. Because each team focuses on a separate product or area, they tend to have specialized knowledge of a subsystem (or microservice) that stays siloed to a handful of people.
With siloed knowledge, it’s difficult for teams and management to know how the code being written fits together at a macro level. Without a macro level understanding, development teams can’t anticipate the full impact of making code changes. Teams either manually crawl through the code to understand its dependencies or rely on other sources of information, such as their IDE, which only exposes a subset of the details needed. As a result, a code change ends up breaking something no one ever knew would be impacted.
2. Prioritizing software over documentation
Another unintended pitfall of the Agile methodology is that it prioritizes working software over updating documentation. With teams working in shorter development cycles, updating documentation often falls through the cracks, robbing teams of the ability to understand what has been changed.
Why is dependency mapping part of the solution?
The CodeLogic team is made of developers who understand the frustrations with the pitfalls of the Agile methodology (siloed knowledge and out-of-date documentation). Our product brings key dependency intelligence to teams when they’re making code changes, so they can reduce break/fix cycle frequency, understand change impact on other teams, and make code changes with confidence.
With CodeLogic’s static and dynamic application scanning capabilities, systems are automatically kept up to date, allowing development teams to spend more time building and innovating and less time manually maintaining documentation.
To learn more about how CodeLogic can help you and your development team, download our eBook: 5 Answers for the Developer.