Do you think Agile can’t work with SAP? 7 myths debunked

[jamesroberts]

In my last post I talked about the benefits and value an Agile delivery model can bring to a business running SAP.  It’s a topic that’s on my mind a lot at the moment as I’ve been working with several companies who have seen tremendous benefits following a transition to Agile development in their SAP environments.

However, there are still many people who believe that modern application delivery processes like Agile and DevOps simply don’t or can’t apply to SAP, despite the evidence to the contrary.

The fact is that many modern IT organisations are under enormous pressure to deliver business benefits more quickly, and old ways of working simply no longer cut it.

In this post I’m going to highlight the most common myths and misconceptions that can hold back adoption of Agile methods for SAP.

 

Myth #1:  Stability and resilience are key.  Agile just adds risk

SAP systems have been built on stability and resilience and as such there’s a common perception is that they shouldn’t be changed quickly - a perception fundamentally driven by the fear (and consequences) of breaking things!

Of course it’s true that SAP is regarded as a System of Record, but in many cases it’s also a System of Differentiation or Innovation that directly enables more visible systems such as websites and mobile apps.  Businesses and their customers are demanding more and more from these Systems of Engagement, which are constantly changing in response.  SAP systems need to move at a corresponding pace if they are to continue providing the valuable differentiation that sets a business apart from its peers.

Agile processes and tools enable SAP developers to meet the apparently contradictory requirements for system resilience and rapid change.  And in fact the smaller incremental changes seen in Agile are actually far less risky to manage and deploy.

 

Myth #2:  Agile can’t provide the compliance, documentation and approvals we need

OK, there’s no doubt that certain industry sectors like healthcare, or government, require a lot more compliance, governance and documentation.  At first glance this may seem to be at odds with an Agile approach but in fact that’s not the case.

Agile makes engineering and development processes much more efficient, which means that the right solutions can be delivered more quickly - a beneficial outcome even in regulated industries where specific documentation and compliance are required.

Regardless of mandated processes, you're more likely to be testing, approving and documenting things sooner with an Agile approach, especially if you embed the right amount of regulation and industry knowledge in the development team.  This accelerated pace of change also allows organizations to respond more quickly when legislation changes - potentially a commercial advantage; certainly a way to reduce risk.

 

Myth #3: ASAP works well - there’s no need to reinvent the wheel

The ASAP methodology has been around for many years and has been the bedrock of many an SAP implementation project where it has worked perfectly well for waterfall approaches.  So why change something that already works?

Well, where more agility and responsiveness is needed - as is the case more and more often these days - companies are looking for alternative approaches.  That’s where Agile can come in.  I've seen Agile approaches work very well in some huge organizations that run SAP, though it can admittedly take time to get it right.

The digital age is forcing companies to adopt better ways of delivering software so they can remain competitive.  It’s unavoidable that this will bring newer methodologies like Agile and DevOps to the forefront.

 

Myth #4:  A hybrid Waterfall+Agile approach is better

There is often a reluctance to take steps towards Agile without definitive proof that it works - a chicken-and-egg situation that results in Agile being seen as an unknown quantity.  The fixed price and pre-budgeted projects that are commonplace for SAP can also be a barrier.

One solution in this situation may be to ‘sample’ Agile in specific parts of the development process, via a ‘Water-Agile-Fall’ approach.  Here the build phase of the project is carried out in iterations whilst the design phase and full integration testing proceed in the normal manner.

This hybrid approach can be used to retain the familiar up-front planning and budgeting, and the downstream testing and release afterwards.  And as the process matures it will start to generate the empirical evidence that is needed to gain traction and expand into the other parts of SAP project delivery.

 

Myth #5:  SAP can’t be broken down into smaller chunks

A key feature of SAP is that there is a large amount of integration between business processes, which may be distributed across different teams and functional areas, with limited collaboration between them.  This situation often reinforces the idea that Agile can’t work.

However, a major success factor in a situation like this is a clear understanding of the dependencies across the solution, so that they can be managed effectively and focus remains on the required business outcomes.  Part of this understanding comes from a clear view of how teams are structured, so it’s vital to have business and architectural knowledge as part of the solution delivery.

Agile really helps in this situation.  Effective backlog management and sprint planning ensure that dependencies between processes and teams can be well managed, resulting in requirements that are implemented in the right order, and maintenance of solution integrity.

 

Myth #6:  Agile doesn’t work for greenfield implementations

It is often said that Agile can work in SAP, but not if you’re a greenfield implementation or rolling out a major programme of work, where there’s just too much to manage.

It’s true that in this case the project could last many months, or even years, before a solution is delivered for use in production.

But that doesn’t mean that the business should have to wait months before they get their eyes in front of, and hands on, what’s being built.  That’s a recipe for failure.

Agile, in this scenario, integrates the business into the process from the start so they can act as product owners and constantly steer development and configuration.  They also get to see and test what’s been built at an early stage, avoiding the lengthy development of sub-optimal solutions that might be seen in Waterfall approaches where the business has no visibility of outcomes until final project delivery.

 

Myth #7:  Agile doesn’t work with outsourced and offshore teams

In many SAP organisations teams are distributed, and often comprise a mixture of outsourced vendors.  This can prove a challenge to the adoption of Agile due to the perception that communication will be hampered if team members are not in the same room.

The first step in jumping over this hurdle is simply for teams and partners to be open to Agile methods. This may already be the case, or it might need some work, but this attitude is becoming commonplace for most vendors, since support for Agile and similar methods is necessary to remain competitive.

In fact, Agile can actually be a benefit in this distributed model.  Daily scrums, along with planning and retrospective meetings, ensure that all team members are aligned with the product owner.  They understand priorities and dependencies, and have constant communication and checkpoints, enabling risks to be managed more effectively, thereby addressing the key risk with the offshore model - communication breakdown.

 

Conclusions

Resistance towards a move to Agile is understandable, especially in SAP where it still hasn’t been seen very often.

To make Agile work you need to have the right people with a mix of functional and technical skills, who are open to working in a different way and can be trusted to do just that.  It will take time to adapt, but it can be done!

SAP projects are often long and complex, and the planned approach typically taken to development gives a feeling of confidence, security and risk mitigation.  In this scenario many people feel that a Waterfall approach is best.  In reality though, Waterfall is possible in this case but is not necessarily the best, because you still have long phases where there is little or no feedback.

Actually, the more there is to deliver, the better an Agile approach can be.  In complex systems like SAP there are often many things that can’t be anticipated.  This is where Agile excels:  as a method for dealing with the stuff you simply can’t plan.

If you’re interested in Agile for SAP - or maybe this post has convinced you that it’s worth looking into - take a look at this eBook for more reasons why an Agile approach is worthwhile.