AGILE OR ASAP Framework of Implementation of SAP

Michael Veatch SAP Blog

Agile Implementation Considerations for SAP

think it’s safe to guess if you’ve been asked about going Agile on your next SAP project,
your response was along the lines of: “What are you talking about? Agile SAP? Now that is
an oxymoron if I’ve heard one. It doesn’t work that way.” I know that because I’ve had a lot
of recent conversations with customers and partners who are being asked about Agile by
their management, and the need to go for Agile or DevOps with SAP, and their response
frequently is, “We don’t really know how you can do that. What are your thoughts on that?”

Well, that’s a very common point, and in my experience with SAP projects, it was frequently
the case where we thought that Agile wasn’t really possible. The reality is that it can be
done, but not in the same sense that it is done in a custom development environment. SAP
is different. Enterprise apps are different.

SAP itself is adopting Agile as the approach to building its own products. We’ll look at how
that is affecting not just SAP’s products, but also how it affects SAP’s methodology and the
architecture of Solution Manager 7.2. Another point of reality is that Agile is coming and so
we have to get ready for it. Not adopting Agile has a cost. And that cost can be that you may
not be able to move as quickly in adopting SAP technologies and changes to the
technologies as rapidly as they’re coming out.

In the blog “Why DevOps Doesn’t Work for Enterprise Applications,” Worksoft CTO Shoeb
Javed boils down the difference in doing DevOps for Custom Apps vs. Enterprise Apps like
SAP to four key factors – size, operational focus, multiple stakeholders, and risks. If you
were to make an analogy, it would be similar to saying you want to make a change to a
house (Custom App) versus a change to an entire city (Enterprise App). One is very focused
and limited, the other has a much greater scale of impact, and much more that has to be
taken into consideration. You may be able to build or update your own house, but no one
can build or change a city on their own! With this in mind, we need to take the inherent
differences in size, scope, scale, impact, and risk into account as we embark on the journey
to Agile for SAP.
So How Do We Do Agile for SAP?

When we talk about “doing Agile for SAP,” I think it helps to group the considerations into
two buckets – technical and nontechnical considerations.

Technical Considerations

Technical considerations focus around the fact that the Software Development Lifecycle
(SDLC) is dramatically different for a packaged application like SAP versus a custom
application you build yourself. In the custom world, there is no delivered functioning
application; you have to build a functioning application yourself. In the SAP world, a

1
functioning application has been delivered to us by SAP. What we’re doing is we’re taking
that functioning application, understanding the requirements, and then doing a fit/gap
analysis. Then we’re taking that and going into the next set of exercises around process
design, configuration, and master data definition. Even though SAP delivers the application,
it has to be configured to meet the requirements of your business.

There will be some coding; you’re always going to have RICEF objects that you create, ABAP
coding that has to be done. But the core build activities really consist of building business
process that cross business units and span functional areas. Then there’s the testing, which
is a really significant part of the total project. A lot of organizations I talk to say that 60
percent of their project is testing. In the end, there’s a significant foundation that has to be
laid to deliver the minimal unit of functionality needed to provide business value. Trying to
package this up into a “story” for one person to complete in two weeks is just not going to
happen!

This brings us to the reason why many believe Agile won’t work for SAP. I fully agree that
Agile executed using the scrum methodology designed for custom apps is not going to work.
There are several key reasons why:

 SAP stories and functions are massive and cross functional and technical teams
 Complete business functionality has to be delivered
 Two four-week sprints to production are not possible
This is where the Scaled Agile Framework (SAFe) comes into play. SAFe 4.0 is an industry
framework that extends the Scrum Agile concept for large complex organizations. SAFe
adopts principles from lean and Scrum Agile and expands on them to better meet the needs
of complex organizations. It uses a tiered approach based on a release train, and within that
release train you do have the releases that are built on top of those iterations, sprints and
waves. But the key difference from Scrum is that the sprint isn’t artificially forced into
production. In the custom dev world, the perks of a sprint are to get that functionality into
production. SAFe recognizes that this is not necessarily viable in the enterprise application
world, and so instead, functionality is bundled into units. SAP has adopted many of the
concepts from SAFe, and you’ll see those showing up in Solution Manager 7.2. One key
point of Agile that SAP has adopted is that of the business getting hands-on with the
application earlier in the process.
Nontechnical Considerations

When people say, “Well, you can’t do Agile with SAP,” we want to make sure that we’re
making a distinction between what are some of those technical constraints of doing Agile
versus what are some of the nontechnical constraints. These non-technical constraints
include such things as:

 Coordination with Change Control Board (CCB)

 Coordination with organizational change management (OCM)
 Fiscal calendar “freeze” periods
 Regulatory/compliance policies
 Availability of infrastructure and SAP instances

2
In any SAP project, you always have to contend with the CCB and its schedule. There’s a lot
of rigor that’s placed around moving changes in an SAP environment, so that you don’t
disrupt the business. Many times the CCB uses a set schedule for approving changes, so if
we miss a meeting, we have to wait until the next one. Same thing with organizational
change. To implement Agile, organizations have to be able to adapt and really be able to
integrate changes across the business. One example of the organization adapting to Agile
would be to get the CCB to meet as the waves are released, instead of the waves having to
meet the CCB schedule.

In conclusion, when looking at Agile for SAP projects, organizations need to recognize that
Agile, as it applies to SAP, is different from Agile for custom development. Understanding
the differences is critical for setting and managing expectations, as well as for a successful
project. SAFe 4 provides a starting framework for adopting Agile. In my next blog, I’ll talk
more about best practices for implementing Agile for SAP. Or you can view the webcast I
recently recorded: “Agile Change Management for SAP.”

Wherever you are on your Agile journey for SAP, I’m interested in hearing about the
conversations you’ve had and what you’ve experienced.

From Waterfall to Agile in SAP Landscape

Oana-Maria Bocârnea in TSM magazine

One of the first decisions most projects face, regardless of the development landscape or
technology, is "Which development methodology should be used? What fits better for our
application and landscape?" This topic gets more and more attention and it's currently a
subject of debate. There are many articles debating if the developers creativity is not
restricted by adopting standard steps to be followed. This comes up as since the chosen
methodology determines how the project's development is organized. The two most known
methodologies are Waterfall and Agile. Although SAP has ASAP for ERP implementation, in
SAP software development Waterfall and Agile are both famous. The article will draw some
ideas around the way of choosing the best fit for the developed software in SAP world.

SAP Landscape : let's describe the world we live in

Due to the fact that the SAP world is not so familiar among software developers, let's cover
some basics. In the SAP world, a landscape is a set of servers on which the SAP software is
running on. This landscape can be divided into one or more environments, which are
separate, independently-operating instances of your SAP software system. Though these
environments are not dependent on each other, the content can be moved from one to
another using "transports". A transport contains the applications and configurations you
wish to move, together with some instructions for how to pack and unpack those contents.
All this might seem complicated, but it's a safety method. SAP is used to automate the
functions of a business, so if any part of that automation stops working, so do the
dependent business processes. To prevent this from happening, SAP recommends that you

3
put your system through a sequence of at least three environments: Development (DEV),
Quality Assurance (QAS), and Production (PRD).

These environments act like a filter, so that problems can be avoided in productive life. The
first filter is the DEV environment, where the applications and configurations are first
created. These objects are transported in the QAS environment for testing. In the QAS
environment, thebusiness functions are simulated in order to find the existing errors before
the solution gets productive. The encountered bugs are fixed in DEV system and the
solutions are transported again in QAS system for retest. The third environment is the
production environment (PRD.) PRD is what the customer uses and the final business
solution. The described model should help to avoid big problems during applications Go-
Live. Unforeseen problems that will pop up during the lifespan of the system will be fixed
through the same cycle.

SAP developed the ASAP (Accelerated SAP) methodology for project implementation to fit
to the described landscape. The Project implementation phases of ASAP are: Project
Preparation, Blueprinting, Realization, Final Preparation, Go- Live support and operate. It is
important to know that the ASAP phases generally follow each other and 70% of the tasks in
each phase are dependent on completion of the tasks in the previous phase, however some
tasks are carried out through all the phases. Since SAP has a big growth in cloud
development they have also introduced SAP Launch methodology and SAP Active
Implementation for their Cloud Portfolio. As any other landscape it can seem complicated
but once you get it, you get to enjoy it.

4
Waterfall and Agile Approaches
**Waterfall Model

Waterfall is a sequential, non-iterative software development model. It represents the most

structured implementation method, stepping through requirements, design, coding and
testing, steadily downwards.

Each of these steps represent a distinct stage of the software development and each one
finishes before the next one starts. This approach, as any other, offers advantages and
disadvantages.

Pros:

 Developers and customers agree on what will be delivered early in the development
lifecycle. This makes planning and design more straightforward.
 Due to the static nature and predictable scope, the progress is more easily
measured.
 Throughout the development effort, it's possible for various members of the team to
be involved or to continue with other work, depending on the active phase of the
project. For example, business analysts can learn about and document what needs
to be done, while the developers are working on other projects. Testers can prepare
test scripts from requirements documentation while coding is underway.
 Except for reviews, approvals, status meetings, etc., a customer presence is not
strictly required after the requirements phase.

5
  Because design is completed early in the development lifecycle, this approach lends
itself to projects where multiple software components must be designed (sometimes
in parallel) for integration with external systems.
 Finally, the software can be designed completely and more carefully, based on a
more complete understanding of all software deliverables.

Cons:

 Gathering requirements at the beginning is a risk. One of the most difficult parts of
software development can be to understand and document the customer
requirements. Customers often have difficulties to detail the specific of what they
need. It is also a challenge to make the customer visualize the application from the
requirements documentation. If this fails, the whole model fails, since change
requests are hard to handle.
 The biggest disadvantage is that waterfall is not change-friendly. The customer may
not see what will be delivered until it's almost finished. Therefore, there is a
possibility that the customer will be dissatisfied with the delivered software product.
By that time, changes can be difficult and costly to implement.

Agile Model

Agile is an iterative, team-based approach that emphasizes the rapid delivery of an

application in complete functional components.

The tasks and schedules are broken into small implements called sprints or iterations.
Iterations are short time frames ('time-boxed"). Each sprint has a defined duration, with a

6
running list of deliverables, planned at the beginning of it. If the planned work for the sprint
is not completed, then it is rescheduled for the next iteration planning.

The completed work can be reviewed and evaluated by the project team and customer,
through daily builds and end-of-sprint demos. Two of the most widely-used and known Agile
approaches are SCRUM and KANBAN. A Scrum process is distinguished from other Agile
processes by specific concepts and practices, divided into the three categories of Roles,
Artifacts and Time Boxes.

Some Advantages of the Agile approach are:

 Progress is measured in terms of working functions or products which can be

reviewed by the customer, so immediate feedback is available
 Customer ownership: by being involved in the project development as well as team
work.
 Changing requirements are welcome and don't make the development and delivery
harder
 Quality Improvement: by breaking down the project into manageable units, the
project team can focus on high-quality development, testing, and collaboration.
 Minimal Documentation: efforts for this are kept to a minimum, so more can be
involved in development
 Because each Sprint is a fixed duration, the cost is predictable and limited to the
amount of work that can be performed by the team in the fixed-schedule time box.

And, there are also some disadvantages:

7
  Agile works best when members of the development team are committed to the
project.
 The working relationships in an Agile project are easier to manage when the team
members are proficient in their role and also if located in the same physical space,
which is not always possible.
 Because Agile methodologies try to enforce a close communication between team
members it can lead to escalation of suppressed conflicts.

Learning by doing or "For the things we have to learn before we can do them, we learn by
doing them" (Aristotle).

For a better understanding of the decisions taken in the project, in which we have
experienced crossing from Waterfall to Agile, some history information is needed.

The ABAP Language (Advanced Business Application Programming, originally Allgemeiner

Berichts-Aufbereitungs-Prozessor, German for "general report creation processor") was
developed in 1980 as the report language for SAP. Until 1999, the language was a
procedural programming language and the SAP applications were procedural developed
apps (Reports, Function Groups and Transactions), which worked perfectly with the
Waterfall method. In the early and mid '90 the object oriented programming developed as
the dominant programming methodology, supported by the most known and powerful
programming languages like C++, Objective-C, Pascal, C# and many others. So, as the market
requested, SAP decided to extend the ABAP language to object orientation. This extension
was released in 1999 and it was called ABAP Objects. The focus of procedural programming
is to break down a programming task into a collection of variables, data structures, and
subroutines, whereas in object-oriented programming it is to break down a programming
task into objects that expose behavior (methods) and data (members or attributes) using
interfaces. The most important distinction is that while procedural programming uses
procedures to operate on data structures, object-oriented programming bundles the two
together, so an "object", which is an instance of a class, operates on its "own" data
structure. During the same period the software development methods evolved to
alternatives for the waterfall approach. For example in 1991 the rapid application
development (RAD) and in 1995 Agile-Scrum. We can say that the evolution of the
programming language exposed the necessity of new methodologies.

SAP started developing new applications in an object oriented landscape using also Agile
methods to organize the development, but they noticed that old applications needed also to
catch up to the new trend.

We have experienced such a change in 2011. A 20 year-old application developed in old

ABAP language using the Waterfall method was brought up to date while new features and
extensions were also added. Because the effort estimation and the following steps were
hard to document and predict, it was decided to use Agile-Scrum as the organization
method for this project. A lot of preparation work was needed in order to facilitate the
migration. There were many difficulties: starting from how to reuse what was already
developed, how to change the mindset of people who were reluctant to the new approach,

8
reduced costs, and so on. Another challenge was to bring teams together, since staff
members were located in 3 countries: Romania, Austria and Germany.

The application migrated and extended, is a healthcare information app and, therefore, it
needed to have long term maintenance. The old maintenance process did not fit to Agile-
Scrum since bugs and problems could not be split into sprints. Also the effort needed for
bug fixing is difficult to estimate since you first have to find the actual problem before
actually fixing it. Since the maintenance tickets had to be prioritized and an evidence of their
number was needed, parts of the Kanban approach were used.

Developers from Scrum teams have the following opinion about this experience: "On the
new development front, Scrum was a better fit. In most cases user stories were based on ten
year old functionality and in some cases continuing fresh development.

Since Scrum was new for everyone, including the Scrum Master, in the first six months we
adjusted the process at every sprint retrospective and finally settled on four week long sprint
and a week reserved for sprint review, planning and retrospective with stand ups on Tuesday
and Thursday. We also had to learn to calibrate our commitment to our actual velocity and
to calibrate the refinement of user stories so that any developer of the team could begin to
work on them. In short it took the team almost a year to achieve its potential velocity but it
also meant that developers specialized on parts of the project. The most helpful tool was the
so called Product Canvas introduced after the first release. It was a blueprint of the next
release that gave an overview of the task ahead and a target for release. After the first
release our team felt the need to have a big picture for the next one and we took a page
from the 'Waterfall' book and made a high level blueprint in a day or two before starting the
release plan." (Peter Tako)

The project is big and still continues to grow; it contains a lot of changes and modifications
and thus needs constant customer involvement. The Agile-Scrum methodology is currently
still in use, although we have to admit that Waterfall advantages are sometimes missed.
Luckily scrum allows tweaking the process if the team considers it helpful therefore the
development methodology evolves together with the project. This approach is a great
improvement over the rigid Waterfall model which greatly limits development teams in
their creativity. Still Agile-Scrum needs to be improved as big projects, such as ours, proves
that no methodology is perfect although it might seem so at first.

References:

 https://www.linkedin.com/pulse/sap-project-methodologies-transformation-from-
asap-waterfall-goel/
 https://blogs.sap.com/2015/11/23/sap-landscape-basics/
 http://events.asug.com/2011AC/
1608_Using_Agile_Approach_for_SAP_Implementation.pdf
 https://www.seguetech.com/waterfall-vs-agile-methodology/
 https://en.wikipedia.org/wiki/Agile_software_development
 https://en.wikipedia.org/wiki/Rapid_application_development
 https://en.wikipedia.org/wiki/Procedural_programming

9
  https://en.wikipedia.org/wiki/Object-oriented_programming
 https://en.wikipedia.org/wiki/Waterfall_model

Images

 http://1.bp.blogspot.com/-Rhk9BI7vU6o/VhTMsYq00PI/AAAAAAAAAPE/
kay4IqUkZxc/s1600/7.PNG
 https://cdn-8a82.kxcdn.com/wp-content/uploads/2017/02/
scrum_process_afa_5000.jpg
 http://cyclosys.com/Content/img/portfolio/agile-model.png
 https://narbit.files.wordpress.com/2012/06/waterfall_model_1.jpg

10
SAP Activate – with Agile, really works and save time?
Jarlei Nascimento Gonçalves

Announced at Saphire 2015 with the promise of replacing ASAP, it seems that Activate is
becoming a popular subject in SAP articles and being mentioned in Hana implementations –
please note this methodology is aimed for Hana projects (Cloud / OnPremise), but due to its
nature and procedures, it can be used for all types of project.

It is important to highlight that the correct name would not be “methodology”, but
“framework”, since its main cornerstones are best practices, guided configuration and
methodology as a whole.

 Best Practices
o Ready scenarios, optimized for S4Hana
o Best Practices for S4Hana integration/migration
o SAP BP creates processes or own processes

o Whether SAP is Cloud or OnPremise used, both will start with the Solution Builder
tool in order to activate Best Practices.

o Please note SAP cloud updates are faster and should be immediately implemented.

o For Cloud, the Expert Configuration may modify or add existing processes.

 Guided Configuration

11
 o Tools for assisted implementation
o Users and IT may access service tools for implementation
o Contextualized content and knowledge on what will be implemented

[Tools that may help delta customization à http://searchsap.techtarget.com/answer/Which-

SAP-Activate-tools-can-I-use-for-an-S-4HANA-Cloud-implementation]

Moreover, there is methodology, in which is possible to apply agile methods – this has to be
decided in the planning step, considering the company’s cultural understanding of Agile. Do
not try it if you do not know it.

Apparently, there is still some opposition regarding using Agile Methods for ERP, which may
pose a matter of company’s lack of practice or presentation and certainty. This article
presents a helpful point of view on the subject, besides the practical insight on the new
methodology adoption. Even though it is from 2016, which seems a lot of time, the
following article is an excellent reference: http://www.insidesap.com.au/can-the-agile-
methodology-actually-work-in-sap/.

My intention is not to detail this methodology, since it may be referred in several available
posts. In case you do not find appropriate links, please see the reference links for a detailed
explanation. In this article, we will focus on the Agile opportunities and insights, and talk
about the common mistakes related to simply accepting a task that you may not be ready
for.

12
The Agile methodology replaces or intends to replace the former model, ASAP, which used a
traditional BBP meeting method to develop solutions and seek understanding without yet
having the system. However, in this methodology system only arises after the BluePrint
phase, which takes a time, besides the arguable ASIS/TOBE evaluation.

In 2013, I had the opportunity to manage an SAP implementation project using the ASAP
RDS methodology, which shows a format similar to Activate – in other words, there is no
BBP, it is direct in the system, there is an initial system assessment before starting the
project and approval of what is being delivered, quality gates are well defined, etc. Its major
goal is to reduce complexity and present the system as faster as possible, mainly when
implementing projects in Brazil: the most cumbersome country to implement ERP due to its
legislation specificities.

Regarding that project, SAP was hired to do the Quality Assurance, verifying projects status
and taking steps in each Quality Gate. Moreover, I strongly recommend another company
taking care of the QA, since it makes a difference and may help a lot. In addition, do not hire

13
the same company that is implementing SAP. Instead, hire a QA-dedicated company,
formed of systematically expert employees, who are focused on project coordination,
recommendation, ideas and alternative options – which means management, project and
implementation experience.

However, there was not a Scrum presentation, even though we used a KanBan board for
ABAP development guidance and the common practice of project development based on an
initial environment or pilot. I remember managing WEB projects in 2004 and starting them
with user interaction and screen templates developed by inters. By the way, Design Thinking
involves a prototype visual model analyzed and interplayed by the user. This reduces
documentation, endless meetings, misunderstanding, improves delivery and user
experience – muy bien, it looks exactly the Agile method.

It is important to mention that in Activate courses (ACT100 / ACT200) we can understand

the team’s maturity in order to decide on the Scrum usage. The type of implementation
model – SCRUM, ASAP, regular – should be decided in the PREPARE phase, for example, if
the team can have a project manager. Personally, I think is important, since there are
activities that are not mentioned in the Product Owner scope, such as schedule, status
report, project cost, consultancy recruitment, project status meetings, cut over elaboration,
integrated testing stages, go, hypercare, etc). If possible, hire experienced people because
the in-house development is highly difficult.

14
This is a suggestive team model that you will use in ACT100. This governance model will
align the project development, providing an agile orientation. Additionally, “agile” does not
mean forgetting about actions, organization and documentation. Being agile demands a lot
in terms of prior organization and preparation, including the fact of having well oriented and
skilled workers involved in the project. Like this, I strongly recommend you do not act
“agile” in an ERP implementation if you have not experienced this idea before – even if it is
an ordinary project, try learning a bit of this “culture”.

I have been talking to companies and tried to see this in SAP projects, and it seems to be
something that is described as a “reduced time methodology”. People usually do not
mention the hard work for this – only the theoretical advantage on reduced time. I reinforce
no agile resists without preparation.

The recommended Scrum approach in SAP Activate is used in several projects and follows
existing models (if you wish to know more about SCRUM, there are many links available on
the internet). Get ready, study and practice. Do not try it without understanding it, and
develop the Scrum Master and Product Owner roles.

15
Every SCRUM tool is welcome and useful. As we see, training on the appropriate usage
demands a lot of practice, but especially “culture” of being acquainted. At the EXPLORE
phase, we have the great opportunity of practicing SCRUM.

At this point, users fully see the system operation and create the backlog along with
consultants. Consultants can indicate the deltas in regards to what SAP provides – in the
form of User Stories, for example, where user tells a story of how he/she develops the
coordinated process, and then the process is split into activities that appear on the SCRUM
board.

16
Product Owner should support the prioritization of backlog-cataloged items, being
responsible for the classification based on the company’s needs and priorities – the
integrated knowledge is a crucial feature for this character.

Scrum Master will mentor the methodology appropriate usage, supporting understanding
and coordinating methodology required practical actions.

One of the ACT200 recommended techniques is the Planning Poker – which I struggle to
accept since it seems to drive to average defined by the expert, in practice. Besides that, if
we will use an expert, the practical inclination is close to his/her estimate, so I believe we
can save time shortly directing it to the expert estimate.

In addition, it is crucial to establish a fair amount at the backlog exit in order to feed the
sprints, at least for two weeks and up to four weeks. This streamlines the interaction and
avoids waiste time in a moment the team is waiting for the implementation of items.

17
During Sprint process, we have to align the testing process on what is being delivered,
integrated to the sprint. Depending on the items, we can test one by one or wait for the end
of the sprint to test the package – some companies/projects hire a specific team for items
testing, creating the UAT (User Acceptable Test) for the delivered packages. Please consider
this option, since it may be a way of efficiently controlling the testing phase, besides the
benefit of another separate point of view.

This whole process may and should be documented – there is a common misunderstanding
here because some people still think being agile is having little or no paperwork. “Agile”
means presenting an agile documentation. For example, in my opinion, code documentation
seems useless (this will be in SAP and will be monitored by versions and mapped/analyzed
by ATC – tool that reviews adherence to ABAP code).

SAP provides an amazing tool for each methodology phase: SOLMAN or Solution Manager.
This tool allows us to download all the documentation templates that support the
methodology and write whatever needed, directly in the tool. Furthermore, there are
several possibilities in this tool, such as scenario download, best practices, testing routine
development and documentation phase download (please check a reference article
at https://www.linkedin.com/pulse/solman-um-pequeno-overview-jarlei-n).

18
I suggest (better late than never) to plan the post-implementation called HyperCare phase,
which is not a part of the Activate as a methodology, in the RUN step, where we will have a
project support team helping the immediate start once the project is implemented.

The team operation and interaction should be defined as soon as possible. I use to say that
the Project itself is not as important as the daily routine, which is crucial. Careless
planning/preparation is a high price to pay right in the project beginning, on Monday
morning.

After this, the company is at a normal pace and improvement projects arrive – we may use
the same implementation method but with more experience and strong onboarding. Try
Scrum or another agile method in your company! Please note the interactive action is not
something new, such as RAD, created by James Martin in 1991

19
[https://pt.wikipedia.org/wiki/Desenvolvimento_r%C3%A1pido_de_aplica
%C3%A7%C3%B5es].

Moreover, the different ways of working (currently famous in the information systems area)
come from the automotive industry and are adapted/adopted by the technology area. This
history should be reviewed, so people can understand how these things arise and the
importance of boosting people and companies, which may end the obsession of defining
everything as agile, such as Agile PMO, agile developer, agile project manager, agile
cafeteria. “Agile” is not a stamp or obligation. First of all: learn, practice and get used to it.

Regardless the methodology, Always tries using the continuing improvement process and, if
possible, innovation and a lateral thinking. Try providing current available disruptive options
for the company (virtual reality, augmented reality, IoT, M4, M2M, and a lot o

Agile or Waterfall? Which is best to implement FSCM?

by Mark Chalfen
ollowing from my previous article about why FSCM is becoming more popular with
customers a key question that customers ask is, "what is the best methodology to
implement FSCM?"
The traditional methodology to implement a SAP module or product is known as a
"waterfall" methodology which follows the SAP specific "ASAP" methodology.
The key phases of the ASAP methodology are:
 Project Prep
 Business Blueprint
 Realisation
 Final Prep
 Go-live and Support.

This provides a structure to a project, however certain procedures need to be fulfilled and
the duration of similar projects can be off putting to potential project sponsors who are

20
considering implementing FSCM. Further to this each phase needs to be signed off before
the next phase can commence.

The other option is the AGILE methodology. The key concept and differentiator here is that
by using the AGILE methodology, the phases are joined together to allow small groups of
functionality to be packaged into "sprints" of no more than 4 weeks to design, build test
and implement the functionality. A project can have a number of sprints - however after 4
weeks some functionality should be signed off or delivered into Production. Further to this
the functionality can be prioritised so the key functionality is implemented in the first
sprints.

FSCM focuses on enhancing the cash flow for a client. It would therefore seem sensible to
implement in the project in the most cost effective manner.
There are a number of articles that will cover the benefits of each of the different
methodologies and I don't want to provide a pro and con listing for them. What I intend to
do is to focus on the actual FSCM product, the business users groups that are being
implemented to and also the rationale for the implementation.
The core FSCM product is fairly simple to implement. The volume of physical configuration is
not that great nor is the complexity of this configuration. SAP have created a number of
BAPI's that will personalise the build. Workflow could be used to automate some of the
processes, or escalate certain events. The key to the development is mapping the required
business processes to the FSCM solution, or amending the business processes and mapping
that to the FSCM solution. As such if the business process requirement is known it can be
easy to break out the required functionality into smaller chunks of work that can be
managed in an AGILE manner. However if there is to be some form of business process re-
engineering or this is a new business process the effectiveness of using an AGILE
methodology reduces.

The key business users using the new FSCM solution should also be considered. There are a
number of very mature S AP ERP Finance users within certain clients.These business users
have been using standard Finance Accounts Receivable for a number of years and are
comfortable with the screens. Within an AGILE project business users and technical users
work together closely. The technical team will be providing prototype solutions and ideas to
the business users, and if the business users have the detailed Finance knowledge their
input will be better received. However if you are implementing FSCM to a user group that is
not familiar to ERP Financials such as new implementations of SAP, or users who are using
3rd party software for Accounts Receivable processes this will be different. These users will
need to be up-skilled, including navigation skills, SAP terminology and integration to
consider which align more to the ASAP methodology.

21
The last key consideration is the original rationale of the implementation. Does the project
sponsor require immediate returns for this project? Has the project sponsor got a certain
budget for this project? Has anyone done any analysis on the priorities of the functionality
that is being included in the scope? One of the real benefits of the AGILE methodology is
that you can deliver small groups of functionality at regular intervals. However whilst this
can be a good idea, the whole project team needs to be able to be AGILE, they need to be
able to feed into the scrum's and potential key business users will need to reduce the time
they spend on the normal day to day duties. One example of where the AGILE methodology
did not work was when a client who had a business process that took 5 days to create a SAP
user. The project required a specific user, and requested the day before the user was due to
start which lead to certain required functionality not being implemented in the agreed
scrum.

In summary there is not one answer. The actua l product does lead itself well to the AGILE
methodology, however there are certain examples where the traditional waterfall
methodology is best suited. To work out which implementation methodology is correct for
you I would recommend that you consider some of the points I have raised here. If you
have implemented or are in the process of implementing FSCM please comment on how
you chose your implementation methodology.

22
ASAP goes Agile

Jan Musil 2011

ASAP goes Agile

Earlier this year SAP published the new Agile Business Add-On to ASAP (Service Marketplace
account required) that incorporates agile and lean implementation concept based on
SCRUM methodology into the new AcceleratedSAP (ASAP) Methodology and Business Add-
Ons. This Business Add-On maps agile implementation approach elements such as a product
backlog, a baseline build, and iterative sprints to the traditional phases of ASAP.

This close alignment allows SAP implementation projects to following Agile approach and
deliver benefits to the business early through incremental releases of functionality during
the course of the project. In addition to the incremental nature of the project the Agile
methodology requires much closer cooperation between IT organization and business users.
This is done in a structured manner dictated by the SCRUM framework that consists of clear
ownership of product backlog by the business, regular communicationbetween business
users and IT and structured approach to reflect evolving nature of requirements as solution
is built.

At the same time the methodology benefits from the proven structure of ASAP 7, lean
project WBS and strong set of quality measures like project Q-Gates that are built into ASAP
7.

With Agile Business Add-on to ASAP project teams can tailor the level of acceleration in the
project leverages to fit customer specific needs by leveraging full spectrum of ASAP7
acceleration techniques including the SCRUM based implementation approach. See next
picture for overview of acceleration techniques build into ASAP

23
For example, the implementation team might choose a to follow a hybrid implementation
approach that pairs the SAP Best Practices (e.g. standard functionality) for significant part of
the project scope with Value Prototyping and Custom Development Services from SAP to
address Customer Own Practices that require enhancements of SAP standard. Such project
can be managed with Agile implementation techniques to achieve earlier return on
investment through iterative delivery of functionality to the business. Instead of aiming for
delivery of one big release in 9 months the project team may delivery 2 or 3 incremental
releases of functionality to help business realize value sooner.

This approach provides the flexibility to respond to our customers’ implementation needs
within a proven ASAP framework. We recognize that this is a new concept for many SAP
practitioners and will offer help through practice sharing, discussions and knowledge
exchange in the ASAP community forums on BPX as well as in the BPM webinars. We are
also working on formal extension of standard ASAP training for Agile Business Add-on.

24
25
 Waterfall vs. Agile: Which is the Right Development Methodology for Your
Written by Mary Lotz on July 5, 2018

One of the first decisions we face for each of our project implementations at Segue is
“Which development methodology should we use?” This is a topic that gets a lot of
discussion (and often heated debate). If this is not something you’ve worked with before, a
definition of development methodology is in order; put very simply, it’s a way of organizing
the work of software development. This is NOT about a style of project management or a
specific technical approach, although you will often hear these terms all thrown together or
used interchangeably.

The two basic, most popular methodologies are:

1. Waterfall: (ugh, terrible name!), which might be more properly called the “traditional”
approach, and

2. Agile: a specific type of Rapid Application Development and newer than Waterfall, but
not that new, which is often implemented using Scrum.

26
 Both of these are usable, mature methodologies. Having been involved in software
development projects for a long time, here are my thoughts on the strengths and
weaknesses of each.

Waterfall Methodology
Waterfall is a linear approach to software development. In this methodology, the sequence
of events is something like:

1. Gather and document requirements

2. Design

3. Code and unit test

4. Perform system testing

5. Perform user acceptance testing (UAT)

6. Fix any issues

7. Deliver the finished product

In a true Waterfall development project, each of these represents a distinct stage of

software development, and each stage generally finishes before the next one can begin.
There is also typically a stage gate between each; for example, requirements must be
reviewed and approved by the customer before design can begin.

There are good things and bad about the Waterfall approach. On the positive side:

 Developers and customers agree on what will be delivered early in the development
lifecycle. This makes planning and designing more straightforward.

 Progress is more easily measured, as the full scope of the work is known in advance.

 Throughout the development effort, it’s possible for various members of the team to be
involved or to continue with other work, depending on the active phase of the project.
For example, business analysts can learn about and document what needs to be done,
while the developers are working on other projects. Testers can prepare test scripts from
requirements documentation while coding is underway.

 Except for reviews, approvals, status meetings, etc., a customer presence is not strictly
required after the requirements phase.

 Because design is completed early in the development lifecycle, this approach lends itself
to projects where multiple software components must be designed (sometimes in
parallel) for integration with external systems.

27
 Finally, the software can be designed completely and more carefully, based upon a more
complete understanding of all software deliverables. This provides a better software
design with less likelihood of the “piecemeal effect,” a development phenomenon that
can occur as pieces of code are defined and subsequently added to an application where
they may or may not fit well.

Here are some issues we have encountered using a pure Waterfall approach:

 One area which almost always falls short is the effectiveness of requirements. Gathering
and documenting requirements in a way that is meaningful to a customer is often the
most difficult part of software development, in my opinion. Customers are sometimes
intimidated by details, and specific details, provided early in the project, are required with
this approach. In addition, customers are not always able to visualize an application from
a requirements document. Wireframes and mockups can help, but there’s no question
that most end users have some difficulty putting these elements together with written
requirements to arrive at a good picture of what they will be getting.

 Another potential drawback of pure Waterfall development is the possibility that the
customer will be dissatisfied with their delivered software product. As all deliverables are
based upon documented requirements, a customer may not see what will be delivered
until it’s almost finished. By that time, changes can be difficult (and costly) to implement.

The Agile Methodology

Agile is an iterative, team-based approach to development. This approach emphasizes the
rapid delivery of an application in complete functional components. Rather than creating
tasks and schedules, all time is “time-boxed” into phases called “sprints.” Each sprint has a
defined duration (usually in weeks) with a running list of deliverables, planned at the start of
the sprint. Deliverables are prioritized by business value as determined by the customer. If
all planned work for the sprint cannot be completed, work is reprioritized and the
information is used for future sprint planning.

As work is completed, it can be reviewed and evaluated by the project team and customer,
through daily builds and end-of-sprint demos. Agile relies on a very high level of customer
involvement throughout the project, but especially during these reviews.

Some advantages of the Agile approach are easy to see:

 The customer has frequent and early opportunities to see the work being delivered, and
to make decisions and changes throughout the development project.

 The customer gains a strong sense of ownership by working extensively and directly with
the project team throughout the project.

 If time to market for a specific application is a greater concern than releasing a full
feature set at initial launch, Agile can more quickly produce a basic version of working
software which can be built upon in successive iterations.

28
 Development is often more user-focused, likely a result of more and frequent direction
from the customer.

 For more Agile Development benefits, please see 8 Benefits of Agile Software
Development

And, of course, there are some disadvantages:

 The very high degree of customer involvement, while great for the project, may present
problems for some customers who simply may not have the time or interest for this type
of participation.

 Agile works best when members of the development team are completely dedicated to
the project.

 Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s possible
that some items set for delivery will not be completed within the allotted timeframe.
Additional sprints (beyond those initially planned) may be needed, adding to the project
cost. In addition, customer involvement often leads to additional features requested
throughout the project. Again, this can add to the overall time and cost of the
implementation.

 The close working relationships in an Agile project are easiest to manage when the team
members are located in the same physical space, which is not always possible. However,
there are a variety of ways to handle this issue, such as webcams, collaboration tools, etc.

 The iterative nature of Agile development may lead to a frequent refactoring if the full
scope of the system is not considered in the intial architecture and design. Without this
refactoring, the system can suffer from a reduction in overall quality. This becomes more
pronounced in larger-scale implementations, or with systems that include a high level of
integration.

Making the Choice Between Agile and Waterfall

So, how do we choose? First, we change the game a little (which is what most software
development organizations do) by defining our own process. At Segue, it’s called
our Process Framework, and it’s a variation on the traditional Waterfall methodology. Our
modifications include use of prototyping where possible to provide the customer a better
view of their finished product early in the design/development cycle. This helps to improve
the team’s understanding of requirements and communication with the customer. After the
primary framework of the application is completed per high level requirements, we
continue to develop and also to reach out to the customer for refinement of requirements.
In this way, we strive to be as iterative as possible without compromising our overall system
architecture.

We consider the following factors when considering which methodology to use:

29
30
The factors above are not equally weighted; each is assessed depending on the individual
project and circumstances.

Although we are starting to see mass adoption of various Agile methodologies in the
Enterprise (even DoD and Federal agencies), there are still many organizations that are slow
to make the change. It is also very common for organization to transition into more of a
hybrid Agile approach that combines aspect of both Agile and Waterfall. The Agile Practice
Guide was developed specifically to help organization understand and evaluate the use of
Agile and hybrid Agile approaches. The Project Management Institute (PMI) that developed
the Project Management Body of Knowledge (PMBOK) Guide collaborated with the Agile
Alliance to bundle the two guides in one offering to help organizations, managers and
leadership increase agility in the development process.

Once we’ve decided which basic methodology to utilize, we can further refine the process to
best fit our project goals. Ultimately, although the way in which we do our work is
important, delivering a solid and maintainable product that satisfies our customer is what
really counts.

31
Introduction
In order to achieve goals and planned results within a defined schedule and a budget, a
manager uses a project. Regardless of which field or which trade, there are assortments of
methodologies to help managers at every stage of a project from the initiation to
implementation to the closure. In this tutorial, we will try to discuss the most commonly
used project management methodologies.

A methodology is a model, which project managers employ for the design, planning,
implementation and achievement of their project objectives. There are different project
management methodologies to benefit different projects.

For example, there is a specific methodology, which NASA uses to build a space station
while the Navy employs a different methodology to build submarines. Hence, there are
different project management methodologies that cater to the needs of different projects
spanned across different business domains.

Project Methodologies
Following are the most frequently used project management methodologies in the project
management practice:

1 - Adaptive Project Framework

In this methodology, the project scope is a variable. Additionally, the time and the cost are
constants for the project. Therefore, during the project execution, the project scope is
adjusted in order to get the maximum business value from the project.

2 - Agile Software Development

Agile software development methodology is for a project that needs extreme agility in
requirements. The key features of agile are its short-termed delivery cycles (sprints), agile
requirements, dynamic team culture, less restrictive project control and emphasis on real-
time communication.

3 - Crystal Methods
In crystal method, the project processes are given a low priority. Instead of the processes,
this method focuses more on team communication, team member skills, people and
interaction. Crystal methods come under agile category.

4 - Dynamic Systems Development Model (DSDM)

This is the successor of Rapid Application Development (RAD) methodology. This is also a
subset of agile software development methodology and boasts about the training and
documents support this methodology has. This method emphasizes more on the active
user involvement during the project life cycle.

32
5 - Extreme Programming (XP)
Lowering the cost of requirement changes is the main objective of extreme programming.
XP emphasizes on fine scale feedback, continuous process, shared understanding and
programmer welfare. In XP, there is no detailed requirements specification or software
architecture built.

6 - Feature Driven Development (FDD)

This methodology is more focused on simple and well-defined processes, short iterative
and feature driven delivery cycles. All the planning and execution in this project type take
place based on the features.

7 - Information Technology Infrastructure Library (ITIL)

This methodology is a collection of best practices in project management. ITIL covers a
broad aspect of project management which starts from the organizational management
level.

8 - Joint Application Development (JAD)

Involving the client from the early stages with the project tasks is emphasized by this
methodology. The project team and the client hold JAD sessions collaboratively in order to
get the contribution from the client. These JAD sessions take place during the entire project
life cycle.

9 - Lean Development (LD)

Lean development focuses on developing change-tolerance software. In this method,
satisfying the customer comes as the highest priority. The team is motivated to provide the
highest value for the money paid by the customer.

10 - PRINCE2
PRINCE2 takes a process-based approach to project management. This methodology is
based on eight high-level processes.

11 - Rapid Application Development (RAD)

This methodology focuses on developing products faster with higher quality. When it
comes to gathering requirements, it uses the workshop method. Prototyping is used for
getting clear requirements and re-use the software components to accelerate the
development timelines.

In this method, all types of internal communications are considered informal.

33
12 - Rational Unified Process (RUP)
RUP tries to capture all the positive aspects of modern software development
methodologies and offer them in one package. This is one of the first project management
methodologies that suggested an iterative approach to software development.

13 - Scrum
This is an agile methodology. The main goal of this methodology is to improve team
productivity dramatically by removing every possible burden. Scrum projects are managed
by a Scrum master.

14 - Spiral
Spiral methodology is the extended waterfall model with prototyping. This method is used
instead of using the waterfall model for large projects.

15 - Systems Development Life Cycle (SDLC)

This is a conceptual model used in software development projects. In this method, there is
a possibility of combining two or more project management methodologies for the best
outcome. SDLC also heavily emphasizes on the use of documentation and has strict
guidelines on it.

16 - Waterfall (Traditional)
This is the legacy model for software development projects. This methodology has been in
practice for decades before the new methodologies were introduced. In this model,
development lifecycle has fixed phases and linear timelines. This model is not capable of
addressing the challenges in the modern software development domain.

Conclusion
Selecting the most suitable project management methodology could be a tricky task. When
it comes to selecting an appropriate one, there are a few dozens of factors you should
consider. Each project management methodology carries its own strengths and
weaknesses.

Therefore, there is no good or bad methodology and what you should follow is the most
suitable one for your project management requirements.

34