INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP
Agile on SAP projects

Agile SAP Success

After offering insight based on my personal experiences around “Agile Project Methods for SAP ERP Projects?” I thought it would be helpful to highlight a couple of areas where Agile does work.

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

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

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

 

Applying Agile Methods to ABAP Software Development and SAP Data Conversions

Development (ABAP, Java, or other coding)

Since Agile methods have been used for some time with small, discrete components of software development I won’t spend a lot of time there.  On a typical SAP project you will end up with a functional spec which defines the program requirements and a technical spec which 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, it is 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 3 for software development.  By 3 cycles I mean 3 completed cycles too.  This is not a demonstration with feedback that is only partially built.  If the feedback cycle is not completely implemented 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 3 complete cycles or “sprints” (not including a minimum of 1 mock go-live conversion, probably 2 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, making adjustments to the conversion script where necessary, and achieve a goal of at least 98% conversion completeness and accuracy.

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

Agile Design

Agile processes or sprints, are effective for design sessions.  Done correctly, this allows 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 with Agile Design vs. the traditional SAP Blueprint is the timeline.  An Agile Design approach requires more time because there is an element of system setup and solution discovery.  In the traditional Blueprint approach, everything is done on paper and many details are often missed.

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.  What this means is that 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 100% of the integration areas, or solution areas completely set up and defined.  This is important to understand.  If a customer expects to see perfection during Agile Design then a more structured waterfall approach, with a formal paper Blueprint would be required before any system solution activities are performed.

Conclusion on Agile in SAP or other ERP Projects

Even with newly packaged Scrum, Agile, or other methods, on an SAP project there are so many moving parts and work streams to coordinate that there is no substitute for a good waterfall project approach.  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 work streams.

The Agile approach that works for an SAP deployment is one with a mix of both Agile for discrete task areas combined with a waterfall overlay.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175
Bill Wood contact

=========================


Print pagePDF pageEmail page


Popular Searches:


  • erp prototype
  • what is erp prototype

Related Posts:

3 Responses to “Where Does Agile Fit in SAP Projects?”

  1. 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

  2. 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…

  3. 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?

Leave a Reply