Why The Agile Model Of Software Development Doesn't Work For ERP Projects

ERP software applications are critical for many businesses. They're used to manage business processes, make better decisions, and provide a global view of data. However, ERP systems are not positioned to be implemented or customized using the Agile development model. This often leads companies that want an Agile approach to find themselves in trouble during implementation.

The Agile model is a software development approach that focuses on close collaboration between different parts of the organization, iterative development and frequent testing during the process. The idea behind this is that it allows for quick feedback which can help developers make changes as needed so that they don't end up with inefficient code or poor-quality products.

However, Agile doesn't work well for enterprise resource planning (ERP) applications because these are typically large projects with complex requirements and long timelines. They require more structure than Agile offers, particularly when it comes to managing scope creep or keeping track of feature requests from business stakeholders who often want new features as soon as possible.

Given the many components that need to be developed concurrently (financial management, supply chain management, and customer relationship management (among others)), Agile for ERP is ever more challenging because of its need for close cooperation with non-IT subject matter experts who have their primary job responsibilities on top of the time-consuming and administrative burden of Agile ceremonies and rituals.

Agile Transparency?

One of the biggest challenges with ERP applications is that they’re so complex and have such long gestation periods. They require a lot of configurations upfront to get the requirements right, and then even more time spent on testing those requirements and permutations of scenarios that the ERP claims to support. Given this, it’s natural for software teams to want to prove out functionality quickly so that they can get some feedback from users before continuing work on other details.

While Agile development claims that they allow business stakeholders to see working capabilities quickly - it can be argued that a more traditional Waterfall method staffed with non-robotic and communicative IT managers should be equally transparent in setting the right expectations about the final product or process with the end users.

See Related:

Are Developers An Extension Of Your Business Or Just A Robotic Disposable Resource?

The Agile model was created so that developers could respond to unpredictability through incremental, iterative work cadences, known as sprints. In an Agile process, teams of software developers are organized into small teams and given a set of tasks which they must complete within a predefined time frame. Each sprint lasts for about 30 days or less and is focused on solving a specific problem or creating one feature of the product. At the end of each sprint, the team conducts a review meeting with stakeholders (customers or internal clients) to demonstrate what they have accomplished in that period of time; then they make plans for next steps based on what has been learned during previous meetings and how these factors will impact future development activities. Agile processes emphasize constant communication between different parts of an organization including stakeholders, customers and developers so that everyone understands what's happening with their part of the product at any given moment in time. When applying this mindset to an organization, you can see that constant communication will be a challenge with stakeholders and customers not having the bandwidth to be 100% allocated to the project, creating significant delays in feedback loops and causing more tasks to be rolled over to the next sprint causing all kinds of inter-dependency bottlenecks especially in an inter-connected ERP application.

Stick With What Works

The opposite of the Agile approach calls for a more structured approach where expectations and assumptions are declared upfront and then implemented in a specified order throughout the development lifecycle. This approach is often referred to as Waterfall because it follows the same linear process from start to finish. It can be argued that Waterfall methodologies are not very responsive to change because you have already decided what needs to be developed before you even begin writing code. The ability to be "agile" in a Waterfall methodology ultimately comes down to having excellent "techno-functional" developers who can predict or influence user behavior into what is agile, flexible, and deliverable in a timely manner. Additionally having a software development manager who has remained technically relevant who is experienced in many different design patterns leading the way can mitigate the risk of not being able to course correct if needed.

Since the Agile model isn’t native to most ERP systems, there are several challenges businesses will face if they try to use it for an ERP application. The first challenge is that many companies don't have a dedicated team of developers that know how to implement an Agile process in their software development projects. This means that you'll need someone who has experience with both Agile and ERP systems in order to successfully create your new AP system, which such a skillset is high demand. The second challenge is figuring out how much time and money it will take for your team of developers (or a third-party service provider) to build this new system using an existing product or custom-built codebase from scratch.

Businesses are already familiar with traditional development approaches for ERP applications. But if you consider the fact that most businesses run on ERP systems, and if you consider how long these systems have been around compared to Agile development, it becomes clear why many businesses prefer the old ways of doing things.

Conclusion

Agile approaches are popular in today's software development world, but for ERP applications, they don't work. Why? Because businesses have multiple departments, multiple personalities, and multiple leadership styles resulting in all this required collaboration being prone to failure. Using Agile for ERP development in a corporate setting is similar to managing a 53-man football roster with each player belonging to a specific position group vs. managing a 12-man basketball team with each player playing multiple roles (offense + defense), where removing the variables, communicating clearly, and simplifying the process will win out.

The Agile model can create an environment where more innovation is possible and faster development cycles are expected but, it's important to remember that ERP systems are not built with this model in mind. ERP systems often follow a more structured approach where they specify all steps upfront and then implement them in a specified order throughout development rather than iterating on small pieces every few weeks like Agile teams do. As always it is best to stick with tried-and-true tactics instead of falling for the latest buzzword that often times is a new name for some regurgitated process already known.