5 reasons why you need an agile delivery model for SAP

[jamesroberts]

I’ve talked a lot recently (and read even more) about the developing digital economy and how it’s driving a big change in the way applications and infrastructure are provisioned and delivered.

But what if you’re running applications like SAP and the digital transformation doesn’t have a direct impact on you, at least not right now?

Perhaps you’re focussed on trying to improve operational efficiency and implement process improvements, and you want to be able to deliver them with the minimum of disruption.

In that case you might be wondering why methodologies like Agile, lean, DevOps and continuous delivery have any relevance - you already have robust processes in place to deliver applications in a traditional way, after all.

 

The answer is the early delivery of business value.

There’s nothing inherently wrong with delivering applications in a waterfall fashion, where they’re pre-planned, budgeted and have a well defined scope, but just because it’s done in this way doesn’t mean that risk is removed.

In large releases...

• The business waits a long time to get new features, so people get frustrated;


• It’s difficult to change direction or refine what was asked for;


• There are high levels of business impact and testing;


• Recovery from failure is difficult and time consuming due to the volume of changes deployed all at once - so there’s less time to build new features.

A more agile way of managing application changes allows requirements to be delivered to the business in shorter, more frequent releases.

So what’s so good about that and why should you do it?

 

1. Fail fast and respond

In traditional development requirements are documented up-front based on what people think they want at that time.  When the project gets delivered - often many months later - stakeholders realise that things don’t work as they expected or, even worse, it’s taken so long to deliver that they’re no longer relevant.

In addition to this, day-one obsolescence and the spectre of ‘feature creep’ can hang over long-running projects.  More and more requirements are “discovered” during design, build and test, becoming increasingly hard to accommodate.

One of the key benefits of an agile approach is that requirements are delivered faster so the business can benefit from them far sooner.  And, even if they don’t quite work right, fast feedback loops enable constant improvement.

Agile development permits the business to experience this delivery “failure” and learn from it so that less time is wasted building things that no one wants.  It allows testing of what’s been built to ensure that it meets business needs - in the “old world” nothing would have been seen until the end of a long project many months later, with little or no opportunity to make changes.

 

2. Smaller chunks reduce risk and impact

With big releases comes big risk and big impact.

Deploying hundreds or thousands of changes at once might seem like a better way of doing things but it’s hugely risky and there’s a high impact on the business - adoption of many new features and processes requires considerable effort.

Breaking down releases into smaller, manageable chunks takes away a large risk element.  It makes testing and user adoption far simpler and allows immediate deployment of distinct changes when they’re ready to go.

Of course, some analysis of existing business processes is required in order to fully understand the impact of more frequent deployment, but this approach means that changes can be accepted into production much faster.

 

3. Avoid temporary (permanent) workarounds

When the pace of change is slow people naturally attempt to build creative solutions that can work around the bottleneck and be delivered more quickly.

Unfortunately most of these temporary workarounds don’t operate in an optimal way.  It’s all too easy for them to become permanently embedded into processes, creating large levels of technical debt and a high cost to maintain and run.

If workarounds can be avoided because the delivery pipeline moves faster, not only will solutions be more efficient but they’ll be easier and cheaper to run in the long term as well.

 

4. Visibility, Control & Measurement

In traditional development the testing is largely done in one big lump at the end.  That means it’s almost impossible to know the current status of anything or to anticipate and manage issues as they arise.

Agile processes promote transparency through the involvement of all stakeholders on a day-to-day basis.  Business requirements live in a constantly updated and prioritized product backlog and in each iteration it’s easy to see what’s been done, what needs to be done and what the risks and blockers are. 

As users are actively involved they can steer development at every step of the way.  And if requirements change it’s much easier for the team to shift attention to higher priorities.

 

5. Fast recovery from failure

So what do you do when something goes wrong after the deployment of a project?  It’s really hard to measure and recover from failure when changing many things in each release.

The smaller deployments that come with agile processes make it far easier and faster to unpick any issues and provide the necessary resolutions.

The risk and uncertainty that surrounds massive deployments is almost eliminated, freeing more time to spend building new features and create business value.

An efficient IT delivery model

So, the methodologies I mentioned earlier are not just about supporting digital transformation.  Agile and DevOps support a much more efficient IT delivery model that’s designed to give the business exactly what it needs, when it needs it.

When applied to SAP this can transform what is all to often a slow and inflexible way of delivering business value.

And who wouldn’t want that?

For more information on how to run Agile development for SAP please download this eBook here.