Agile SAP by Sean Robson by Sean Robson - Read Online
Agile SAP
0% of Agile SAP completed




Many SAP projects use waterfall methodologies, but these often run into budgeting and scheduling problems. In this unique book, Sean Robson presents ways of improving SAP implementations and offers practical advice on the most effective way to see a project through from beginning to end. Basing his strategies on the twelve principles of the Agile Manifesto, and drawing on his vast experience, he particularly focuses on the use of Scrum and Kanban and their suitability for certain types of projects, enabling you to select the most appropriate method for the task in hand.

Published: itgovernance on
ISBN: 9781849284479
List price: $37.99
Availability for Agile SAP by Sean Robson by Sean Robson
With a 30 day free trial you can read online for free
  1. This book can be read on up to 6 mobile devices.


Book Preview

Agile SAP - Sean Robson

You've reached the end of this preview. Sign up to read more!
Page 1 of 1



I am hoping that you picked up this book because you are looking at a way to avoid the pitfalls of waterfall. I believe that most of us understand the issues of waterfall, but it is useful to have a brief discussion of some of the major issues, to remind us why we need to change our approach.

Most traditional projects run over budget. It is very difficult to achieve valid estimates for a complex SAP project, even at blueprint completion, so we acknowledge the difficulty during business case development. The issue with traditional approaches to projects is that there is no escape valve. The BDUF (Big Design Up Front) blueprint approach attempts to identify all possible scope and design details for a project, prior to beginning any development. Once development begins, the directive to the project is to deliver all scope identified during blueprint. This means that if the budget cap is reached before all development is done, the project has no choice but to ask for more funds.

The odds are stacked against the project. It is almost certainly guaranteed that the details identified during blueprint will need to be revisited during realization. This occurs because of the time difference between when requirements were captured, and when they were delivered. It also occurs because a client’s understanding of SAP is minimal during blueprint, so they are unable to adequately express their detailed requirements upfront. It is only when testing a particular piece of functionality that the client is able to understand that requirements were missed. At this point, the team, for all purposes, must return to the blueprinting process, recapture requirements, redesign, and reconfigure or redevelop the solution. Change requests are issued for additional funds, and the result is an extension of budget and schedule.

Traditional projects are painful to schedule. They are scheduled using technical tasks, and the expectation is that all tasks will be correctly identified, scheduled and resource leveled upfront. Since most SAP projects are of several months duration, this is a massive undertaking, that requires continual updates to the plan. For this reason, traditional projects have a huge management overhead to take care of the burden of continual planning and status monitoring. As we’ll learn later, Agile considers management overhead to be one of the largest sources of waste on a project.

Traditional projects are painful to participate in. Teams are often built in silos, and become competitive because of the way traditional SAP projects are structured along technical lines. As tasks run late, the downstream teams are unable to complete their work. Finger pointing results, and it is difficult to maintain a collaborative approach. Given that projects often run late, the team ends up having to multitask which further increases project stress. Overtime is common towards the end of a traditional project, as teams fight to meet critical milestone dates. The workload is intense, largely because all integration testing is left until the very end of the project.

The benefit of Agile is that if solution complexities are discovered during realization, an iterative delivery approach provides the executive with a better decision making mechanism. Using 80/20, and an assessment of value delivered to date, they can make decisions at checkpoints throughout the project, to decide where to continue spending. If schedule issues are encountered, an Agile approach allows us to deliver higher value items within budget. The client can then decide whether the remaining scope warrants additional spend. This compares to waterfall, where a client has no choice but to continue spend in order to derive value, since nothing is delivered until the end.

Although this locking in effect of waterfall can be useful in the short term to maintain sales in a vendor implementation, it can damage the potential for long term sales. Through early delivery and a collaborative team approach, you can better secure customer commitment. Given that SAP customers are continually adding modules and upgrading, a long term customer loyalty approach is more likely to gain repeat business.


This section provides an overview of Scrum and Kanban. These two approaches are considerably different, and each has their place, depending on a number of criteria. Following an overview of the two approaches, I provide you with the information you need in order to select the correct approach.


Scrum was developed by Jeff Sutherland and Ken Schwaber in the early 1990s. It is an approach that most readers will be familiar with, because it uses time boxed iterations. When most people think of Agile, they think of dividing the project functionality into iterations of a couple of weeks, to one month. Scrum calls its iterations, sprints, and the goal of each sprint is to build a tested, workable piece of the system, that is ready to be released to production.

Scrum uses what is called a product backlog, to collect requirements and manage the scope. Each sprint builds a selected set of items from the backlog. A product owner is assigned to the project, and it is their responsibility to prioritize the backlog, to ensure that high value items are built first. Each sprint begins with a sprint planning meeting, where the product owner tells the team his preferred list of work for the sprint. The team then negotiates the sprint scope, based on their estimates. A conversation then ensues where the team gains a high level understanding of the selected backlog items, and creates an initial draft of the tasks required to complete each selected item.

A unique aspect of Scrum is its approach to teams. There are no unique roles in Scrum, other than developer, ScrumMaster and product owner. The ScrumMaster is responsible for helping everyone understand the rules of Scrum, and is primarily involved in removing blocks that prevent the team from getting their work completed. The product owner is responsible for defining the project vision, deliverables and priorities. Other than the ScrumMaster and product owner, all other team members are referred to as developers. The reason behind this is to maximize collaboration within the team. The objective is for every team member to be able to perform every task on the project. This means that any one person should be able to perform requirements and design analysis, code, configure, test and write documentation. This generalization causes issues in the specialized world of SAP configuration (more on this later).

Although their recommended team sizes vary slightly, most Scrum experts agree that smaller teams perform better. Cohn cites a study of 491 projects that looked at the performance of teams varying from 1 team member up to 20 (Succeeding with Agile: Software Development Using Scrum). The study found that a five to seven person team will complete an equivalently sized project in the shortest amount of time. Jeff Sutherland writes that the team in Scrum is seven, plus or minus two people (Scrum Handbook). Due to the smaller team size, Scrum has a method of coordinating projects of larger sizes and refers to this as a Scrum of Scrums. A Scrum of Scrums involves ScrumMasters from each team meeting to coordinate work between the teams. In the Scrum of Scrum approach, planning must include careful consideration of dependencies between the teams, to help ensure that each team can proceed independently on their work as much as