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?
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.
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.
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.
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.
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.
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)
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.
Be more successful on your next SAP project.
If you're about to start an SAP or ERP programme, you need the SAP success report.
This research outlines 15 key success levers that will help you deliver your programme on budget, on plan and on value.
