SAP Agile on projectsAfter offering insight based on my personal experiences around “Agile Project Methods for SAP ERP Projects?” I wanted to highlight a few areas where Agile does work:

  • Design sessions
  • Development efforts (i.e. coding)
  • Data conversions

Once you begin to move beyond these areas, you quickly encounter dependent workstreams that need much more coordination. Those additional dependencies make it difficult to apply Agile methods.

While Agile tends to emphasize the one-week to one-month “sprint,” I would define a sprint as more of a completed requirements and planning package rather than a pure timebox approach.

Applying Agile Methods to ABAP Software Development and Data Conversions

Development (ABAP, Java, or other coding)

Because Agile methods have been used for some time with small, discrete components of software development, I won't spend much time there. On a typical project, you will end up with a functional spec that defines the program requirements and a technical spec that informs the development details. Even though the more typical “Agile Manifesto” method would not require the documentation, it is well-placed on an . In fact, businesses would be foolish not to have it for long-term support and maintenance.

Development can work well for the Agile stages of build/prototype, demonstrate, gather feedback, adjust, and repeat. The key here is to limit the number of these “Agile” cycles to no more than three for software development. By three cycles, I mean three completed cycles as well. This is not a demonstration with feedback that is only partially built. If development does not completely implement the feedback cycle, then it is not a complete cycle. Even though Agile would consider these “sprints,” I would consider them a failed sprint if the requirements of the current plan, or the subsequent plans, are not fully realized in the prototype or demonstration.

SAP Data Conversions using Agile Sprints

With data conversions, I suggest at least three complete cycles or “sprints” (not including at least one mock go-live conversion, probably two or more if you can).

  1. Build the initial conversion program to all of the requirements (again, partial requirements do not count as a full cycle).
  2. Pilot a test conversion with all data, no matter how much fails, and capture all necessary changes. This will include data dependencies and sequencing. At this point, you will be lucky to achieve a 70% success rate when considering all of the data dependencies. This step is not about getting things perfect, but about identifying data and programming issues to resolve.
  3. Implement all SAP data conversion changes the conversion pilot exposes, script every conversion step and rough timings, and aim for a successful test target of at least 90%.
  4. Make additional changes and attempt to follow the scripted conversion, adjusting the conversion script where necessary. Achieve a goal of at least 98% conversion completeness and accuracy.

Once you achieve this level of conversion consistency, you are ready for a mock conversion. These Agile “sprints,” or “Scrum-ban” (a spinoff of Kanban) as they are starting to call them now, ensure a successful data conversion.

Agile Design

Agile processes or sprints are effective for design sessions. Done correctly, sprints allow a customer to be exposed to the system earlier, provide better insights and results, and generally improve overall solution fit.

One of the major differences between Agile Design and the traditional is the timeline. An Agile Design approach requires more time because the method has an element of system setup and solution discovery. In the traditional Blueprint approach, everything is done on paper, so the team misses many details. In an Agile design approach:

  • you bring in a live system, pre-configured to your best estimation of a customer's requirements;
  • demo the standard capabilities with a “guestimation” of the customer's configuration and data;
  • and perform interactive design sessions with the live system and the customer during the actual design sessions.

You build a live system together, during workshops, so that you are performing knowledge transfer and building a solution together. Customers see how it works, provide critical inputs for configuration and data, and walk away with a greater sense of understanding and solution ownership.

When you combine an Agile Design approach with Lean principles, you can see overall project benefits in quality, cost, and overall solution stability at go live. During the design, you are actually doing small sprint-type activities to build out key areas of the solution. Design sessions become playback and adjustment.

One key consideration with this approach is that you will not have all of the or solution areas completely set up and defined. If a customer expects to see perfection during Agile Design, then they should have a more structured waterfall approach, with a formal paper Blueprint, before performing any system solution activities.

Conclusion on Agile in SAP or Other ERP Projects

Even with newly packaged Scrum, Agile, or other methods, an has so many moving parts and workstreams to coordinate that a good waterfall project approach has no substitute. Using “Agile-like” methods for the ABAP development or data conversions is not a substitute for good project management, either. Done properly, this approach can work well as long as it is carefully managed along with the rest of the workstreams.

The Agile approach that works for an SAP deployment employs Agile for discrete task areas combined with a waterfall overlay.