We at BestXperts did not adopt agile project management overnight. In fact, it took us years to come up with an approach that was both repeatable and scalable. At first we dispensed with the idea of massive upfront blueprinting and instead began to have many mini-cycles of blueprinting, realization and testing throughout the project. In the process, we started structuring our project schedules around “sprints” and conducting daily standups to facilitate active communication within project teams.
We quickly found out that if we kept our “user stories” at a really high level (otherwise known as “epic stories”) we could usually commit and successfully execute on a sprint, as long as sprints were on the longer side, the project teams were fairly small and the members of the team were experienced and cross-functional. Our typical epic story referred to a core business process or SAP best practice scenario, like “Sale from Stock” or “Purchasing”.
The problem with operating at an epic story level in an SAP implementation is that it doesn’t scale very well on larger projects, especially if you have your clients as active members of the project team. The lack of detail in user stories can cause critical business requirements to be missed and make it very challenging to incorporate junior and less experienced members into a project.
So we adjusted and started breaking down our epics into a large number of user stories, using a traditional story format – “As a WHO I need to WHAT so that I can WHY”. We saw some immediate benefits to this approach. Business users found it a lot easier to validate our understanding of business requirements when presented with a list of user stories in this format. At the same time, we were able to manage larger projects while successfully incorporating and giving out stories and tasks to less experienced members of the project team on the client side.
Up to that point we have been predominantly using the “Scrum” variation of agile project management. At the core of Scrum exists an understanding that each sprint has a finite duration (typically 6-8 weeks) and that user stories that are included in each sprint are defined up front and generally fixed for the duration of that sprint. Unfortunately, in projects where our clients wanted to play a larger role in the implementation and include their own internal staff in configuration and roll-out of SAP the Scrum approach ran into a couple of snags.
As soon as we started recording detailed user stories to capture business requirements we found it very hard to define all of them up front for each sprint, because so much of SAP implementation is about extracting, identifying and capturing business requirements as opposed to pure development and configuration. It is not uncommon to spend one week of blueprinting to identify just a few days of actual development and configuration work.
In addition, we found it more challenging to keep all sub-teams (sales, purchasing, finance, etc.) synced to the same sprint schedule, further increasing the violation of typical Scrum principles of sprint duration and scope.
So we decided to do some research into alternatives to Scrum. Within hours we came upon a wonderful book by Henrik Kniberg and Mattias Skarin:
Kanban and Scrum – making the most of both
We have not heard of the Kanban variation of agile project management up to that point, but as soon as we started looking deeper into it we had one of those “eureka” moments where after brainstorming on a white board for a couple of hours we came up with a general structure for a Kanban board in an SAP implementation that just made perfect sense.
With Kanban we would no longer try to fit our user stories into neat sprints but rather embrace the nature of SAP projects with their high volume and unpredictability of business requirements and treat all work as a continuous flow of user stories and focus on increasing the velocity of moving stories from inception to completion by limiting the amount of stories we take on at any given point in time.
So far, our experience with Kanban has been very positive. Both our own “xperts” and our clients seem to really enjoy this approach to managing SAP projects. We are planning on delivering a couple presentations at SAP conferences in the coming year on this subject and will share more details on how we get the job done with Kanban at BestXperts on this blog.
4 Comments
EricV
Nice post. Perhaps the greatest problem that I’ve seen the switch to Kanban improve is the unpredictability of the project. As always, things pop up in a project that you didn’t plan for and the fixed scope requirement of Scrum can become an issue. With Kanban the ability to react to changes in the moment without feeling like you “breaking the rules” is liberating. It forces the team to react NOW and leads to more satisfied users AND team members.
Amardeep Singh Sidhu
After working on large SAP Implementation Projects it becomes very difficult to even imagine that SAP Implementations can be ‘Agile’.
Above Post is an example that even the biggest Implementation Partners should start looking in this direction.
My Question is SAP has a standard ASAP (accelarated SAP) Methodology that almost every one in SAP business follows.Inspite of clear advantages of Agile framework over V-Model or Waterfall Framework why is every one still sticking with ASAP Framework?
AntonK
Amardeep,
We at BestXperts often ponder the same question. There is still surprisingly little interest in the SAP community towards agile. People seem to be satisfied with how things have been done for decades – bloated budgets, over-planning for the sake of planning, wrongful obsession with deadlines as the driver of results, and exhausting 80 hour work-weeks with poor morale.
I have my own theory on why SAP implementations are still stuck in Waterfall/ASAP-land. All of the waste and overhead related to detailed long-term schedules, WBS structures, gantt charts and spreadsheets that come with a waterfall implementation has created a whole industry of handsomely paid SAP “professionals” who for obvious reasons have an intrinsic interest in keeping things the way they are. We’ve come across a fair share of such “professionals” in our own SAP projects over the years.
As I’ve mentioned in one of my other blog posts, the folks who typically have the hardest time with “agile” are managers and project managers. The people who do the actual work and customers who use the software are typically very happy with the agile process. But managers often have difficulty with finding their “niche” in the new paradigm. Many of the things that they used to manage around detailed planning, scheduling and task management are greatly minimized or no longer necessary at all. Leadership skills become the most critical factor. Unfortunately not every manager is an effective leader. And since managers and project managers are usually the main decision makers in IT organizations, this presents a real challenge for agile adoption.
Christian Koch
Hi Anton,Currently I try to figure out if, and if yes, how agile methods could be adapted to a SAP project. So I found your blog entry. Would be great if we could get in contact; I would be very interested in the presentations you mentioned (and wouldn’t have a problem to pay for it;-). I also have a lot of questions how the ‘management part’ (budget, time frames etc.) was solved with this method.
Cheers
Chris