Agile/Scrum in SAP implementation projects

Sprint length

Let’s start with the sprint length. The length you choose has a big influence on the whole scrum experience. Usually scrum proponents prefer a shorter one because as a team you learn quicker as there are more frequent retrospectives and more importantly you are forced to work with smaller stories, which contributes to a steeper learning curve and makes it easier and less risky to write and size follow-up stories.

Scrum skeptics usually prefer a longer length because it enables them to work more in a waterfall way and they think it’s more efficient. They feel the overhead of the scrum ceremonies is much larger when the sprint length is short. Although officially this is not true, because their duration depend on the sprint length, in practice this is absolutely my experience. In longer sprints it’s easier to combine stories in one demo which makes both preparation and presentation time shorter. But also grooming and sprint planning takes longer: we lost quite some time in discussions to cut larger stories into smaller pieces and agreeing on the scope of each. The shorter the sprints are, the more often you need to do this.

And with shorter sprints there is of course less room for delay. When you need help or input from others this forces you to push people to respond quickly. Scrum proponents would probably say this is a clear opportunity to improve internal procedures, but in practice this is not so straightforward or easy. Especially if it concerns people outside your team, with whom you don’t have a close working relationship, I found it really uncomfortable to chase them.

So what did we decide? Well, we started with a few sprints of two weeks, which was perfect to start turning the wheel, get to know each other, implement the first stories and build the product backlog. But later we aligned with other scrum teams in the project and changed to three. This felt as a comfortable sprint length with enough time for meaningful stories and some room for delay due to impediments or dependencies on others. If the sprint length would be longer I think you would really loose the feeling of sprinting and ceremonies would take too long.

Working scrum

Now comes the challenging part: really working Agile/Scrum. In scrum you work on stories and you do this as a team. Together you groom them, you help and learn from each other, you divide the work and take-over each other’s tasks to get the work done. As a team you are responsible to completely finish a story and only then you will earn the points. Especially in the beginning we tried really hard to work like this as much as possible, but eventually we gradually shifted to a more traditional and individual way of working. I’m not saying what we did wasn’t scrum anymore, but the way we worked certainly changed.

I think there were two important underlying reasons why this happened: the members of the team (in scrum called developers) and the goal we needed to achieve. Our scrum team consisted of very skilled and experienced consultants, each with his own SAP specialism like CRM, BI and Finance. And in this project we were dealing with complex processes and business requirements with an ambitious go-live date. Quite normal for an SAP implementation project, don’t you think? Let me try to explain why this had an influence on the way we did scrum.

Grooming

We had weekly grooming sessions with the product owner to prepare our stories for the backlog and get them ready for the next sprint planning ceremony. Although in the first sprints we were able to write stories with sunny day end-to-end scenarios that required involvement of the whole team, quite soon stories concentrated on specific areas only. So, for example, when we were grooming a story for finance about the electronic bank statement of a certain country, only the finance consultants were really participating and the others more or less listened and waited until they finished. 

When it was time to size the story you more or less hoped you paid enough attention that your estimate didn’t deviate too much from that of the specialists. Of course, there were also examples that involvement of others had some positive contribution on improving a story, but this was quite rare. Because we were all so overloaded with work, I think many of us felt it was not always efficient to do all this with the whole team. Later we solved this problem to some extent by introducing separate pre-grooming sessions each focusing on a specific epic (area) with only those consultants involved and by using a story maturity model. Only stories of a certain maturity level were groomed in the central grooming ceremony.

Sprint planning and sprinting

Not surprisingly the same thing happened at sprint planning and during the sprint. As it didn’t make much sense for a CRM consultant to task or work on BI stories, we later did this more separately and in parallel. Nevertheless, to stick to the scrum methodology, at the end of the planning ceremony we always went over all stories together and did a sanity check on the tasks written down. We added or changed tasks where we found this was needed. And during the sprint, we of course tried to help each other to close a story, but the possibilities were limited: a CRM consultant usually can’t replace a BI consultant so easily.

My concerns with scrum

So we were working really scrum with only a few changes to make things work better and more efficient for our situation. But we never abandoned the essence or principles of the scrum method or violated the scrum guide. And although I felt that some things could still be improved, I really saw quite some advantages compared to other methods like waterfall.

But before we end here, I would like to share also two concerns I have with working scrum. The first one is the shared responsibility. In waterfall projects you normally see more hierarchy in roles and responsibilities. Lead consultants or architects are made responsible for a certain process, function or set of requirements and they make sure that their part is working end-to-end. They use their years of experience to lead discussions, build and deliver the solution in the right way and sequence and make sure nothing is forgotten.

In scrum this is more the responsibility of the product owner who usually doesn’t have that much experience with SAP projects. Of course, I see the advantages of having a whole team working on and contributing to stories together, but there should also be someone in the team who is responsible or feeling responsible for the entire solution or a certain area. The product owner is in charge of the stories and their priority, but regardless of how good your product owner is, he/she has so many things to deal with. 

You need developers (consultants) to take the lead also and assist and guide the product owner with the priority and content of stories especially if it concerns less visible, more technical, but vital parts of the solution. It’s easy to focus on the main process flow, but many things need to be in place to make this all work. I agree, maybe in the past we were too much relying on the IT consultants on what needed to be done, but you can’t ask the product owner to be able to write down all stories alone. I’m not saying this doesn’t happen with scrum, but with a full backlog of stories it’s possible that the focus is on working on that alone without thinking about what’s still missing for a successful go-live.

My second concern is the way scrum deals with the path to reach the desired end product. Scrum says it’s important to add value in every story, to build working products instead of designs or documents. With scrum it should be able to change the priority of the backlog without ending-up with unfinished products. It’s preferred to build working solutions and changing or extending them in follow-up stories. So if you want to have a car, it’s better to build a bicycle first, then a scooter and finally the car, instead of creating first a design and then building the chassis and the engine. From an agile or risk perspective this is of course a good approach, but I often see it requires much more time and rework. In many cases the product owner really wants a car and for him the bicycle or scooter is useless and doesn’t have any value. So often I think it’s better to start building the car from the beginning and invest the time that was saved in making it better.

Conclusion

So what’s my opinion on Agile/Scrum? Well, I think it’s a great method and it certainly has many advantages over traditional waterfall methods. But I think it’s also important to understand that scrum isn’t always the Holy Grail either. It should not work against you. So my advice would be to look at the specific needs of your project and team and check if you can use scrum in a way that works best. Much is possible without going against the scrum principles and violating the scrum guide. Good luck!