Agile development for ERP?

Developing software and delivering an SAP project are not the same. Many customers who use ERP systems (SAP) are looking for an answer on how to get their ERP team develop using Agile principles. But is that the right thing to do?

We will discuss the primary problems any team will face when trying to move to Agile from traditional waterfall delivery model and compare how does it stack against different scenarios.

Let’s Start with three common problems any organization will face when moving from Waterfall to Agile:

1. Resistance to change – There are two sides to this story from a team point of view it’s difficult to change something that everyone is comfortable with for many years. At the same time other side of this story is usually we need to be an agile team. This ultimately leads to a top down enforcement – Basically you were told to develop in Agile ways of working and team don’t have any choice.
2. Training – Every member of an agile team needs to be trained in the guiding principles. A typical team of 10 members consist of a product owner, scrum master and developers. Everyone needs to possess good amount of knowledge on the product itself.
3. Stakeholder engagement – A product owner for a team is predominantly part of business unit and although they would engage with IT to deliver the product, not necessarily they can spend 100% of their time. Sometimes they end up dedicating this task to a senior trusted member of the development team or to a deputy.

Why Agile ways of working is so sought after today?

1. It’s a lean development technique for Software development.
2. Your main goal is to provide value early to customer and faster in a predictable manner.
3. You can adapt to changes more easily and can foresee problems up front.
4. The idea is if you do fail, fail early.

All systems good to go:

So far, all the above makes sense. Agile methods are clearly a good way to deliver software faster. If I can create a trained, product focused team, ensure the stakeholders are buying into this idea and team is open to adopt to this new model the delivery will be successful.

Stop:

Although in theory above sounds good, there are few problems.

1. SAP Implantation is not true product development: To start with SAP Implementation is not a true product development. Definitely not for a customer of SAP.
2. Sprints for E2E development: Many of you probably know the scrum and sprint process -The process recommends short burst of development cycles which are added up to a release cycle. In short, your product team is creating multiple components of a product and then adding them together to create the final masterpiece. The Agile model initially was used on web developments. Process described above fits that model As an example creating a WEB- GUI or building part of a webpage as a feature can be completed by an individual developer and these pieces can be integrated with a web page later. You don’t need to evaluate E2E dependency. You can test the pieces individually. Any ERP user will tell you either you implement an E2E flow for them or don’t deliver at all. In short business testing within ERP cannot be approached only unit wise.
3. Integration: Almost every customer uses more than one SAP box and have integration with other systems. If E2E business process is not integrated with these systems, the implementation is incomplete.

There are other issues but let’s focus on the above three pain points during this discussion.

Team’s perspective:

Team has been told to move to Agile, although still they trying to understand how the model works. One thing for sure – It must be E2E process implementation.

OOPS:

Every new team tries to adapt to agile and create a hybrid model which is basically worst of both world (Waterfall and Agile – Scrum-gile ).

In this hybrid model you would observe product owners, scrum masters asking for delivery date exactly like waterfall for every Artefacts on the wall even the components developers are building.  Daily status updates – why this is not done yesterday? and when this can be completed?  etc. Developers complaining “too many project planning meetings” (which they care very less – they would rather be more productive if they build or code). Product owners introducing change in the middle of a sprint and expect to deliver on time. Retrospective’s for team are not taking place or the actions coming out of retrospective are not addressed promptly; features cannot be tested unless all dependencies are closed.

Do this sound familiar?

What went wrong:

Agile principles work better when dependency is low and work is specific user group/product focused, for example you are creating an APP, multiple web pages, a web site, a single nondependent change in ERP with multiple features.

But it doesn’t work as effectively when you are trying to do a large-scale project implementation.

Let’s look at an example:

A Single Problem Statement: A business user would like to create automation in a S/4 system that allows them to see daily sales, submit the sales report to a group of user via email and also show a projection based on past sales.

An Agile Solution: If any agile team is trying to solve the above problem alone, they can potentially create a Minimum viable product (MVP) as the sales report. The other two features, Email alert and sales projection can go in the next sprint but just by delivering the sales report you will give immediate value to business.

Now a Global ERP Problem: The same problem statement now can be looked in ERP context where this sales report is needed for every country in your organization. Apart from the email functionality now we also need to submit the sales data to another system via an interface and the projection must feed into manufacturing planning.

If we just deliver just the sales report, it’s not enough.  Unless the entire problem is solved in one go there is no / very little value to business. If we go via the MVP concept product owners will tell you the value is so low that potentially it is not worth spending the effort only to deliver the sales report.

On top of this many organizations has legal requirements to meet like SOX, GXP which means they need to complete tons of approval and documentation before any release.

So agile is not fit for ERP implementation?

That’s not correct. Both waterfall and Agile ways of working has its merits. The best part of agile methodology that ERP teams can use is engaging your customer more often, adapting to change quickly, keeping customer value in focus while developing or implementing a new change, try to split work into smaller technical deliveries ( if possible ), and finally collaborate (Don’t work on silo’s).

But while setting up Agile teams we need to be careful and choose the products that fit into the agile model of delivery.

A few examples below.

1. Robotic Process Automation – There is a baseline process already available chance of team being dependent on another is less.
2. Standalone tools/Utilities – Where dependency is less but multiple standalone tools are required for a specific user group.
3. SAP FIORI roll out – Rolling out SAP FIORI to a group of users.

Brain Drain:

There are few more problem with this model- Learning of development team is very limited in SAP world developers ( programmers and analysts) cannot just focus on one area of business as many of them are cross skilled to manage dependency between several business processes.

Keeping them focused on one area for long time will reduce overall knowledge in the organization. In today’s world learning and R&D is a must whether this IT or Business, so team’s investment is less in learning they will be obsolete.

A true product development requires constant R&D, few real-life examples – The electric car or smart phones, new vaccines, drugs took years of R&D to develop one product.

IT teams are no different only benefit is they don’t need years of R&D as most of the tools that can help them are out there. But keeping them focused on one module for long doesn’t help.

Conclusion:

Following a methodology for the sake of doing so is wrong. If there is value to follow a particular method to deliver faster or improve efficiency, collaboration in team go for it.

Thumb rule to choose between Agile and Waterfall is – More stable standalone product developments can be accommodated by Agile ways of working. Whereas more dependent product development and implementations work better with waterfall. (Mostly large-scale implementations).

Going Agile from waterfall is a brilliant idea but carefully choose which teams are eligible to do so and if ERP teams are not agile but practices the fundamental principle of collaboration, looking at customer value, understanding the customer, solving problems as one team, you can count on successful implementation and smooth operations.