Skip to main content

How to approach Agile for SAP

You run SAP and want to
be more Agile, right?

But you can't treat Enterprise Applications
like consumer Apps.

Read on for some practical Agile SAP tips
and the gotcha's that lie in your way.

How to approach Agile for SAP

 

Agile is where we're all heading...

It’s the latest buzzword and CIOs all over the world are bearing the brunt - shifting
from process to product focus, moving to sprints and standups, and implementing tools like Jira.

But in a complex, integrated SAP environment, agile is so difficult.

Plus, the people who’ve been around SAP for years are entrenched in decades of waterfall, meaning they find it hard to deal with the change.

So how do you move forward and convince people from what is now a legacy world to adapt to more modern ways of delivering technology?

Become more Agile with SAP

We'll define product owners and implement Jira. Done.

What are the obstacles to becoming more agile with SAP?

Plan ahead without a clear SAP roadmap

Agile suits solutions that involve uncertainty. If you don’t know what your end ‘product’ will look like, agile enables you to iterate and build limited features that customers can test and feed back on. This is why sprints work well - because they allow the freedom to change path periodically.

Waterfall suits solutions that have high levels of certainty. For existing business processes (even if you’re changing or transforming them) you have a clear idea of the end result. This means that you can plan the work out in detail and build large components in a single project.

Agile is a better fit for incremental changes or ‘value sprints’ to an existing solution.

Agile is also a good fit where you are looking to fit-to-standard and showcase new functionality to existing users in order to plan adoption strategies.

Don’t forget that the actions in an agile sprint don’t have to be development - you can also use agile for change management for example.

What are the obstacles to SAP agility

What's your level of certainty about your future SAP roadmap ?

Unbundling SAP change is key for Agile.

In a tightly integrated ERP environment, the changes you make across modules are likely to be tightly interwoven, with significant dependencies on each other.

This means that deciding to drop a change from a release late in the development cycle will pose technical challenges.

How do you unbundle a single change without impacting the release?

Planning releases so that changes can be easily unbundled is worth considering if you are serious about becoming more agile with SAP.

This either involves building isolated functionality or building flags and switches into your changes so that they can be turned off in production without changing code or configuration.

Doing this adds complexity to design, build at test. However, it will enable you to deploy code that is not quite ready knowing that it will not be used - instead of unpicking changes late in the development lifecycle.

Faster SAP Development Cycles

How will you unbundle a single change without breaking the release ?

Get serious about SAP test automation before committing to Agile SAP delivery.

If you’re going to build and release at pace, you need to be sure that you test thoroughly and repeatedly.

Test automation is often seen as a Nirvana for SAP customers - something that’s a nice idea but not practical.

The truth is, the world of test automation has moved on immeasurably in the last 5 years as consumer grade applications have followed true DevOps delivery models.

Some of this automation has finally made it’s way over into the Enterprise Applications space and it is both possible and economically viable to automate significant chunks of SAP testing.

Test automation for SAP

Test automation is commonplace in consumer grade apps. So, why not in Enterprise ?

Choose Process Ownership over Product Ownership
when going Agile with SAP

Too many people blindly adopt a classic agile Product Owner model and assume that SAP can be ‘product managed’ the same way that an externally facing, commercial software product would be.

This is forcing a square peg into a round hole for no reason other than “it’s what the agile book says”.

Provisioning Business Processes

SAP essentially provisions business processes for your business to consume so that it runs effectively.

Business process ownership is a critical role in large organisations to drive efficiency, compliance, customer service and, ultimately, long term profitability.

Whether you adopt a more agile model for SAP delivery or not, process ownership should always be front and centre of your SAP delivery model.

SAP Process Ownership in Agile Development

Let's appoint a product owner for SAP. That'll do it...

Go practical first - Kanban before Agile

Full on agile isn’t always the best fit for reasons outlined above. But, there are some principles of agile that give a great deal of the benefit without the change management effort and risk involved in full agile.

Kanban is the often overlooked practical alternative to agile for SAP customers.

Kanban is a visual way to track workload following manufacturing ‘pull’ principles borrowed from Lean Manufacturing. By limiting Work in Progress, Kanban automatically improves throughput of workload.

Kanban can be used within traditional Waterfall phases to manage workload (e.g. build items or test cases) and involves minimal change management and education other than team orientation.

Using Kanban with SAP

Kanban is the often overlooked practical alternative to agile.

Backlogs of the right things

Incremental improvement in SAP enabled business processes is straightforward and yields tangible results if SAP teams build backlogs of the right things.

Good examples of SAP Backlogs
1. SAP Workarounds

Often when large SAP projects go-live, challenging change requests can be cut from scope in order to get the project ‘over the line’. Trouble is, businesses don’t formally track workarounds - meaning they never go back to address them. The business is left ‘working around’ an issue and it becomes the new normal.

2. Business Tolerations

Sometimes business people “put-up and shut-up” finding certain things in SAP frustrating but reconciling themselves to the fact they may never change. They don’t log tickets, they simply tolerate the way things are. Getting these things out in the open and on a backlog can be a transformational way to build business confidence in IT and add real business value.

3. Process Inefficiencies

IT teams don’t always think in process terms and can sometimes over-fascinate the technology, which alienates business people. Working with business process owners to identify inefficient processes in SAP moves the conversation from a technical to business value discussion, meaning which the business case is more self-evident.

4. MI Gaps and SAP reporting issues

Management Information and Analytics are rarely fit for purpose. Execs and business leaders always wish they could measure something else or aggregate results in a better way. Again, outing these Management Information Gaps in a backlog sharpens the focus on what matters most - and often uncovers other more fundamental factors in process design.

Bad examples of SAP backlogs in agile
  • System Patches and Updates
  • Technical vendor-led features (e.g. Enhance POB Validation BAdI with Worklist Message Handler)
  • Vague features (e.g. improve VA01 screens)
  • Vague sentiments (e.g. simplify requisition approval)

Sometimes business people "put-up and shut-up” - they don’t log tickets, they simply tolerate the way things are.

Proper use of backlogs to improve agile

One big backlog of technobabble - OSS notes and patches - won't get the business onside. Build backlogs that sit firmly on the business agenda.

Service Management: SAP Tickets vs. Portfolio Backlogs

One of the benefits of Kanban is that it visualises workflow. This drives overt prioritisation and leads to better resource management - because it’s easier to spot log-jams, it’s easy to shift resources to focus on them.

The doctrine of traditional IT Service Management (think ITIL) and traditional Service Level Agreements is that they force feed a queue of work into a team without really considering workload leveling or real prioritisation. Traditional ITSM is a push system - If 1,000 users log a P3, the team simply has to deal with them as per the SLA.

Pulling service to match capacity

Kanban is a pull system which promotes active prioritisation from a backlog. This means that workload is pulled into the team based on priority and capacity.

But in a DevOps world, and in a world where skills are not in infinite supply, sometimes it is better to invest in doing something better (e.g. fixing a workaround) overworking an endless backlog of tickets.

High performing SAP teams have realised that a shared functional team prioritising improvements and tickets based on a pull system drives higher business satisfaction with ERP solutions.

is it possible to run SAP projects using agile

ITIL was created in the 70s for the UK Central Government. In terms if it's fitness for an Agile world, there's nothing more to say.

Putting the excellence back into your CoE - For ERP, S/4HANA, and SAP

 

Many businesses simply view their CoE as an IT function — managing tickets, and support, and generally just keeping the systems ticking over. 

In this webinar - a highlight from our recent ASUG Live Event - we explore how your CoE can in fact be the driver for business change, and the engine room for delivering on your business strategy. 

Putting the excellence back into your CoE - For ERP, S/4HANA, and SAP