Agile SAP

Introducing flexibility, transparency and speed to SAP implementations

Sean Robson

• Publisher: IT Governance Publishing
• Year: 2013
• eBook ISBN: 9781849284479
• Topic: Computer Science
• Subtopic: Desktop Applications
• Index: Computer Science

Deliver your projects on time and to budget

The use of Agile methods to implement SAP is a relatively new approach and one that has proven to be very successful. Agile techniques can greatly improve your SAP implementations, reduce risks, and help you bring your projects in on schedule and within budget.

Invaluable practical advice

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.

Apply it to your projects

As you read this book, you will understand how to:

• Bring your SAP projects in on time and within budget
• Build more flexibility and transparency in to your implementations, enabling you to adapt more quickly to your clients' needs
• Realize cost savings as you analyze your expenditure, reduce waste and increase efficiencies in the delivery cycle
• Increase customer loyalty as you adopt 'best practice' in order to maintain consistently high standards
• Work more effectively as you increase collaboration within the company and reduce the stress that so often accompanies large-scale projects
• Improve clarity of requirements and eliminate unnecessary paperwork.

Buy this book and bring your SAP projects in on time and on budget

CHAPTER 1: INTRODUCTION TO SCRUM AND KANBAN

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

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

Another key item of Scrum concerns the notion of velocity. Scrum believes that only historical performance, or velocity, is a valid predictor of future performance. It uses the number of completed stories (features) per sprint, to estimate the team’s ability to complete deliverables.

A good overview of Scrum can be found at www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf.

Kanban

Kanban has its origins in lean, and just in time, manufacturing processes. In Japanese, the term Kanban refers to a “signal card.” In manufacturing, the signal card is used to inform an upstream process that more of the product is needed by the downstream process doing the signaling. A person doesn’t begin any new work unless they have received a signal that more of the product is needed from their work step. Kanban was developed as a mechanism to help control scheduling of the work needed to produce a product. It serves a number of key purposes which center around visualizing work, so that producers know what needs to be produced, when it needs to be produced, and how much to produce.

David Anderson took Kanban principles and applied them to software production (Kanban: Successful Evolutionary Change for Your Technology Business). He found that the core principles of Kanban served well to help address issues of waterfall software production. Specifically, Anderson was able to define a Kanban approach to software that allows its users to improve throughput and reduce leadtime.

Increasing throughput is an important goal for every project manager. In software, throughput is the number of work items completed in a given time period. Another goal of software project managers is to reduce leadtime. Leadtime is very similar to duration. According to Anderson, leadtime measures the duration “from starting a feature to completing it” (Kanban: Successful Evolutionary Change for Your Technology Business).

By increasing throughput, the project is able to get more work done in a given time period. By decreasing leadtime, the project is able to more quickly deliver value to the customer. Anderson recommends a number of lean techniques to improve throughput and leadtime. These include, for example, reducing multitasking, addressing bottlenecks and roadblocks, and reducing waste.

We all know the perils of multitasking. Multitasking is a good way to do many things poorly. Yet on almost all projects we, as project managers, find ourselves overloading our team and asking them to get more done in less time. We try to pretend that the team has more capacity than it truly has. Once we start that method of working, it spirals, and we find that we can never catch up, because the team ends up with a stack of items in process that never seem to move to “done.” It is known that people become progressively less effective and less efficient with more concurrent tasks. On a software project this is revealed in lower quality work, and an increase in unfinished work. Kanban addresses this issue by recommending we define Work In Progress (WIP) limits for each of our work item types. A Kanban board visually shows how much work is in progress, and gives us a simple checking mechanism to ensure that the WIP limits are respected.

Kanban also provides us with a mechanism to address bottlenecks. Bottlenecks reveal themselves on a board when we see that a stack of work items has piled up at a given resource. The project’s job at that point is to identify methods to relieve the bottleneck. Methods can include, for example, improving our upstream processes to ensure that work arrives in a “ready to work on” state at the bottleneck point. If our bottleneck is a programmer, then we will want to ensure, for example, that test specifications are in a good finished state, so that the programmer does not require as much back and forth communication with the analyst. Another method is to redesign the work, so that the bottleneck does not have as much work on their plate. We can, for example, have non bottleneck configurators take on some of the bottleneck configuration, so that the bottleneck resource is not as overloaded. On one project I had a bottleneck in one module, and we took careful attention to review each work item assigned to the bottleneck to determine whether another team member had the necessary knowledge to take ownership of an item.

Blocks occur when a work item is unable to move forward, typically due to a late dependent item. In SAP this often occurs between modules, or between the development and configuration team when tasks run late. Avoiding and managing blocks requires careful planning of work dependencies in the backlog. If configuration work items run late, and the development team is started too early, then the development team will spend a lot of time “blocked” by the lack of configuration. The Kanban board can be used to quickly highlight these blocks and focus the team’s efforts on working to resolve the block. In many cases the development team can help with testing of configuration, in order to speed up closure of the dependent configuration work. This requires an investment in cross training, but can pay dividends later (more on this later). The development team may also have analysts who can work with the business to clarify requirements for the configurator, so that the configurator can complete work items faster.

The structure of a Kanban board helps us communicate priorities to the team. The Kanban board begins with an input queue. The input queue should be loaded with just enough work from the product backlog to keep the team busy for a week, and it should receive only the next priority items from the backlog. This ensures that the team pulls priority work into their work in progress.

Kanban uses five core properties to improve software development:

•   Visualize workflow

•   Limit work in progress

•   Measure and manage flow

•   Make process policies explicit

•   Use models to recognize improvement opportunities (Kanban: Successful Evolutionary Change for Your Technology Business).

Later, I’ll show how each of these core properties can be used to improve an SAP project.

As in Scrum, Kanban believes that historical performance is your best predictor of future performance. In Kanban, one can use throughput, a measure of completed work items per time period, and leadtime, a measure of the duration it takes to complete a work item, to predict the time it will take to complete future work items.

If applying Kanban to your project, your team can benefit through a hands on, Kanban learning experience. There are numerous games that can be used to teach teams the value of using Kanban to manage project deliverables. These games typically teach participants the importance of pulling work through the system based on capacity, rather than pushing work through based on demand. One example game is the paper airplane game (www.shmula.com/paper-airplane-game-pull-systems-push-systems/8280/). By actively participating in such an exercise, the team learns that throughput and leadtime can be greatly improved by carefully managing WIP.

Scrum or Kanban?

Projects can really leverage Scrum when teams are colocated. Colocation is important in Scrum, because each person is expected to be able to work on any task relevant to the sprint. Being able to work on a task with another team member, or pick up a task when it is partly finished, requires good communication amongst team members. Although Scrum has been shown to work with distributed teams, it definitely is better suited to colocation.

Scrum also works better when the tasks are more generic and require fewer specialists. At its core, Scrum aims at improving throughput, by ensuring that each team member has the skill to work on any task in the sprint. In this sense, Scrum works best in an SAP project that is more development focused. Projects that are heavy in configuration require specialists, and Scrum is not designed to accept a high number of specialists. A sprint that has high dependence on one or two specialists can experience stalls, as other members wait for the specialists to complete predecessor tasks. This can arise on a project where one module has significant configuration scope, and the project lacks sufficient capacity in that module. A sprint can stall if it is waiting on one or two team members to complete predecessor configuration. It may be possible to schedule around this configuration, however, the risk of delays is much higher on downstream tasks.

Kanban does not have any prescribed roles. It layers on top of existing methodologies and is used to optimize and improve the existing processes. It can work for distributed teams because it allows for specialist roles. Kanban is not time boxed, and does not prescribe regularly scheduled demos (although I do recommend you use demos in Kanban and schedule them “as needed,” according to readiness and client needs). For these reasons, Kanban is useful for projects that have significant configuration elements and distributed teams.

CHAPTER 2: PROJECT CONCEPTION

Setting expectations

When initially defining the project approach to the sponsor, there are some key differences that should be highlighted to the client.

Working software over documentation

An Agile approach favors working software over documentation. What this really means is that we need to avoid documentation for documentation sake. In SAP, we typically create a high number of documents, and not all documents have direct value to the customer. In traditional SAP projects, customers wait a long time before seeing working software. Blueprint phases can be quite long, as the team attempts to gather all details and predict the required design. As you will see, an Agile blueprint phase can be much shorter, as we focus very critically to ensure the team works only on documentation that adds value. For new SAP customers, it is easier to present a one year project that has an Agile one month blueprint, for example. However, long time SAP customers might expect to see something like a three or four month blueprint, with the only blueprint deliverables being documentation, on a one year project. To overcome this bias, inform the client that the blueprint sign off is based on a combination of requirements documentation, and a baseline build to validate requirements (you will see that the baseline blueprint build is optional and depends on customer needs).

On a sample Agile one year project, blueprint might be planned at a reduced one or two months, depending on complexity. One month will be spent analyzing the as-is, gathering high level requirements and documenting the lean blueprint. An optional second month would be used to prepare a system demonstration, to allow the client to clarify their requirements, and the team to better understand the design. The shorter blueprint leaves more time in realization to focus on building working software, improving quality, and providing knowledge transfer to the client.

Templates should be shown to the client, since they will be much leaner than what the client may be used to. The trade off on accepting less documentation upfront, is lower costs on the project overall. Less time spent on documentation in blueprint, means less money spent on documents that will typically be read only once – at blueprint sign off. By reducing the upfront documentation, the client starts to see pay back sooner. We move more quickly into realization and through releases the client gets working software sooner. Details are captured during realization, at the time when the configuration and development take place.

This approach has several advantages for the customer. There is less risk of getting the design wrong, because the requirements gathering and design take place immediately prior to the actual build. The SAP specialist can more quickly demonstrate functionality to the client, thereby giving the client the information they need in order to clearly articulate requirements and validate the design. On traditional SAP projects, it can be months before the client sees working software and finally understands the system well enough to articulate requirements. In Agile we dramatically narrow the window between requirements collection and system demonstration.

If a company is serious about reducing the cost of the SAP implementation, they will be willing to forego lower value documentation in favor of working software. Typically, the organization’s opponents of this approach are found in the Information System (IS) department. The business understands they are paying for software – not documentation. IS departments, however, place a lot of value on documentation, because they still largely believe that detailed requirements and design for a project can be finalized and approved upfront. Upon reflection, they may agree that the end result often has significant variance from the documentation. At the same time, they feel safer having the project team commit to a large blueprint document. I recall being asked by one IS systems analyst how they could approve blueprint without all the details. This was when the blueprint documentation already numbered in the h...

Table of contents

• Cover
• Title
• Copyright
• Foreword
• Preface
• About The Author
• Acknowledgments
• Contents
• Introduction
• Chapter 1: Introduction to Scrum and Kanban
• Chapter 2: Project Conception
• Chapter 3: Project Preparation
• Chapter 4: Business Blueprint
• Chapter 5: Realization
• Chapter 6: Final Preparation
• Appendix A: Development Approach
• Further Resources
• ITG Resources