Agile Development in an SAP Landscape

Question

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

Answer 1

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.