Intellectual Property Acknowledgement

You, the author of this white paper, agree that you have not used any copyrighted material in this white paper or,
have appropriately indicated the copyright of the respective object. You further agree that you have not used any
other intellectual property of any third party in this white paper or, have appropriately indicated the intellectual
property of the respective object.

You confirm, that consistent with the terms of your employment with Accenture, that any rights, title and interest
whatsoever, including, but not limited to, patents, copyright, trade secret and design rights, mask rights, whether
register able or not, arising or created as a result of the development of and/or the application of any tangible or
intangible work product or materials produced by you during or as a consequence of your employment (including in
this white paper), whether alone or in conjunction with others and whether during normal working hours or not,
including, but not limited to, any invention, design, discovery, improvement, computer program, documentation, or
other material (including in this white paper) which you conceive, discover or create during or in consequence of
employment hereunder (“Work Product”) shall belong exclusively to Accenture and its affiliates. You hereby convey
ownership in such rights, title and interest to Accenture and its affiliates upon inception or development.

All Work Product shall constitute a work(s) made for hire under all copyright acts. To the extent that any Work
Product does not constitute a work made for hire under the foregoing laws, you hereby irrevocably assign all
worldwide right, title, and interest (including without limitation, patents, copyright, trade secret, trademarks, design
rights, contract and licensing rights) in such Work Product to Accenture and its affiliates. You retain no rights to use
the Work Product and agree not to challenge the validity of Accenture’s and its affiliates' ownership in the Work
Product. You hereby forever waive all moral rights in the Work Product and any results or proceeds there from, even
if after expiration or termination of your employment hereunder. If you agree that you will not violate or attempt to
violate the intellectual property rights (IPR), interests or title of any third party. Accenture shall be entitled to
immediate injunctive or similar relief upon a potential or actual breach of this Section by you. You agree to cooperate
with Accenture and its affiliates as is necessary and provide any necessary documentation consistent with and in
furtherance of the rights conveyed hereunder.

By submitting this white paper, you agree that you have read and understood the disclaimer set out above and that
you understand that it may affect your rights and agree to be bound by these terms.

6/26/2019 Ver x.0 1 of 12

 Name of the Employee Roshan Pinto
Employee SAP ID 10621814
Enterprise ID Roshan.pinto
Current Project Name Dupont Spin Merge
Topic Category (Please type in the category number by Agile for M&A Projects
referring to the attachment sent as part of the announcement
mailer.
For ex: if you have written a paper on Test Automation your
category is B8)
If you are locked to an Industry Group, please name the industry Resources
group (FS/H&PS/CMT/Products/Resources/Others)
If you are locked to capability organization, please name the
Technology Platform (SAP/Oracle/Testing/Solution Factory,
Management Services, Digital & Marketing, AD&I, TOD,
Operations)

Note: The above data being solicited is for Internal use & referential purposes only.

6/26/2019 Ver x.0 2 of 12

Introduction
Agile is a project management framework aimed at delivering a project or product rapidly ,
efficiently and collaboratively through iterative methods. The involvement of the business
thoughout the project lifecycle is vital as Scrum relies on collaboration between the business
and IT to deliver the right outcomes in a lean manner . The purpose of this whitepaper is to
discuss the application of Agile in a SAP Merger and Acquisition scenario.

Merger and Acquisition Projects

The Industry is rapidly evolving today with organizations being taken over by larger
orgranizations in hostile takeovers or simply two identical organizations merging together to
leverage synergies and separate businesses based on core competencies . The learnings in the
whitepaper relate to a merger between two Fortune 100 companies and the use of Agile to
implement changes to a rapidly changing framework. With merger and acquisitions being
announced year or year comes the challenges of integrating the IT framework between
companies and harmonizing ERP systems and applications. For the purpose of the white paper
the focus is on SAP as a technology and challenges in enabling .

Applying Agile to M&A Projects

Agile Principles which can be applied to a M&A Project.

Colocation

It is important for the success of a Agile M&A project that teams are co-located in one location.
The business and IT should be working hand in hand on a daily basis . Co-location has several
advantages including a under.

 Reduction in delays due to key decisions pending with Stakeholders .

 Resolution of issues face to face and reduction in downtime and delays .
 Agility in pace of software development with the customer testing the product and
providing immediate feedback to the development team.
 Key decisions and alternatives made quickly in terms of change requests.

6/26/2019 Ver x.0 3 of 12

This applies to third party vendors and contractors who are involved in the project . Colocation
can be structured between sub teams located at different locations with the main location .
Integration between cross teams is also vital for resolution of integration issues.

Definition of Sprint
The sprint definition in a SAP project constitutes into breaking the project into small phases
called Sprints . In a tranditional waterfall method we move from longer phases which are Design,
Build , Code , Test & Deploy . In the Agile methodology we work on smaller phases which
incorporate the key phases of a waterfall model but in shorter duration cycle. For a merger &
acquisition project the focus is more on cloning the systems and migrating data to multiple
systems for businesses . The Sprints can be shorter cycles where systems are build in a POC
phase and trial migrations are done . This is followed by testing and sign off phases . The next
stages would be building the QA systems for USAT testing and sign off followed by short test
cycles of 8- 10 weeks .

Sprint Planning
Sprint planning involves bringing the stakeholders together to define the work which has to be
accomplished during the Sprint . The objectives of the Sprint are defines as User Stories or what
is expected at the completion of the Sprint .In M&A scenario it would be relation to separation
of configuration , Data requirements which need to be loaded and testing requirements .

Transparency
Significant aspects of the process must be visible to those responsible for the outcome.
Transparency requires aspects be defined by a common standard so observers share a common
understanding of what is being seen.

For example:
A common language referring to the process must be shared by all participants.
Those performing the work and those accepting the work product must share a
common definition of “Done”.

Adaptation
Deviations in the process is unacceptable in Scrum and that the resulting product will be
unacceptable. Scrum prescribes four formal events for inspection and adaptation, as described
in the Scrum Events section of this document:
Sprint Planning

6/26/2019 Ver x.0 4 of 12

 Daily Scrum
Sprint Backlog
Sprint Retrospective

Sprint Planning
The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by
the collaborative work of the entire Scrum Team and basically by the Product Owner.
Sprint Planning is time-boxed with the respective teams like and participants from the Business
like the Product Owner, Scrum Master, Developers, Testers and UAT. The PO/SM ensures that
the event takes place and that attendants understand its purpose. The PO/SM teaches the
Scrum Team to keep it within the time-box.
Sprint Planning answers what can be done in the SPRINT.

Tool (Rally) screenshot of the Sprint planning page,

What can be done in a SPRINT?

The Development Team works to forecast the functionality that will be developed during the
Sprint. The Product Owner discusses the objective that the Sprint should achieve and the
Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire
Scrum Team collaborates on understanding the work of the Sprint.

6/26/2019 Ver x.0 5 of 12

On the same hand the Testing team make sure to understand the requirements/user stories and
start their Test Design process. Once the tickets start getting deployed, testers start their
Product Test execution on those.
The input to this meeting is the Product Backlog, the latest product Increment, projected
capacity of the Development Team during the Sprint, and past performance of the Development
Team. The number of items selected from the Product Backlog for the Sprint is solely up to the
Development Team. Only the Development Team can assess what it can accomplish over the
upcoming Sprint.
The Development Team usually starts by designing the system and the work needed to convert
the Product Backlog into a working product Increment. At the same time the Testers make sure
that all the desired scenarios are covered and coded and the Product meets expected result. The
Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the
Development Team determines it has too much or too little work, it may renegotiate the
selected Product Backlog items with the Product Owner.
By the end of the Sprint Planning, the Development Team should be able to explain to the
Product Owner and Scrum Master how it intends to work as a self-organizing team to
accomplish the planned work.

User Story

A user story is a tool used in Agile software development to capture a description of a software
feature. The user story describes the complete description of what users actually want and why.
A user story helps to create a simplified description of a requirement.

6/26/2019 Ver x.0 6 of 12

Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the complete team to synchronize
activities and create a plan for the next 24 hours. This is done by inspecting the work since the
last Daily Scrum and forecasting the work that could be done before the next one.
The Daily Scrum is held at the same time and place each day to reduce complexity. During the
meeting, the team members explain:
What did I do today and what am I going to do tomorrow?
Were there any blockers and if yes than how can they be resolved and who is the
contact person?
Are there any other things which needs to be discussed as to meet the end result?

Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for
delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast
by the Development Team about what functionality will be in the next Increment and the work
needed to deliver that functionality into a “Done” Increment.

6/26/2019 Ver x.0 7 of 12

The Sprint Backlog makes visible all of the work that the Development Team identifies as
necessary to meet the Sprint Goal.
Again all the teams participates in the Sprint Backlog and understand what the process is.

Sprint Retrospective
The Sprint Retrospective or Sprint Retrospection is an opportunity for the Scrum Team and the
complete team to inspect itself and create a plan for improvements to be enacted during the
next Sprint.
The Sprint Retrospective occurs prior to the next Sprint or at the last day of the current Sprint.
This occurs every Sprint. The Scrum Master teaches all to keep it within the time-box. The Scrum
Master participates as a peer team member in the meeting from the accountability over the
Scrum process.
The purpose of the Sprint Retrospective is to:
Inspect how the last Sprint went with regards to people, relationships, process, and tools;
Identify and order the major items that went well and potential improvements; and,
Create a plan for implementing improvements to the way the Scrum Team does its work.
The Scrum Master encourages the Scrum Team to improve, within the Scrum process
framework, its development process and practices to make it more effective and enjoyable for
the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase
product quality by adapting the definition of “Done” as appropriate.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements
that it will implement in the next Sprint. Implementing these improvements in the next Sprint is
the adaptation to the inspection of the Scrum Team itself. Although improvements may be

6/26/2019 Ver x.0 8 of 12

implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on
inspection and adaptation.

The Scrum Team

The Scrum Team consists of a Product Owner, Development Team, Testing Team and a Scrum
Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose
how best to accomplish their work, rather than being directed by others outside the team.
Cross-functional teams have all competencies needed to accomplish the work without
depending on others not part of the team. The team model in Scrum is designed to optimize
flexibility, creativity, and productivity.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for
feedback. Incremental deliveries of “Done” product ensure a potentially useful version of
working product is always available.

The Product Owner

The Product Owner is responsible for maximizing the value of the product and the work of the
Development Team. How this is done may vary widely across organizations, Scrum Teams, and
individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product
Backlog management includes:
Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and missions;
Optimizing the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows
what the Scrum Team will work on next; and,

6/26/2019 Ver x.0 9 of 12

 Ensuring the Development Team understands items in the Product Backlog to the
level needed.

The Product Owner is one person, not a committee. The Product Owner may represent the
desires of a committee in the Product Backlog, but those wanting to change a Product Backlog
item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The
Product Owner’s decisions are visible in the content and ordering of the Product Backlog.

The Scrum Master

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Master
do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those
outside the Scrum Team understand which of their interactions with the Scrum Team are helpful
and which aren’t. The Scrum Master helps everyone change these interactions to maximize the
value created by the Scrum Team.

Scrum Master Service to the Product Owner

The Scrum Master serves the Product Owner in several ways, including:
Finding techniques for effective Product Backlog management;
Helping the Scrum Team understand the need for clear and concise Product Backlog
items;
Understanding and practicing agility; and,
Facilitating Scrum events as requested or needed.

Scrum Master Service to the Testing and Development Team

The Scrum Master serves the Testing and Development Team in several ways, including:
Coaching the Teams in self-organization and cross-functionality;
Helping the Teams to create high-value products;
Removing impediments to the Team’s progress;
Facilitating Scrum events as requested or needed.

The Sprint

The heart of Scrum is a Sprint, a time-box of a fortnight during which a “Done”, useable, and
potentially releasable product Increment is created. Sprints best have consistent durations
throughout a development effort. A new Sprint starts immediately after the conclusion of the
previous Sprint.

6/26/2019 Ver x.0 10 of 12

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development and the
testing work, and the Sprint Retrospective.
During the Sprint:
No changes are made that would endanger the Sprint Goal;
Quality goals do not decrease; and,
Scope may be clarified and re-negotiated between the Product Owner and testing
and Development Team as more is learned.

It varies from Organization and project to project that if each Sprint may be considered a project
or multiple Sprints consist of one Release or a Project. Like projects, Sprints are used to
accomplish something. Each Sprint has a definition of what is to be built, a design and flexible
plan that will guide building it, the work, and the resultant product.
When a Sprint’s horizon is too long the definition of what is being built may change, complexity
may rise, and risk may increase. Sprints enable predictability by ensuring inspection and
adaptation of progress toward a Sprint Goal.

Definition of “Done”

When a Product Backlog item or an Increment is described as “Done”, everyone must

understand what “Done” means. Although this varies significantly per Scrum Team, members
must have a shared understanding of what it means for work to be complete, to ensure
transparency. This is the definition of “Done” for the Scrum Team and is used to assess when
work is complete on the product Increment.
The same definition guides the Teams in knowing how many Product Backlog items it can select
during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially
releasable functionality that adhere to the Scrum Team’s current definition of “Done.”
Development Teams deliver an Increment of product functionality every Sprint. This Increment is
useable, so a Product Owner may choose to immediately release it.
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include
more stringent criteria for higher quality. Any one product or system should have a definition of
“Done” that is a standard for any work done on it.

Advantages of SCRUM methodology

The scrum methodology has many advantages that make it famous and widely used in software
development. The few of the advantages are mentioned below,

If we compare the traditional (waterfall) approaches to scrum, traditional approaches

only judge or provide vision of uncertainty or unpredictability about development in

6/26/2019 Ver x.0 11 of 12

 beginning of the project but scrum is capable of providing this mechanism
throughout development process this flexible nature of scrum helps in managing the
change in project cycle and also in release of the projects on time without delays.
Scrum provides the free environment to the developers to work and provide the
appropriate solution with the change in the environment
Scrum helps the Testers to start their Test Design in parallel with the Development
team.
It helps developers and testers in sharing the knowledge as in scrum the developers
work in small teams and it lead to lot of interaction among employees so employees
can share the tacit knowledge.
The flexible deliverable, flexible schedule, small interactive development teams,
frequent review, collaboration of external parties are the few characteristics that
make scrum project more successful than others approaches in the software
development.

References
https://en.wikipedia.org/wiki/Scrum_(software_development)
https://www.scrumalliance.org/why-scrum/scrum-guide
https://www.scrum.org/Resources/What-is-Scrum

6/26/2019 Ver x.0 12 of 12