After 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 SAP 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 SAP 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 SAP project. 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).
- Build the initial conversion program to all of the requirements (again, partial requirements do not count as a full cycle).
- 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.
- 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%.
- 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 SAP Blueprint 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 integration 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 SAP project 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.
I have a question regarding data conversions from Agile to SAP. We recently have integrated our existing Agile deployment with SAP and subsequently needed to change all of our Bill of Material values in Agile to register quantities for 1000 units because of SAP requirements. This value is also projected to our engineering drawing Bill of Materials, so now it appears that the information on our product BOMs is listed per 1000 units, which is a little misleading to the average person.
Could this information have been converted during the data transfer process from Agile to SAP rather than ‘fudging” the values in Agile to satisfy SAP?
i would agree that it would fit with post-production support activities. I hadn’t considered that in the post but your point is *very* well taken indeed. Thanks for the feedback…
Hi Bill,
The other place that I’ve seen Agile (or Agile style) methodologies work realy well is in the Support / post Implementation stage with ABAP / Functional consultants working directly with / for individual business units. You do need to have some arbitrary limits on what size (budget / dollar / modules affected) triggers more robust examination, and as always the better (and more automated) your test systems are, the better results you get.
The challenge is that doing all of these project ‘infrastructure’ things correctly costs time and money; the cost of setting them up each time you do a major waterfall project gets hidden in the project overhead or is seen as an insignificant percentage of the total project cost. By comparison, setting them up once for multiple Agile projects doesn’t alter their cost, but the cost is perceived as an overhead unrelated to any particular project. In other words, no wants to pay for it :)
hth