Agile SAP

Agile SAP: Introducing flexibility, transparency and speed to SAP implementations

SEAN ROBSON
Copyright Date: 2013
Published by: IT Governance Publishing
Pages: 208
https://www.jstor.org/stable/j.ctt5hh7ss
  • Cite this Item
  • Book Info
    Agile SAP
    Book Description:

    In this unique book, Sean Robson offers practical advice on the most effective way to see projects 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. As you read this book, you will learn how to build customer loyalty by delivering consistently high standards and offering greater flexibility and transparency. You will realize cost savings as you analyze your expenditure, reduce waste, and increase efficiencies in the delivery cycle. Effectiveness will increase as you promote greater inter-company collaboration and reduce the stress that so often accompanies large-scale projects. You will be able to eliminate unnecessary paperwork as you improve the clarity of requirements. Late projects, and those that exceed budget, will be a thing of the past!

    eISBN: 978-1-84928-446-2
    Subjects: Technology

Table of Contents

  1. Front Matter
    (pp. 1-4)
  2. FOREWORD
    (pp. 5-10)
    Jan Musil and Jeff Patton

    It was in late 2009, shortly after my team finalized a major revision of SAP’ s ASAP methodology for implementation. One of those long days where you go from meeting to meeting, in what seems like a big blur. One meeting stood out on that day. It was a call with two SAP project managers from a Nordic organization. They were telling me about their experience delivering an SAP implementation, in a very different way from our standard approach. The team used an Agile approach, based on SCRUM methodology, to deliver additional functionality to the customer. I was intrigued, after...

  3. PREFACE
    (pp. 11-17)
  4. ABOUT THE AUTHOR
    (pp. 18-18)
  5. ACKNOWLEDGEMENTS
    (pp. 19-19)
  6. Table of Contents
    (pp. 20-21)
  7. INTRODUCTION
    (pp. 22-24)

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

  8. CHAPTER 1: INTRODUCTION TO SCRUM AND KANBAN
    (pp. 25-32)

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

  9. CHAPTER 2: PROJECT CONCEPTION
    (pp. 33-52)

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

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

  10. CHAPTER 3: PROJECT PREPARATION
    (pp. 53-57)

    Project preparation in an Agile project has only a few differences from the waterfall approach.

    An initial attempt is made at identifying the Business Process Map, master data and organizational data, reports, interfaces, conversions, enhancements, forms and workflows (RICEFW).

    Key differences arise in the following deliverables: infrastructure, knowledge transfer, work environment and task tracking. In addition, the project charter needs to clarify these differences to ensure understanding between customer and project.

    On a typical SAP project, a sandbox is prepared for the start of blueprint, a development box is prepared for the start of realization, and a quality environment is...

  11. CHAPTER 4: BUSINESS BLUEPRINT
    (pp. 58-121)

    The main focus of Agile blueprinting is to build an initial product backlog, and accompanying documents, representing the main requirements for the project. To help clarify requirements, a baseline system can be built to validate requirements. Note that I have labeled these steps as ‘Iteration 0’ and ‘Iteration 1,’ whereas the new ASAP 8 Agile version defines Iteration 0 as the first iteration in realization. Although the nomenclature is different, the process is essentially the same. The demo system should reflect a subset of the backlog requirements and be leveraged in the realization phase. Blueprint is neither Scrum nor Kanban....

  12. CHAPTER 5: REALIZATION
    (pp. 122-194)

    Before getting into the build phase, it is important to revisit the issue of requirements. In an Agile project, the team has not gathered detailed requirements during blueprint. They have kept things “lean” and focused on ensuring they have captured all stories, but they have not gathered all details pertinent to each story.

    As an example, suppose the project is building the benefits module. During blueprint, the team captured the stories concerning savings plans, but did not go into the eligibility rules for savings plans, other than to capture a child story to solution eligibility rules. This is very different...

  13. CHAPTER 6: FINAL PREPARATION
    (pp. 195-197)

    In the standard ASAP methodology, the purpose of final preparation is to finalize business preparedness, deliver training, prepare for the transition to production support and perform cutover. In Agile, the purpose and deliverables remain the same, with the difference being that we run final preparation for each release. In essence then, each release is a mini project. As part of each production release, the training documents and course schedule must be in place. A business readiness plan, including job restructuring needs, should have been completed, or be in the process of being completed. Your sustainment organization needs to be in...

  14. APPENDIX A: DEVELOPMENT APPROACH
    (pp. 198-200)
  15. FURTHER RESOURCES
    (pp. 201-204)
  16. ITG RESOURCES
    (pp. 205-208)