SAP TechEd talk on the Magic of Scrum in the SAP world

Magic of scrum with SAP from Twan van den Broek

At SAP TechEd in Madrid I hosted two expert sessions, EXP299 and EXP300, to share real life project experiences on doing scrum with SAP projects.

Interesting discussions, as most of the times the following questions arise:

• SAP projects can't be done with scrum, they're just too big
• How can you start a project without blueprinting
• How can you start sprinting without specifications
• An SAP team is formed with specialists, how to deal with that
• Multiple business representatives are involved, multiple product owners?

Let me try to answer them shortly.

SAP projects just too big?

SAP projects can be big, cover a multi year implementation strategy, but it's just a way of splitting large programs into smaller projects that can be understood by everyone involved. Scrum supports you in focusing, what adds the most business value, it's better to work on something that you can oversee than on something that you might need in 4 or 5 years.
And of course with scrum you can have multiple teams running in parallel, each with their own goals, the scrum-of-scrums approach.
What about the die-hard SAP consultant stressing out that processes take longer than a sprint. To them I'd like to say - think of how to break an end-to-end processes into small pieces. It might feel a bit strange, but you'll manage ;-)

Start without a blueprint? Sprint without specifications?

How is that possible? Of course you need a starting point, the business case needs to be clear to your team(s). How else can they translate into a product backlog. So there is a sprint 0 to understand what the project is to deliver. Time boxed  of course, take 2 or 4 weeks to understand the scope and create your product backlog. A list with user stories or use cases describe what is to be delivered on a high level basis. And when you start your sprint, start with designing the use cases that you want to start (highest prio) with. That's how it works.

Team with specialists?

But hey, an SAP team is built with multiple specialists in stead of a multi disciplinary consultants. And yes an ABAP consultant will not do Finance customizing, as the Finance consultant will not do PI mappings, ... and so on. Decide whether your team is going to handle end-to-end processes, you will have a multi disciplinary team. Or, in bigger projects quite common, have process teams with specialists, like Finance, Logistics, ...
It will work, either what choice you make. Just as important as in every other (non scrum based) SAP project - integration is key! Collaboration - even within a team - is not obvious. As a scrum master you have to facilitate that. And in case you have multiple scrum teams running in parallel: make sure that these teams cooperate in a 'scrum of scrums' set up.

Multiple product owners?

In an SAP project there are multiple business owners active. SAP is about end-2-end processes, so it's quite logical that there is not just one business representative. If you translate that to scrum, it just might happen that you have multiple product owners. For the real 'scrumdamentalists' this must look like hell. Then again, be pragmatic, if you have multiple product owners, just make sure they all head the same direction. I planned a weekly 'scrum of scrums' session with my 4 product owners, just to align our joined route.

Remember, scrum is no silver bullet. Start doing it by the books, get yourself some coaching and enjoy the ride!