Agile Project Management is a management framework that delivers technology products in incremental releases. There are various methodologies for running agile projects; a leading approach is Scrum, created by Ken Schwaber and Jeff Sutherland. Recommended reading on the SCRUM Agile approach scrumguides.org.
A vital aspect of Agile SCRUM is delivering functionality in smaller smarter sets, often in shorter project cycles. Agile SCRUM removes the concept of a project and replaces iterative, ongoing rollout of product and fixes to bugs.
Traditional software projects focus on delivering new software products in a big bang approach over a software development cycle (SDLC) (requirements, development, configuration, unit testing, integration testing, user acceptance testing and go-live).
The problem with the traditional waterfall approach is that the business does not see the final product until just before go-live. The time between the requirements gathering phase and UAT acceptance can be months apart. The expectations of the business often are misinterpreted, or due to the long period, the business users change their minds..
An infamous study was done by the Gartner Group and repeated by others with similar results.
There are many studies, and the general conclusion is that:
75 percent of all ERP projects fail to be successful.
The findings also show that smaller projects are much more successful than larger ones. The bigger the project, the more likely it would fail. Failure usually can be tied directly to change management issues. Also once the project goes live, the technology implemented is already considered legacy.
With Agile, delivering functionality to production more often, has a positive effect on change management. Smaller projects mean smaller scope that goes live at any given time. If there are problems, the impact on the business is minimal due to the smaller iterative functional change.
Developing a culture of rapid deployment of new technologies via smaller iterative rollouts has significant benefits. Users see the positive side of the new functions almost immediately. Smaller scope and a shorter period. Business can absorb the change and embrace the benefit without being overwhelmed.
A traditional big bang approach project goes with a significant disruption. This disruption is a negative one, as it leads to a dip in productivity, due to the long learning curves to learn the new functionality. Users do not see the benefits, just the chaos created by the implementation. Business processes are impacted negatively, leading to a general lack of faith in the technology product.
For traditional SAP implementations of its ERP product, it was necessary to bundle large amounts of scope within a single project due to the integration nature of an ERP system. Waterfall has been the chosen method for these types of implementations due to its complexity.
In addition to the large scope requirements, SAP ERP systems often required business users to accept less than "best of breed" software, in exchange for the benefits of overall integration. ERP systems were comprised of single instance central core systems, which did pretty much everything. Interfacing with an ERP system was a nightmare as standards didn't exist. Thus companies would push ERP functionality, even when the ERP functionality was substandard.
Further complicating ERP system solutions was that these systems were proprietary. Companies were at the mercy of the ERP vendor for everything, and there are examples where the ERP system brought down a few companies. ERP systems did not separate the front end from the back end, customizations and development to simple front-end aspects, required code development on the back-end. User interfaces were horrendous, merely put the user experience was a very negative unproductive one.
SAP has moved beyond the ERP concept and now offers more distributing computing solutions, and the code base is now open source (Web-dynpro is now considered legacy, and ABAP code is written as an exception, giving way to open source products. There is no question to anyone in the industry, that proprietary code is not as good as open source code. There is a lot of misinformation out there, and what it means to be open. It isn't' about free software; it is about access to the software code base, where changes can be made to modify the product to suit individual company needs.
There are definite growing pains in this transition (mostly with legacy proprietary SAP technical resources and their resistance to change). A lot of lost opportunity can occur by staffing a modern enterprise project with senior legacy resources. Legacy ERP required highly specialized SAP proprietary skill sets. Today's skill set required to implement SAP is aligned with SAP legacy ERP skills, and more aligned to a full stack designer and developer.
Companies that strictly hire resources based on SAP experience are continuing to align with the 70% failure rate statistics. If these resources have not updated their skill base, (which isn't easy to do), SAP HANA next generation implementations, are just ERP implementations, running inside SAP HANA. The bottom line is that enterprise systems must adopt new technologies (like drones, or automated cars) in near real time. Companies no longer can afford big long drawn out projects.
Agile project management helps facilitate the adoption of new business functions faster, and the solutions gain greater user acceptance. Agile projects are hitting 80% or more success rates, the opposite of the 70% failure rates of waterfall projects.