Agile Project Methods for SAP ERP Projects?

Looking at the “Agile Manifesto” and how Agile methods have been applied generally involves small, discrete, “digestible” work and task components.

Juggling the number and complexity of dependencies on a full-scale SAP ERP project involves management and coordination efforts, which completely go against the idea of pure Agile methods.

======

ERP projects tend to have too many moving parts and dependencies for Agile, as the methodology provides too little control and coordination. The level of coordination required for a large business package implementation flies in the face of Agile-only methods and techniques. For example, you need to coordinate the following:

• process configuration teams,
• custom code development teams,
• data conversion,
• change management,
• training,
• testing,
• governance,
• infrastructure, etc.

On complex projects, any “sprints” that are not carefully coordinated and planned become completely disjointed (which goes against the “Agile Manifesto” listed below). Too many workstreams with dependencies cannot be allowed to operate on their own– you must coordinate the integrated cross-team impact to other workstreams.

Agile Manifesto Activities

The following chart from the Agile Manifesto illustrates serious trouble spots for ERP projects such as SAP.

Notice that three out of four of those items on the right side (Agile DE-Valued) are often precursors to ERP implementation failures according to the academic literature. For context, in the mid 1990’s, several ERP and large Enterprise package projects were failing. After careful research on the root causes, the studies showed that Agile “De-Valued” areas are the places ERP projects fail. For example:

• Failure to follow good processes and have solid tools, templates, methods, and guidance.
• Failure to have adequate documentation (clearly defined scope, lacking design details, training materials, help, etc.).
• Not following a well-laid-out plan (for example, SAP Activate).

The only Agile Manifesto item listed above that has merit in the ERP space is the focus on the customer over the system integrator contract. Unfortunately, this “customer collaboration” is lacking on most Agile projects because Agile so completely fails to coordinate the various workstream activities.

All of Those Competing Stakeholders and Constituents

Not only are the project-related dependencies and work streams significant, but numerous competing constituencies must also be coordinated:

• business stakeholders or organization,
• IT,
• external business customers,
• external vendors,
• system integrators (when you use consulting companies),
• internal business senior management,
• business department heads (who don’t always agree with each other), etc.

While Agile methods might work well for small, discrete, component areas of an SAP or other ERP project, the academic literature proves that this method can be a disaster for ERP implementations.

However, Agile is not a waste of time– it just needs to be understood and used in the proper context of an overall SAP project. Even the Activate Methodology includes an “Agile” overlay. This overlay does not replace more traditional waterfall methods and does not adopt the “de-valued” Agile Manifesto areas.

Does Agile Have a Place in ERP Projects?

Yes!

Remember, Agile works well with digestible, discrete, or self-contained work packages. Also, remember that an ERP implementation with solutions such as SAP requires good documentation for production support or even user training. De-valuing documentation only leads to possibly significant future pain points.

Some examples of where Agile does work include design iterations through business processes. During these design sessions, you co-create with your customer an MVP (Minimal Viable Product) using configuration. This way, as you exit design, you also have a functional system with 60-80% of the base solution configured. This can save time from the traditional waterfall approach, where you have a separate Design (Blueprint) and then Build. It also exposes the user community to the solution earlier and helps with knowledge transfer.

However, this still requires a waterfall effort to define the workshop schedules, work through resource dependencies or constraints, and develop an initial detailed scope assumption before beginning the design. This approach requires that the consulting company you use provide consultants with deep enough experience and capability to pre-configure a “straw model” before the design workshop starts. Then, they demonstrate the standard capabilities, and finally walk through the detailed configuration and capture solution gaps in a half- to full-day design session for each discrete component of a solution process area. For example, you might do an all-day design session demonstrating just SD order types and their settings and options.

Again, the sessions are planned using waterfall. The scope is known ahead of time, the actual solution build starts with a straw model, and then Agile is used to refine the actual solution build during the design session.

Another area where Agile works well is in development. However, this does not mean that you should do development without initial requirements gathering (or user stories) and functional specification documentation. Later, you need technical specifications to support the documentation of code, tables, and any program complexities. This is especially true for larger development objects that may involve multiple programs, multiple custom tables, and multiple data exchanges. That technical documentation can save days, or even weeks, when a change might be needed later.

Those project areas with overlapping dependencies and cross work-stream coordination require more traditional project management methods with:

• full project plans,
• discretely defined tasks and responsibilities (to avoid “border wars” at transition points),
• clearly defined deliverables,
• management of parallel work-streams and parallel critical paths, etc.

Applying “pure” Agile principles to an overall SAP project creates a high likelihood of blown timelines, blown budgets, and collapsed scope — delivery suffers as stress balloons. However, looking for discrete chunks of work that can be coordinated through normal waterfall methods does allow the benefits of Agile to produce a better overall result. Their overall program, projects, and workstreams must all be coordinated with a detailed waterfall plan, while individual tasks that roll up to the project plan might use Agile methods.

Agile in SAP ERP Project Examples

I know about the struggles, stresses and messes of SAP projects where the team attempted to do the whole project, or large portions of it, with pure Agile methods. I have been on several of these types of projects, and none of them went well.

On one SAP project, they tried to run the whole project with “Agile,” and it was a complete mess. The coordination and responsibility struggles forced a change to the more traditional waterfall approach. Using Agile methods, the project had an unsustainable burn rate for the budget, dates were always slipping, inter-team coordination and planning were a complete disaster, and before the mid-course correction, this project was not going to go live.

Worse still, because of the “Agile” methods of only planning small, discrete work components just before they are due, each dependent group tried to minimize their own work and risk by dumping many of their traditional responsibilities and tasks onto any other group. With Agile, they could self-define much of their own effort and naturally tried to minimize their effort while maximizing their success (at the expense of other project participants and workstreams).

On another project, the workstreams minimized their clear risk of missing the timeline by simply dumping a bunch of garbage into testing. They figured the Integration Testing would fix the complete mess. The shove-it-in testing approach creates major downstream problems with the constant fixes leading to the following problems: constant data mapping and data migration changes, continuous design until go-live, constantly adding or changing requirements, and high risk to solution quality at go-live. This delivery practice is easily among the worst.

My Conclusion on SAP and Agile Deployments

Pure application of Agile is a disaster on any major SAP, ERP, or business software implementation project. I can absolutely guarantee you that any Agile SAP project delivery “success” claim violated the Agile Manifesto to get there. There are too many moving parts and too many constituents to use pure Agile on a full-blown SAP project. A full project needs a component of waterfall-type coordination, no matter what it is called (SCRUM, SCRUM of SCRUMs, etc.).

However, Agile can work within certain task areas, and at different periods and phases in projects. I have used “agile-light” or hybrid-agile approaches that have a waterfall overlay. You can successfully combine agile tasks to provide a higher-quality project result, as long as you continue with the waterfall coordination between workstreams and efforts.

The real challenge with pure Agile combined with Commercial-off-the-Shelf (COTS) Enterprise Applications is in the nature of Agile itself. Agile works well when you are iterating and trying to discover vague or unknown solutions. You use a starting premise through the customer story and iterate through that until you reach some level of consensus on satisfying the story. However, with packaged applications sticking fairly close to standard, the processing steps are the processing steps. The “Best Practice” process flows are the process flows. The application capabilities are known. So, the real issue is in understanding where there might be gaps to fill rather than starting with a clean sheet of paper.