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:
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.