Skip to Content
avatar image
Former Member

Agile Development in an SAP Landscape

My team is looking to shift from a 'regular', waterfall-type development methodology which delivers 2 large functional releases per year to a more flexible, nimble project based approach based on Agile Development methodologies.

The goal is to be able to treat each project independently from a resource and scheduling perspective - so multiple projects could be underway at any one time but each one potentially running on a different time line. Of course, life-cycle support for the production environment would be on-going at the same time.

The problem we face is defining an SAP system landscape that supports this approach and that allows for the management of the inevitable conflicts that will arise when different projects require changes to the same development object.

I'm interested to hear feedback from anyone who has implemented an Agile Development approach within an SAP environment ( successfully or not ! ) as well as ideas for what a possible Agile SAP landscape could look like.

Thanks

Tim

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • avatar image
    Former Member
    Jul 24, 2007 at 10:15 PM

    Our team has been adopting some agile practices and have seen some great benefits. We have not embraced one methodology entirely (XP, Scrum, etc.). We're taking bits and pieces that make sense in our environment and adopting them incrementally.

    Here's an example of some of the things that we're doing:

    1. Chunking out development tasks. Basically working with the requirements or functionality that we know and not waiting until every possible scenario is clearly (or not so clearly) defined. We try to get stakeholders (business users and BPx's) looking at our programs and prototypes often to ensure that we're on the right track. This chunking out of tasks has been a benefit in that it is easier to manage (from a manager and developer perspective) and it gives us clearly definable goals for what we're shooting for in a fixed time frame (1 week). We talk individually every day (short spinarounds) to ensure that we're on track and identify any potential risks.

    2. Modeling of requirements. This proves extremely valuable to our developers, functional folks, and business users. This usually involves grabbing a couple of folks and whiteboarding ideas to ensure that everybody has a clear understanding of what is going on. I will admit that this we certainly don't do it as much as we should, but it's something that we're working on doing as much as we can.

    3. Frequent builds/migration. We currently transport released changes to test every 30 minutes in the ABAP stack. This allows us as developers to move on to the next task and allows our testers a quicker turnaround of bug fixes and new functionality. We move production code twice a week. For the JAVA side, we do a "JIT" build/deployment. As fixes need to be migrated, we check in/build and deploy. Since the NWDI is still new to us, we haven't done much investigation on automating this process, but I imagine that we will do so in the future.

    One of the challenges that we ran into was thinking that the code was the only thing that matters (which you might get from some agile camps). Just because you're modeling and documenting (just enough documentation), does not mean that you're not "agile". You don't throw out design and analysis just so you can sit down and write code to have something to show somebody. The collaboration and clarity that agile practices provide is one of the keys to making it successful.

    We started implementing some of these practices in the development group about 8 months ago and since then we've seen some interest/adoption in our project management group and functional teams. I would imagine that we'll continue to pick and choose practices that work for us...try some out, see what happens, adapt, evolve, etc. So far so good in my opinion. From a managment perspective, it really has made it easy to know what people are working on and how productive we can be as a group. From a developer's perspective, it makes development easier and more fun when you have a clear target in front of you and you can throw out ideas in a modeling session. From the end user perspective, they seem to like that we can roll out production ready functionality in an incremental way so they don't have to wait 6 months to get something that they can see and use. From my limited experience, it seems to be a much better way to develop applications.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Dear Mohammed

      Can you share the documentation for implementing SAP using Agile concepts with me as well?

      Best Regards

      Hrishikesh

  • avatar image
    Former Member
    Jun 23, 2012 at 11:37 PM

    Hi, Tim.  Eric and I have made a lot of progress on implementing "agile" within our organization.  We have started to share our experience with agile and SAP on our website at http://www.bestxperts.com.

    My first post describes our journey from Waterfall to Agile from a high level:

    http://www.bestxperts.com/blog/posts/running-sap-projects-the-path-from-waterfall-to-agile

    More posts to come soon.

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Apr 13, 2015 at 11:49 AM

    Hi Tim,

    Have a look at this link.

    http://www.basistechnologies.com/how-to-run-agile-development-for-SAP-tips

    You may find some answers you're looking for.

    Cheers,

    Olly

    Add comment
    10|10000 characters needed characters exceeded