Using Adaptive Scrum to Tame Process Reverse Engineering in Data Analytics Projects

Cognizant 20-20 Insights
August 2021
Using Adaptive Scrum to Tame
Process Reverse Engineering in
Data Analytics Projects
Organizations rely on analytics to make intelligent decisions and improve
business performance, which sometimes requires reproducing business
processes from a legacy application to a digital-native state to reduce the
functional, technical and operational debts. Adaptive Scrum can reduce
the complexity of this reproduction process iteratively as well as provide
transparency in data analytics projects.
Executive Summary
Data analytics helps organizations improve their business
performance and achieve business objectives. But legacy
application modernization required to keep existing
business processes running has saddled numerous
organizations with functional, technical and operational
debts that create obstacles to deploying the latest data
analytics. Many analytics applications must therefore
be reproduced — or reverse engineered — from legacy
applications and implemented using cutting-edge digital
technology.

2 / Using Adaptive Scrum to Tame Process Reverse Engineering in Data Analytics Projects
The Scrum framework is highly recommended
for resolving complex business problems. Reverse
engineering projects are inherently complex, and
often create uncertainty from the onset. As opposed
to the waterfall approach, the Scrum method
allows the project team to reduce complexity
iteratively, which enables quicker release of the
product to users. Several success criteria for reverse
engineering projects are fulfilled better using the
Scrum approach.
The Scrum development process for reverse
engineering follows an incremental approach to
produce a releasable product. Although Scrum
appears to be well-suited for reverse engineering
projects, there are several challenges that need to be
overcome before the business value can be realized.
This white paper discusses proven best practices to
mitigate the management and technical challenges,
based on a complex project that we delivered to a
leading life sciences organization.

Business value through reverse engineering
The mastery of digital domains such as cloud,
analytics, the Internet of Things (IoT), digital
engineering, machine learning (ML), artificial
intelligence (AI), etc. has become essential for
businesses to remain competitive. Analytics plays
a major role in providing critical information to
improve business performance using applications
such as big data analytics, predictive analytics, retail
analytics, supply chain analytics, etc. During the
COVID-19 pandemic, 58% of 1,800 respondents
in a 2020 Gartner CIO survey1
said that they would
spend more on business intelligence and data
analytics in 2021, which was second only to cyber
and information security spending.
As digitization of key business processes accelerates,
data analytics is playing a key role in enabling
organizations to make intelligent and informed
decisions. Analytics applications allow businesses to
analyze, predict and track specific KPIs and thus cap
overall costs. In the COVID era, organizations must
balance investments to keep legacy applications alive
and investments in the latest digital technologies.
The practice of reverse engineering involves
reproducing the business scenarios and processes
from legacy applications in state-of-the-art mobile
apps or internet/intranet applications. Reverse
engineering of business processes can be defined as
the practice of analyzing, extracting and reproducing
the business processes in whole or in part from a
legacy application to a modern application in order to
reduce the functional,technical and operational debts
of the legacy application in the business environment.
The debts are application activities or practices
that are not best-in-class industry standards (e.g.,
shortcuts,work-arounds or manual activities) and
hence need to be replaced with available best in-class
practices so the business can remain competitive.
For instance, a state-of-the-art application could
implement functionalities that are missing in the
legacy application in a more sustainable manner.
They can be built on top of the core business
functions or processes in the legacy application to
reduce the functional debts and retain the core and
functioning processes within an organization.
As an example, a predictive analytics dashboard
for the warehouse shows the replenishment orders
required based on the ordering process that is
currently implemented in the existing ERP system.
Technical debts include issues such as scalability,
performance, etc. of the legacy application. One
example would be a low number of concurrent
mobile users who could access the ERP system.
Operational debts in the legacy application include
business processes that require manual processing or
intervention and that keep the operational costs high
within an organization. For example, an operational
database that need to be restarted once every week to
avoid operational disruptions is an operational debt.
Reverse engineering of business processes can be defined as the
practice of analyzing,extracting and reproducing the business
processes in whole or in part from a legacy application to a modern
application in order to reduce the functional,technical and operational
debts of the legacy application in the business environment.

Reverse engineering waves
There have been three major waves in reverse
engineering since the 1990s (see Figure 1). The
Y2K problem, or millennium bug, saw the first big
wave of code reverse engineering in the early 1990s.
Program codes were rectified in source systems to
avoid application malfunctioning. The second wave
came with the internet boom period from the early
2000s to 2010 when businesses reengineered their
applications to improve their web presence and
ventured into e-commerce.2
Web applications were
reengineered to connect to the enterprise legacy
applications.
The third and current wave is a result of the ongoing
pivot to digital and the proliferation of digital-native
(mobile, cloud-native, no-code/low-code, etc.) apps
that started in the 2010s. This wave has seen the
demand rise for processes to be reverse engineered
in state-of-the-art applications that provide better
insights by allowing users to develop their own
dashboards and thus make smarter decisions. These
applications use data from the legacy operational
systems or analytics applications that are built using
the latest platforms such as Qlik, Tableau, etc.
Mobile apps and business services are being
redefined, but the business processes are reverse
engineered for existing business logic, rules and
configurations, and reproduced for various platforms
like Apple, Google Play or Microsoft stores. Further,
the deployment of no-code/low-code platforms from
major analytics vendors provides self-service or on-
demand analytical capabilities. These platforms are
supported by AI and ML models with the ability to
analyze, classify, extract, transform and load data with
less user involvement and thus allow the businesses
to take intelligent, real-time decisions.
Code reverse engineering
Application reverse engineering
Process reverse engineering
• Y2K problem
• Period: 1990-2000
• Business value: Keep applications running
• Internet boom
• Period: Late 1990s-mid-2000s
• Business value: Connect legacy applications to the web
• Digital disruption and proliferation of mobile apps
• Since 2010
• Business value: Reuse key business processes and
make intelligent decisions
Figure 1

Figure 2
Reverse engineering: Success criteria
How to achieve reverse engineering project success
Organizations are aiming for specific business
goals when they venture into reverse engineering
projects, such as increasing revenue from customers,
targeting new millennial customers, reducing cost/
inventory, etc.The waterfall approach to building
software applications continues to be the dominant
project management methodology, since it allows
organizations to tackle business requirements in a
structured and phased manner.The proliferation of
Agile frameworks such as Unified Process, Scrum,
etc. in the 2000s allowed organizations to develop
applications by adapting quickly to ever-changing
business dynamics. Scrum is nowadays the most
popular Agile framework,3
with many IT professionals
even viewing Scrum as the default.The success of
waterfall and Scrum approaches can be evaluated
using specific criteria in reverse engineering projects.
The success criteria in a reverse engineering project
need to be defined well to ensure their fulfilment by
the end of the project. These criteria are primarily
related to the reduction of functional, technical and
operational debts and to how fast the application
can be released to the market. Figure 2 defines the
success criteria of both waterfall and Scrum projects
based on our client engagements.
Success Criterion Waterfall Scrum
Reduce functional debt
Initially determined functional
debt can be amortized
Initially determined functional
debt as well as changing
functional needs can be
addressed
Reduce technical debt
Initially determined technical
debt can be amortized
Initially determined technical
debt as well as changing
needs can be addressed
using enforced engineering
practices from day one
Reduce operational debt
Initially determined
operational debt can be
amortized
Initially determined
operational debt as well
as changing needs can be
addressed
Accelerate time-to-market
Initially determined timelines
can be achieved
20% to 50% faster time-to-
market than waterfall projects
is possible

In a waterfall project,the functional requirements are
fixed in the beginning and the reverse engineering
project could reproduce the functionalities identified
by the business.A Scrum project could further look
into changing business needs and implement more
functionalities than initially planned in the waterfall
project within the same timeframe,which brings value
to business; the product owner (PO) can prioritize the
dynamic requirements of the business throughout the
project based on the value they generate for the business.
Technical debt in terms of nonfunctional
requirements (such as scalability, performance,
usability, reliability, security, etc.) that are in scope
from the outset can be fulfilled by the waterfall
project; Scrum could further address changing
needs, such as security requirements, if emerging
threats are anticipated. Operational debts (such as
data quality, maintainability, accessibility, extensibility,
etc.) can be amortized in both waterfall and Scrum
projects; Scrum projects can have improved data
quality as the PO will continuously verify the data
model and rules as the project progresses.
Further emerging operational changes can be
addressed in Scrum projects; however, it is highly
unlikely that major operational changes will emerge
during the project. The product team (which
includes the PO, Scrum master and the development
team) focuses on the smaller scope of Sprint goals
(goals within the Sprint, a time-boxed duration of
one month or several weeks) rather than the larger
scope in waterfall projects, which allows them to
deliver against impending deadlines. This focus in
Scrum projects results in better productivity and
thus allows 20% to 50% faster time-to-market of the
product than in waterfall projects, depending on the
Agile team’s self-managing skills.
More success criteria can be determined based on
specific business goals.Each data analytics project has
its own business goals covering finance, management
and quality.While both Scrum and waterfall projects
can achieve the initially determined specific business
goals, Scrum is better suited to resolve uncertainties
involved in reverse engineering projects.

How Scrum development processes boost reverse
engineering
Scrum projects have fixed budgets and schedules,
whereas the scope is variable. On the other hand,
waterfall projects have fixed scopes and variable
budgets and schedules. The complexity and
uncertainty of requirements are the main criteria that
determine the choice of Scrum over waterfall in a
data reverse engineering project.
Requirements that exhibit low uncertainty and
change are better managed through the waterfall
approach. A waterfall project takes a linear-phased
approach, coursing through sequential phases —
from requirements and analysis, through design,
develop, test and deploy (see Figure 3). This linear
approach is often highly challenged for reproducing
business processes, especially when the required
documentation and the SMEs of legacy applications
are no longer with an organization.
Scrum is usually recommended for generating
“value through adaptive solutions for complex
problems.”4
The adaptive approach is best suited
to projects that exhibit high rates of change and
uncertainty in their requirements and technical
degrees.5
Process reverse engineering is a complex
problem that can be resolved well using Scrum, as
the method’s iterative and incremental development
reduces the complexity as the product evolves. It
provides business value through feedback loops and
frequent deliveries.
Figure 4 (next page) illustrates how the Scrum
reverse engineering process results in improved
business value, nearly end to end. The product
vision and the high-level design of the application
will be developed in the design Sprint. In the Sprint
planning meeting, the product team will ideate
about the core business processes to be reproduced
from the legacy application as well as new business
processes to be implemented. The initial discussion
of functional, technical and operational debts in
this Sprint could also involve primary business and
technical stakeholders who are affected by the
legacy system. Based on the product vision, along
with prioritization of the product backlog developed
by the PO, the product team will analyze and finalize
the architectural and functional design. Software
engineering aspects such as test automation,
continuous integration (CI) and continuous
deployment (CD) will be set up in this Sprint.
This Sprint also lays the foundation for the Agile
execution. The core business processes and
immediate user stories (features from the user
perspective) that will be implemented in the
upcoming Sprints will be elaborated with their
definition of done (DoD) as well as definition of ready
Waterfall phases
Final project
outcome
Requirements
& Analytics
Design Develop Test Deploy
Figure 3

(DoR) and finalized. The development team will
receive an overview of the business and technical
requirements of the product with the inputs from
the business analyst (BA). The user stories groomed
in the design Sprint provides a solid basis for the
development team to implement in the development
Sprints. The high-level design, product scope and
functional dependencies will then be reviewed in the
Sprint review meeting.
In the development Sprint,the product team will go
through several iterations to produce an increment
that could potentially be released to the users.In the
requirements and analysis phase,the development team
assesses business requirements that are formulated as
user stories by the PO in the product backlog.
It is key that as much business and technical
understanding of the process be reverse
engineered for the development team to commit
to the user story in the Sprint planning meeting.
During the design phase, the developer will work
closely with the BA to translate the functional
specifications into technical design specifications
with their DoD. This involves information related
to the main data sources, entities and fields to
start work with. Further, the developer will look
for business logics/rules, relationships and data
scenarios to develop the first version of the data
model. As Figure 4 depicts, the design, develop
and test phases will be repeated until the DoD is
completed for the user story.
Reverse engineering the Scrum process
Figure 4
Plan & Ideate Review
Analyze
F
i
n
a
l
i
z
e
Design Sprint
Development Sprint N-1 Development Sprint N
T
e
s
t
T
e
s
t
S
c
r
een
S
c
r
een
Fee
d
b
a
c
k
Fee
d
b
a
c
k
(
I
n
f
o
r
m
a
l
)
(
I
n
f
o
r
m
a
l
)
Bui
l
d
Bui
l
d
Requirements
& Analysis
Requirements
& Analysis
Design Design
Develop Develop
Test
(Formal)
Test
(Formal)
Deploy Deploy
Sprint N’s
cumulative
outcome
Sprint N-1’s
outcome
Data
Model
Data
Model

The iterative design-develop-test phases
encompass the development of initial data model
testing using production data extracts and involving
the BA to informally test the data model. It is
important that the PO or BA who has access to the
productive source system, of which the process is
reproduced, is involved to provide the latest data
extract and scenarios to test the data model. Once
the data model is tested informally by the developer,
the PO screens it against business requirements
and provides feedback, which will then be
integrated into the model.
Based on the production data and iterative design-
develop-test cycles, new business rules will be
added and/or data model changes will be made to
produce the next build. Developers will check the
business rules and data model several times with
the PO before the formal testing and deployment
will be conducted, after which the user story will be
formally closed in the Sprint review meeting.
There are a few key differences in reproducing
business processes using reverse engineering
compared with normal Scrum development.As
clear design specifications and the full picture of
functional dependencies are missing from the outset,
the design-develop-test phases will involve several
cycles — in a trial-and-error manner—to develop
and refine the business rules and data model.The
complexity will subside gradually as the data model
will be verified incrementally by the PO. In order to
test with real scenarios, access to production data
examples is critical. Developers need direct access to
the production data or production environment in the
development environment.
Reverse engineering data analytics challenges and
recommendations
Depending on the complexity of business processes
and the information asymmetry regarding the
business processes between the source and the to-
be-implemented processes, it can be a daunting task
to get the Sprint increment released to end users on
time.There are several management and technical
challenges that need to be managed well to meet the
business requirements. Figure 5 describes the best
practices to mitigate the challenges, based on our
analytics project client experiences.
Overcoming reverse engineering obstacles
Figure 5
Challenges Best Practices for Mitigation
Missing SMEs to walk through key business
processes or scenarios

❙ PO and development team to work together using key business rules
and production data

❙ PO and BA to leverage existing documentation and data and define the
DoD before the Sprint planning
Missing special cases or specific processes in
the initial Sprint or iteration

❙ Assign requirements having high uncertainty with corresponding story
points
Difficulties in announcing release dates

❙ MVP to be defined; announce enhancements in the upcoming release
for known issues

❙ Continuous or frequent showcasing to end users to get feedback
Continuous reworking of program code and
data model

❙ DoD to be clarified before the start of Sprint with technical aspects

❙ Work using key examples to capture all the possible scenarios
Availability of production data that is in sync
with all the data sources in the development
environment

❙ Get business approval and maintain a dedicated DevOps team

The PO may not be thoroughly familiar with all the
business processes or scenarios to be reproduced
from the source system, and could become
overwhelmed by the situation. He or she will have to
check with several process experts who may fully or
partially know the processes to be rebuilt. Because
of the lack of SMEs with mastery of business
processes in the organization, the PO, BA, technical
experts and developers need to work closely using
key business rules and production data.
The DoD of the product backlog item needs to be
defined by the business and, whenever possible,
also from the technical perspective before the
Sprint planning meeting. The backlog review and
grooming meeting needs to be used effectively
to discuss the required details such as the DoD
and DoR. Nevertheless, there will be several
special cases or specific processes that will not be
captured in the design Sprint. From the project
management perspective, the product team should
be encouraged to consider difficulties for covering
complex requirements, of which dependencies are
not fully understood, and assign the corresponding
risks and efforts as story points in the user story.
Special cases remain a challenging part in
unravelling the business processes and the product
team will need to re-plan a Sprint as soon as such
cases are found during a Sprint.
Agile budgeting in an Agile organization allows
the PO to secure the funding required to create
the next increment in a project. However, because
of the inherent uncertainty regarding whether the
business processes are recreated correctly in a
reverse engineering project, the announcement of
release dates could be difficult.
To mitigate this challenge, the product team should
work toward a minimum viable product (MVP) and
announce the release date only if there is enough
confidence to meet the deadline. The PO will
decide whether the increment will provide enough
value for users and decide about the release,
particularly when there are open issues. Continuous
and frequent showcasing of developed artifacts to
end users allow the developers to adapt the product
on time. Users need to be informed about known
issues during the release, and enhancements could
be promised for upcoming releases.
From the developer’s perspective, reverse
engineering is a daunting task since build activities
can be completed only once the DoD is fulfilled.
Reproducing complex business processes
requires continuous reworking of the program
code and data model compared with a typical
Agile or waterfall approach. This rework cannot be
predicted well; however, the PO, BA and technical
experts could help to reduce uncertainty by helping
to define technical aspects as much as possible
and bring the DoD of the product backlog item
in a healthy state. Appropriate examples using
production data covering most scenarios or
processes will help developers to avoid rework.
A critical success factor to rebuild the data
model from the source system is the availability
of production data that will be synchronized for
development. The development environment needs
to have all the latest production data associated
with business processes. Access to the production
data requires approvals from data owners in
organizations and may require anonymization,
depending on industries. In the banking industry,
for example, the customer data shall not be used for
testing, and in the pharma industry, all personally
identifiable data needs to be masked. Ideally, a
DevOps team needs to be formed to ensure that
the production data is constantly available.

How Reverse Engineering
Reduced Stock-Outs at a Life
Sciences Organization
A leading global life sciences company needed to reduce the supply chain risk of stock-outs
and improve the predictability of stocks. The operational data sources provided the data
required to manage the stocks using Excel sheets that were extracted manually on a regular
basis from its SAP ERP system. However, the data could not provide information related
to stock-outs and the need for replenishments in a major business division of the client. A
data analytics dashboard application — comprising mobile and desktop versions based
on QlikSense technology — was proposed to address the functional and technical debts
and thus address various customer segments. The application could then follow individual
orders of customers across countries starting from the order until delivery. It also highlights
inventory and factories that run the risk of zero stock, which means lost revenues or delayed
business depending on other products from competitors.
The first step in building the analytics application was to reproduce the business processes from
the source system,which proved to be highly complex.As developers tried to make sense of
the data in a trial-and-error manner,many unknown business scenarios were found.No one in
the organization had a full picture of the business processes as the product team did not have
access to the documentation and SMEs with such knowledge were gone from the organization.
The PO was supported by a team of managers from different departments who helped to define
the user requirements.The BA developed the functional specifications of the application based
on the initial understanding of the source system.Further,based on the analysis of Excel sheets
and behavior of the source system,the rules of data model were developed.
On the implementation front, developers took the initial inputs from the PO and worked
together with the BA and technical architect to develop the data model of the application.
Developers analyzed the Excel sheet and used the process inputs from the BA and PO to
develop the initial build. The build was verified by the PO who further sought the inputs of
Quick Take

the team of managers to provide feedback to the developers. This development process
involved build, test, screen and feedback cycles that were iterated until the PO had fully
verified the business processes involved. The quality of application code improved with
the continuous feedback from the PO. Access to the production data in the development
environment allowed developers to verify the business processes using key examples.
The feedback from the PO,who further integrated inputs from other stakeholders,was critical
to finalize the data model.At times,the development process has frustrated the development
team as the data model was iterated multiple times.This rework was required as the PO
iteratively found inconsistencies with the existing processes or data issues, even shortly before
the announced release date. However,the development team was committed to fulfill the
defined Sprint and product goals and the results were highly satisfying for the client.
It took five months to reverse engineer the core business processes of order tracking
and stock management from the source system in the data analytics applications using
the Scrum approach; it would have taken roughly eight months to do this using the
waterfall approach. Once the data model was developed, other value adding features like a
management data dashboard and e-mail notifications for informing users about deviations
of stocks or order deliveries from any given threshold were implemented in the following
three months. This reverse engineering project has fulfilled the business case of saving
$600,000 annually through the implementation of the data analytics application to manage
stock-outs. The addition of predictive features to manage the stock situation allowed the
business to take smarter decisions in terms of stock replenishment.
This reverse engineering project has fulfilled
the business case of saving $600,000 annually
through the implementation of the data
analytics application to manage stock-outs.

Looking Forward
Today’s digital business build-out will only accelerate
in the coming decades.6
During this phase, the
demand for analytics applications will increase in
all industries. Advanced analytics applications with
innovative features could be built on top of existing
business processes in legacy applications.
Although we recommend Scrum as the Agile
framework for analytics projects because of its
flexibility and simplicity, organizations having
experience with other Agile frameworks such
as Crystal, eXtreme Programming (XP), Agile
Unified Process, etc. could assess their suitability
for initial implementation of Agile reverse
engineering. For large-scale projects involving
multiple teams, Nexus, the scaled version of
Scrum, is recommended. Here again, other scaled
frameworks such as scaled Agile framework
(SAFe), large scale Scrum, disciplined Agile, etc.
could be checked for organizational suitability.
As a result of improved team productivity in Scrum
projects, applications can have up to 50% faster
time-to-market than in waterfall projects,7
depending
on Agile organizational and team maturities. Based
on our project experiences with leading clients to
generate faster time-to-market through reverse
engineering,we believe IT organizations could also
save up to 50% of their development time and budget.
The skills of team members play a big role in Agile
execution as the team self-management is a key
factor for successful execution. The availability of
skilled resources with Scrum skills in the market
makes Scrum the Agile framework of choice in the
near future to realize business goals through reverse
engineering projects.

About the authors
Dr. Tom Philip
Senior Consultant, Digital Strategy, Cognizant
Dr. Tom Philip is a Senior Consultant in Cognizant Consulting’s Digital Strategy Team. He has worked in
the telecommunications, life sciences and aviation industries, and his works have appeared in leading
publications. Tom’s interest areas include digital transformation project management, and project failures.
Tom holds master’s and PhD degrees in information systems from the University of Zurich. He can be
reached at Tom.Philip@cognizant.com | https://ch.linkedin.com/in/dr-tom-philip.
Andrea Colavita
Data Analytics Manager, Life Sciences Practice, Cognizant
Andrea Colavita is a Data Analytics Manager at Cognizant Digital Business & Technology who works
in the business unit’s Life Sciences Practice. He has worked in healthcare, energy and public sector
industries, and his interest areas include big data, machine learning and cloud technologies. Andrea holds
a bachelor’s degree in computer science and a master’s degree in IT security. He is big data (Hadoop and
Spark) and cloud (AWS) certified. Andrea can be reached at Andrea.Colavita@cognizant.com | https://
it.linkedin.com/in/andrea-colavita-27a3b21a.
Endnotes
1 “Executive Pulse: Plans for Analytics Spend Continue Through Crisis as Data Use Issues Also Persist,” Oct. 1, Gartner
website, 2020, https://www.gartner.com/en/documents/3991286/executive-pulse-plans-for-analytics-spend-continue-
throu.
2 Teodoro Cipresso,“Software Reverse Engineering,” Handbook of Information & Communication Security, Springer, 2020.
3 15th State of Agile Report, https://explore.digital.ai/state-of-agile/15th-state-of-agile-report.
4 Ken Schwaber and Jeff Sutherland (2020),“The Scrum Guide,” www.scrum.org.
5 “Agile Practice Guide”, PMI, 2017.
6 Malcom Frank, Paul Roehring and Ben Pring,“What to Do when Machines Do Everything,” Wiley, 2017.
7 Delta Matrix,“Why is Agile Time to Market (TTM) Delivery 50% Faster?” https://www.deltamatrix.com/why-is-agile-time-to-
market-ttm-felivery-50-faster/.

World Headquarters
300 Frank W. Burr Blvd.
Suite 36, 6th Floor
Teaneck, NJ 07666 USA
Phone: +1 201 801 0233
Fax: +1 201 801 0243
Toll Free: +1 888 937 3277
European Headquarters
1 Kingdom Street
Paddington Central
London W2 6BD England
Phone: +44 (0) 20 7297 7600
Fax: +44 (0) 20 7121 0102
India Operations Headquarters
#5/535 Old Mahabalipuram Road
Okkiyam Pettai, Thoraipakkam
Chennai, 600 096 India
Phone: +91 (0) 44 4209 6000
Fax: +91 (0) 44 4209 6060
APAC Headquarters
1 Changi Business Park Crescent,
Plaza 8@CBP # 07-04/05/06,
Tower A, Singapore 486025
Phone: + 65 6812 4051
Fax: + 65 6324 4051
About Cognizant
Cognizant (Nasdaq-100: CTSH) engineers modern businesses. We help our clients modernize technology, reimagine processes and transform experiences
so they can stay ahead in our fast-changing world. Together, we’re improving everyday life. See how at www.cognizant.com or @Cognizant.
© Copyright 2021, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by any means, electronic, mechanical,
photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein is subject to change without notice. All other trademarks mentioned
herein are the property of their respective owners.
Codex 6799

Using Adaptive Scrum to Tame Process Reverse Engineering in Data Analytics Projects

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Using Adaptive Scrum to Tame Process Reverse Engineering in Data Analytics Projects

Similar to Using Adaptive Scrum to Tame Process Reverse Engineering in Data Analytics Projects (20)

More from Cognizant

More from Cognizant (20)

Using Adaptive Scrum to Tame Process Reverse Engineering in Data Analytics Projects