Things to consider when using Agile Methodology in SAP Planning projects

11 April 2011

Andrey Bondarev

Andrey Bondarev


Agile methodology is much younger than SAP so it's pretty new to the SAP world. At Bluefin Solutions agile methodology was first used within the CRM capability before being adopted by the other capabilities.  So how well goes agile methodology work with SAP Planning projects? I've been involved in a number of BI/Planning projects using agile so in this blog I'll be sharing my experiences and giving some practical advice. I'd also recommend that you check out Mike Curls excellent blog 'what happens when SAP meets agile?'

What is so specific about planning projects?

Planning solutions have never come straight out of a box - rather they've always had to be built from scratch using SAP tools as the environment on which to build the application. This usually involves a significant amount of bespoke work that can be time consuming and sometimes complex.  With only few weeks between collaboration group meetings you need to ensure significant and visible progress is made - and this often means having to cut corners.

This naturally leads us to the first insight taken from real-life project experience.

Tidy-up time

Good builders won't leave your house in a mess once they have finished their job. In the same way, a good project delivery team should not leave any 'mess' behind them, such as unused objects in the system, sub-optimal code and the lack of clear documentation. Whilst cutting corners is sometimes inevitable, it's important to allocate good time to tidy things up. Be sure to explain to the client in advance why this is important. It ain't broke, so why fix it? Simply because there is a big gap between the 'stuff that works' and decent project deliverables. Have a good look in the following areas, which are often compromised in favour of development speed & functionality:

  • Performance - yes, it works, but can it work even better? Don't forget that your planning application can fly in the development or test system...but will it be the same when it reaches production?
  • Comments in code - at the time of writing it looks crystal clear to the developer, but will it be the same after 2 years even for him, let alone someone else? There is no unanimity in best practice on how well a code should be commented, but normally figures fluctuate around 20% of the total number of lines. And that does not include your obsolete commented out code of course!
  • Redundant objects - be prepared that some of the objects will be created and never used, or used and rejected. This is typical even for the standard waterfall approach. With the Agile approach expect to have more of these! Typically quite a few of the info-objects will not be used and many key figures or characteristics in the cubes will also be redundant. Make sure you do as much cleanup as you can before the final wave of full testing. Obviously deleting so many objects will require some regression testing and you don't want that to be the only reason for an additional testing cycle!
  • Documentation - of course trying to document your developments while the iterations are on-going can be likened to a dog trying to catch its own tail. However towards the end of the project make sure you leave decent functional and technical documentation. Again, this can only happen if you allocate some time for this in the project plan, so do ensure there is budget for this task!

Agile, not twisted

The agile approach in planning projects consists of a lot of decisions, big and small. Whilst it's possible to remember the big decisions history, the devil is in the detail, and the smaller ones might take more effort than they should have ever taken. So when can agile become twisted? You make a decision during the first collaboration group meeting. However a few weeks/months later you realise it was a mistake and agree to do the opposite. Then later on, you all forget why and how you got there and go back to the very first and the most natural decision. Not only does this mean redundant work, but at the end of the process you might find strange things happening in your system. Sales Unit being connected to Base Unit in transformations is just one of the most harmless examples. When this happens, make sure you tidy up, but here is how to prevent this from happening.

  • Traceability - make sure to allocate a person to keep minutes of your collaboration group meetings. I guess it is needless to say that it should not be the person who runs the collaboration group meeting. This will help remembering when and why the decisions were taken.
  • Sign-off process - of course having a formal signoff process and making the client stick to their decisions is against the very principles of the Agile Methodology. However it should be clear at any given point of time who owns a particular area/decision and what the current status of it looks like.
  • Agree actions and dates - if some questions are unclear and the business needs some time off to make a decision, make sure you allocate a responsible person and a realistic deadline and stick to it - there is nothing worse than last minute decisions, even in Agile projects.

Why are we here?

To address a particular business need. It can be a tactical or strategic goal, but every project has an objective. Whatever you do, keep this objective in mind. The fact that users are involved early on is usually welcomed by the business. It is very pleasant to see their active participation in the process, but be aware of scope creeps! Agile principles welcome change and creativity however it is also difficult to distinguish between a genuine need that contributes to the success of the project and an abuse of the Agile approach in order to solve the businesses' old problems. Here are some tips:

  • Always challenge any change or additional requirements from the project and its context point of view and develop this culture within the business. The additional requirements that do not directly benefit the project should not always be rejected. It is however important to highlight when such things happen, as even the Agile projects have to take budget constraints into account!
  • This is not to say that every 'nice-to-have' should be rejected on this basis. On the contrary, some nice-to-have's can be more important than the functional bits to make the project a success. A typical mistake would be to sacrifice look and feel features in favour of more functionality, resulting in a solution that works, but has an interface like that of a Unix operating system. The flashing buttons and flying windows won the mass market, whether we like it or not, and for a reason!
  • You will often find out that there is no clear view or opinions differentiate within the business. Provoke discussions, but do not let them steal your collaboration group meetings - that precious time when the project team and the business are in the same room to develop the steps forward! If the discussion within the business becomes too time-consuming, feel free to intervene and park it in order to go through the rest of the agenda. To avoid tense situations, make sure this is made clear in your introduction to the Agile Methodology meeting (you would run this session with your client, wouldn't you?)

Parameterise and encapsulate

A lot has been said about this, but as it is crucial in the Agile projects so it's worth reiterating. No rotten apples please, but basically, we should expect the requirements to change. When they do change, make sure there is a minimum of places in the system to apply the changes, ideally just one place. Here are some practical tips on how to achieve that.

  • Every piece of logic that is used more than once should be encapsulated in a function module, or a class, if you want to keep up with the trend. I am far from saying that every select statement should stay in a separate module, but if it is used more than once, it should! Even if it is as simple as getting a material group from a material.
  • Maintain a set of easily changeable system parameters and create a function module or a class that returns their values. Personally I prefer creating a technical characteristic and use its texts - short text for parameter value, long text for free text description. The keys would be the parameter name compounded with sequential number - some parameters naturally could have more than one value, for example a list of document types or company codes eligible for a particular action. This is not the only way to implement that, the important thing is to have a module that returns a list of parameter values as long as you send it a parameter name. Never use direct table reads to access the parameters outside of the function module. One day the concept or the structure of the parameter table might change and it would be a challenge to find all its usages! Here are some examples of parameterised constants:


  • In SAP Integrated Planning, make sure you use variables, not constants, in filters and functions. A variable can also have a fixed constant value. It takes a bit more time than just restricting a filter by the constant, but you will thank yourself more than once when you change that value type or version number in one place instead of 10.

This summarises my learning's from the planning projects using agile methodology - interested to know your experiences...

View comments


Blog post currently doesn't have any comments.

Bluefin and SAP S/4HANA - welcome to the one horse race

We use cookies to provide you with the best browsing experience. By continuing to use this site you agree to our use of cookies.