How to get started with Agile for SAP – 8 steps to success

I’ve written recently about the benefits an Agile development approach can bring to SAP and also some common misconceptions that are often voiced on this subject. 

Software is changing the face of business today, and the speed at which your business can innovate will often be determined by the speed at which software can change. Of course, the same applies to your competitors - whoever can manage change and deliver value most efficiently will have the commercial edge. Applying lean and Agile principles will optimize application development processes and remove waste.

And it’s not just customer facing “Systems of Engagement” that need to be changed quickly. In the digital age all applications need to be delivered faster - including SAP.

Here I’m going to take a look at how you can get started with Agile so that SAP development can be as responsive as the business needs it to be.

1. Understand what Agile is

This might sound obvious but it’s important to understand that Agile is not Waterfall.

Waterfall SAP projects are typically pre-planned with solutions designed up front. They are then delivered via a structured series of steps from development, through testing, regression and release.

Agile breaks projects up into smaller chunks that can be delivered in shorter iterations called sprints. A key difference here is that problems and solutions are not necessarily understood or documented up front. This might seem counter-intuitive in SAP, where things are often documented to a very detailed level before any work starts.

In Agile we have to learn to accept uncertainty and the fact that solutions evolve. Problems are managed as part of the process. The fact that we’re not tied to a spec allows us to question and adapt as we go, so the risk that we deliver the wrong thing is dramatically reduced.

2. Work out who your stakeholders are

Not everyone is going to think Agile is a good idea and support it. In fact, in SAP, there are many who will happily find many reasons not to do it.

So you need to look at who in the organization will be impacted and make sure to involve them in the process. Exec management, business owners, development and testing teams all need to be included. There will be people who you can rely on for support and there will be people you can expect to derail you. Understanding who these people are from day one will help you no end.

People need to understand what Agile means for them and what benefits and changes they can expect to see.

Some realism is also required. People may be expecting a ‘silver bullet’ that will cure all the problems with the current processes, and may quickly become disillusioned if this is not achieved. So you need to manage expectations and help people understand that adopting Agile is a journey.

In SAP projects I’ve seen most success where there are champions, both in management and project teams, to help get the message over and smooth out the inevitable bumps on that journey.

And once you’ve chosen a framework, for example, Scrum, it’s a great idea to run some training courses on the methodology and process so everyone understands how it’s going to work. The training should not be onerous - a couple of days should be enough.

3. Build a business case

Before you embark on an Agile transformation it’s important to understand what benefits it can bring so you can convince the powers that be that the idea is actually worth looking at.

Applications need to deliver business value quickly to promote innovation and increase competitiveness. Agile does this for SAP, and also brings responsiveness to change.

So take a look at your current state and ask some questions, like...

What does it cost to deliver applications now?

How much would it cost to delay application delivery?

What’s the cost to respond when a competitor takes market share because they got there first?

How much could faster delivery translate to in revenue terms?

What is the current cost of application failure and downtime?

How much do you spend on application development and testing?

How much waste is present, for example, in reworks where time is spent constantly testing and fixing?

Looking at historical data and timesheet bookings will help you to evaluate the time and cost of development and testing activity.

You can expect an Agile approach to reduce development cycles, improve quality and stability, add efficiency to the application delivery process and provide greater collaboration and feedback.

An Agile transition is not without cost but even conservative estimates on improvements can become a compelling business case to get started.

4. Start small

You can’t expect to switch over to Agile processes overnight and assume that everyone will be able to instantly adapt to new ways of working.

So it’s a good idea to start on something small and safe so you can learn and prove the process. It’s ok to make mistakes, try different approaches, and work out what works and what doesn’t as you go along.

Although Agile is a common approach it will be applied slightly differently in every organization so learn what works best for your specific teams.

A good recipe for adoption in SAP is to start out with one team as a nucleus, then branch out to others when you’ve got it nailed. When you can demonstrate success you can scale it to other teams to get them on board too.

5. Reorganize teams around projects and products

Traditionally in SAP we are used to handing over requirements to development, who then hand over to test teams, and then cycle around various other teams in an attempt to deliver what was asked for.

Agile requires that we address how teams are structured and interact with each other. As there’s not a detailed spec to work from you’ll need to have very open communication channels between team members, and you’re going to need trust.

You’ll want development and testing to work as one with a business representative overseeing things as a product owner / manager.

Successful adoption of Agile in SAP is often seen in the form of many smaller, multi-functional teams working together to deliver specific related requirements.

For fixes and smaller enhancements, this can work very well indeed as they can be delivered much faster and with more flexibility.

It works for larger projects too, though. Regardless of the fact that a programme may be delivered as a whole at some point in the future, there’s still a strong case for smaller units of delivery that enable the business to see results sooner (even accepting the need for an integrated testing phase at some point in the process).

6. Create a prioritized backlog

Agile focuses on business outcomes and working solutions, where a backlog of requirements is created in the form of user stories for specific personas.

This backlog should be prioritized so that stories that produce the most business benefit are planned to be addressed first. That means you need to look at what’s most important and what the dependencies are between requirements.

In SAP, due to the high level of integration between modules and processes, the management of dependencies is particularly important so you can understand what can be delivered independently, and what needs to go together. It’s also important to make user stories manageable so that they represent smaller, discrete portions of work.

The product owner needs to learn how to do this.

The backlog is not something that’s set in stone though - Agile provides the flexibility to adjust priorities and support scope changes, making them much easier to manage.

In SAP projects it’s a huge benefit to be able to respond to changes in priority and scope as you go along, rather than having a design and blueprint that’s fixed and won’t be delivered for many months.

In each iteration, it’s important that testing is a key part of the process so you can aim to deliver something tangible at the end.

7. Organize some sprint meetings

Agile promotes constant feedback so everyone understands what’s going on and where gentle redirection may be required:

Team members need to attend sprint planning sessions so that everyone understands what’s wanted and can estimate the effort required. Timebox them to an hour or two to keep people focused.

Short daily stand-ups need to be run so that everyone can report on progress and highlight issues and blockers. Keep it short (10-15 mins) and don’t try to solve problems in them.

After a sprint is finished you’ll need to have a retrospective session to review what was done (or not) and to look at areas for improvement. It’s really important to use this to improve and evolve the process.

Playback sessions can be used to present what’s been built to the organization. This is an important feedback loop and an opportunity to demonstrate achievements.

Accept that not everyone will be comfortable being in the spotlight or enthusiastic about changing - you’ll need to understand the personalities involved and ensure that everyone is supported.

Ultimately, this constant communication ensures that the business gets what they wanted even though, at the start, they might not have known exactly what that was.

8. Tools

You’ll need some tools to help you manage Agile processes.

This might start off as a big whiteboard and a selection of sticky notes to represent each user story. You can then physically move them around the board as they progress. This highly visible approach is great to start with as suddenly everyone can see exactly what’s happening.

When you’re more mature, dedicated tools like Jira and Rally can be used to manage the process and provide the required workflows and reporting.

But you also need to think about SAP itself and how you’re going to manage all those transports. A mature change tool that can manage and automate transports and ensure that dependencies are handled correctly is a must for larger SAP projects.

It takes time to adopt and trust Agile processes. In my experience, it can take at least a year to embed the process and cultural changes needed to make this successful but the high levels of engagement, transparency, flexibility and responsiveness are hard to argue against.

If you’re looking to get started but are meeting people who put barriers up and say it can’t be done, take a look this eBook on some of the most common misconceptions about Agile for SAP and how you can start to challenge them.