Agile Software Testing

Shifting to a New Paradigm

A Gallop Whitepaper by Mayuri Darabastu

Transition
from
Waterfall to Agile
Gallop proprietary and condential. Not for public distribution | www.gallop.net

|1

Abstract
In his article 'Tradeos: Giving up Certainty', Paul
Dolman-Darrall explored the trade-os companies typically
face when contemplating a shift from conventional waterfall-based methods to more agile approaches. As the
author rightly concludes, eective progress on this
journey often emerges from trial and error, plus ne
tuning of methods found to be eective. This is the case
with most forms of innovation, as Darwin observed. If you
dig deep into the IT department of any large organisation,
you will nd many examples of successful adoption of agile
delivery practices even if the organisation itself remains
heavily waterfall-centric. These pockets of innovation
typically emerge through bottom up endeavors usually
instigated by focused individuals or small teams that are
quick to see the local benet oered by such practices.
Company leaders have traditionally been unconcerned with
the nuts and bolts of their internal software development
eorts, but the recent challenges facing some high-prole
projects have placed these issues at the forefront of
business concerns. Hybrid agile things are often not a
good idea. They just create confusion and sometimes
extra non-value producing work. The risk is that people
cherry pick practices from dierent methods and use the
introduction of agile as an excuse not to exercise
discipline in how they operate. The second risk is that a
half-hearted adoption of agile has a great possibility of
poisoning the well for a later successful adoption.
There is already some signicant factor holding back the
adoption of agile; those naysayers will point to the
weaknesses in the half adoption as reasons why it is not
a good idea to begin with. Then it makes a subsequent
decision for this team to adopt an agile method like scrum
even more problematic. It is becoming increasingly
dicult for companies to compete successfully when their
initiatives or product improvements take many months or
even years to bring to fruition. Nimble, rapidly adapting
organizations are thriving, winning market share. They
make it a priority for everyone to nd ways to delight their
customers, while nding joy in work for people.
Slow-changing businesses that fail to engage eectively
the intelligence and passion of all their people, see their
livelihood erode and sometimes even vanish altogether.
To further complicate matters, the predominant ways in
which many executives still think, structure, and run their
organizations, work against the speed of adaptation,
despite their best intentions to the contrary.

This white paper attempts to focus on the journey of

agile and the challenges faced while transitioning from
waterfall to agile. Change is inevitable. The journey from
comfortable to new, however, is never easy and the
journey from waterfall to agile is no less bumpy. Entire
elds of study have focused on the concept of change and
cultural transformation, yet dealing with human beings
seems to be no easier now than in decades past.

1. Setting the Goals

So if the transition has already begun, do we need to set
up Goals or destinations? Or in another note, list out the
various needs that necessitated the requirement to
become more agile. There can be various reasons such as
Speed, Quality, and adaptability to change; return on
investment can be any one or combination of reasons.
This is not an engineering project, where we can train
people and start producing the software from the rst day
itself. This is a philosophy. This is an art. This is a mindset
change of the people who will be adopting agile. Before
changing the companys vision, we need to analyze the
pitfalls and mindset of the people who make the company.

2. Waterfall and Scrum

To give a clear overview of the reasons to adopt Scrum, the
theory behind both methods is planned and a comparison
is made between Waterfall and Scrum in the following
section.

2.1

Waterfall Models

In the history of the software industry, as software

products were getting bigger there was an urgent need
for better prediction and control over the output of larger
software projects. This resulted in the sequential waterfall
model. The waterfall method follows a sequential order of
phases. In the rst stage the requirements of the customer
are determined and are xed before the design is taking
place. This is a strong characteristic of the model, it ows
downwards. Each stage consists of a set of activities and
deliverables that need to be nished before moving to the
next stage. Requirements are xed upfront, the design is
taking place and the implementation follows.

Gallop proprietary and condential. Not for public distribution | www.gallop.net

|2

Then the software is tested before it is delivered to the

customer. The advantages of the waterfall model are:
Its sequential, easy to implement
Minimal resources are required to implement it
Proper documentation
The waterfall model reduces uncertainty by clarifying
requirements and producing design documents early.
This makes the waterfall approach highly predictable.
In some projects that are not subject to changes in
requirements, this is the best approach for software
development. Back in 1970 the waterfall method was
founded by Royce but he immediately admitted this
method is risky and invites failure. Testing is taking place
only at the end of the cycle and may require a redesign of
the system. This is so disruptive that either the
requirements must be modied or a substantial
change in the design is required. In fact, the development
process needs to be completely re-done and causes a
100% overrun in schedule and/or costs. A more
iterative-like approach was proposed to x this issue but
because of its simplicity the waterfall-model gained
ground in the industry, against Royces intention.

2.2

Analyzing the Pitfalls of Waterfall

The major reasons for the failure of the waterfall

approach to software development and reason for
adaption of agile are:
Requirements are not fully understood before the
project begins.
User knows what they want only after they see an
initial version of the software.
Requirements often change during the
software development process.
New tools and technologies make implementation
strategies unpredictable.
Many projects have faced the above issues that made the
waterfall model ineective. This Predictive model cannot
cope with rapidly changing business environments.
There was need for an adaptive approach on software
development. Agile is an adaptive approach on software
development as most software development projects
cannot be predicted and planned upfront and agile is a
more exible way to cope with ever changing business
demands. It uses short cycles to add maximum value for
the customer.

2.3

SCRUM

Agile methods are lightweight software design processes

based on small teams using exible technologies to iteratively improve software using customer feedback to
converge on solutions.
According to the Agile Manifesto, the major factors of
agile methods are:
Early customer involvement: refers to top-level
commitment, management involvement, and user
involvement, user participation, lead users.
Iterative development: was known as concept testing,
beta testing, and probing in marketing and iterative,
incremental, evolutionary, spiral, and time-boxed
development in the software eld.
Self-organizing teams: were known as self-organizing
dynamic teams, self-determined groups, small,
decision-making groups, task oriented groups, and
autonomous groups up to the 1960s.
Adaptation to change: came from organism biology,
cybernetics, systems theory, systems dynamics,
Double-loop learning, adaptive organizations, learning
organizations and systems thinking.

Gallop proprietary and condential. Not for public distribution | www.gallop.net

|3

In particular, agile development accelerates the delivery

of initial business value, and through a process of continuous planning and feedback, is able to ensure that value
is continuing to be maximized throughout the development process.
As a result of this iterative planning and feedback loop,
teams are able to continuously align the delivered
software with desired business needs, easily adapting to
changing requirements throughout the process. By measuring and evaluating status based on the undeniable
truth of working, testing software, much more accurate
visibility into the actual progress of projects is available.
Finally, as a result of following an agile process, at the
conclusion of a project is a system that much better
addresses the business and customer needs.

Benets of Iterative and Incremental

Delivery
Iteration is a mini-project that results in a version of the
system that will be released internally or externally. This
version is supposed to oer incremental improvement
over the previous version, which is why the result of
iteration is called an increment. The iterative development model allows for early adjustments to the product
during development, rather than nding the problem
once it is too late and having to spend a lot of time and
money trying to incorporate the changes into the project.
The corrective actions in the iterative development
model are normally done at every interval; they are
highly accurate and specic this is because if there is a
fault in the requirements or design stage than it can
hopefully be found sooner rather than later.

These corrective measures are also eective as they

reect the outcome of the specic stage of the project.
Iterative development is more adjustable to changes as it
considers each stage like a vital portion of the
development cycle. Incremental software development,
with short increments, is a very useful technique to
reduce project risk and to deliver value faster to users.
Each release provides opportunities for useful feedback
and re-planning, so that the nal product meets the
users real requirements. The project is at its most "agile"
when we consider only one increment at a time.

History of the Agile Manifesto and the

Four Values
Agile is dened in the dictionary as quick, brisk, and
nimble. True to its denition, the agile methodology aims
at being nimble and quick moving in response to change in
requirements and other issues that arise during the development process.
It is based on iterative and incremental development
wherein the requirements are gathered through coordination and collaboration of highly motivated self-organizing and cross functional teams. The agile development
methodology pursues opportunities to have a clear vision
of the direction of a project throughout the development lifecycle. This is achieved through regular cadences
of work, called sprints or iterations, at the end of which
teams must have an output of a potentially shippable
product increment.
Laying emphasis on the repetition of the work cycles as
well as the functional product being developed, agile
methodology is described as iterative and incremental.
Agile empowers the team to continuously plan the release
to optimize the value throughout development. It helps
stakeholders to calibrate releases for prots in the real
world and helps companies build the right product.
Towards the beginning of this century, the Manifesto for
Agile Software Development was published and reads as:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
This means that while there is value in the items on the
right, the value of the items on the left are more. It is also
important that the manifesto says over and not instead of
so going Agile is not an excuse for no documentation, not
to look at requirements, or having no plans.
Being Agile is a state of mind. Agile is not about the tools
or methods to use but how to use them. It is about the
mindset and approach problem solving. Practitioners do
not automatically become Agile by using SCRUM.

Gallop proprietary and condential. Not for public distribution | www.gallop.net

|4

There is no such thing as an agile tool. Also the Agile Manifesto and Principles are guidelines, really good guidelines
based on practical experiences that has proven to work,
and should be treated as such.
The values on the left are more important than on the
right. These values compensate for the shortcomings of
the The Agile Software Development Methods have the
potential to provide higher customer satisfaction, lower
bug rates, shorter development cycles, and quicker
adaptation to rapidly changing business requirements.
Scrum is a framework to organize people and deliver a
quality product on time. Scrum is not a process or a
technique for building products; rather, it is a framework
within which you can employ various processes and
techniques.

2.4

SCRUM TEAM

The Scrum team consists of a Product Owner, Scrum

Master and a Development Team. Scrum teams are
self-organizing and cross-functional, they are not directed
by others outside the team and have all the competencies
to accomplish their work.
There are three core roles and a range of ancillary roles.
Core roles were previously referred to as pigs and ancillary
roles as chickens. The core roles are those committed to
the project in the Scrum processthey are the ones
producing the product (objective of the project). They
represent the Scrum team. Although other roles may be
encountered in real projects, Scrum does not dene any
team roles other than those described below.

---------- ----------------------

----------------------------- -

----- ----------- Design ------------

Implementation

Analysis

-----------------------------

Testing

The Product Owner

Represents the stakeholders and is the voice of the
customer. He or she is accountable for ensuring that the
team delivers value to the business. The Product Owner
writes (or has the team write) customer-centric items
(typically user stories), ranks and prioritizes them, and
adds them to the product backlog. Scrum teams should
have one Product Owner, and while they may also be a
member of the development team, this role should not be
combined with that of the Scrum Master.
The Product Owner interfaces with management and both
internal and external stakeholders who want to inuence
to the Product Backlog. The Product Owner has to be
convinced, if a priority of an item needs to be changed, or
a new item added. No one else but the Product Owner is
allowed to change the priorities on items the Development
Team is working on.

The Scrum Master

Responsible for ensuring Scrum is understood and enacted.
Scrum Masters 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 and helps
those outside the Scrum team understand which of their
interactions with the Scrum team are helpful and which
arent. The Scrum Master helps everyone change these
interactions to maximize the value created by the Scrum
Team.
When the product Owner focuses on the value of the
project being developed, the Scrum Master focuses on the
development process and the mentor for the Scrum team.

The Development Team

Consists of professionals who do the work of delivering a
potentially releasable Increment of Done product at the
end of each Sprint. Only members of the Development
Team create the incremental Development.

Gallop proprietary and condential. Not for public distribution | www.gallop.net

|5

Teams are structured and empowered by the organization to

organize and manage their own work. The resulting synergy optimizes the Development Teams overall eciency
and eectiveness. Development Teams have the following
characteristics:
They are self-organizing. No one (not even the Scrum
Master) tells the Development Team how to turn Product
Backlog into Increments of potentially releasable
functionality;
Development Teams are cross-functional, with all of
the skills as a team necessary to create a product
increment;
Scrum recognizes no titles for Development Team
members other than Developer, regardless of the work
being performed by the person; there are no exceptions
to this rule;
Scrum recognizes no sub-teams in the Development
Team, regardless of particular domains that need to be
addressed like testing or business analysis; there are no
exceptions to this rule; and,
Individual Development Team members may have
specialized skills and areas of focus, but accountability
belongs to the Development Team as a whole.
The whole team together is responsible for the product. The maximum size of a Scrum team is 9
members.

The Sprint Planning is the rst meeting in a Sprint. In this

meeting the work to be performed in the Sprint is planned.
This plan is created by the team and is agreed upon. The
Scrum Master ensures that the planning is realistic. The
rst topic is what has to be done in this Sprint. Objectives
are discussed and the Product Backlog items that should
be completed to achieve the Sprint goal.

---------------------

2.4.1. Events

All events in Scrum are time-boxed, they have a maximum

duration. The length of a Sprint is xed, other events may
be shorter when the purpose of the event is achieved. The
Scrum meetings are a formal opportunity to inspect and
adopt something, they are essential to get a high level of
transparency.

---------- -----------------

--- ---------------- -The Development Team must decide, based on their

capacity, how many Backlog Items they can accomplish
over the upcoming Sprint. The second topic is the way in
which the chosen work is going to be done to turn this
functionality into a potentially releasable product. The
Backlog Items are decomposed in work items of a day or
less and added to the Sprint Backlog. These work items
should be fully understand by the team members, possibly
with the help of the Product Owner.
The Daily Scrum is a meeting of 15 minutes every day. Its
purpose is to synchronize activities and create a plan for
the next 24 hours. The Scrum Master inspects the work
done since the last meeting and the work that has to be
done before the next one. These meetings are held every
day at the same time and place. Every team member
explains:
What work they have done since the last meeting;
What work they are going to do today;
If they are see any impediment that prevents an
individual or the team from meeting the Sprint goal.

---------------------------

The Sprint is a time-box of four weeks or less during which

a potentially releasable (working) product is created. Each
Sprint has a specic goal on what is going to be built. A
new sprint starts immediately after the previous Sprint.
Only in exceptional cases the Product Owner can cancel
the Sprint, but this is rarely done because of the complications that can occur and the short nature of Sprints. The
Sprint consists of Sprint Planning, Daily Scrums, development work, Sprint Review and Retrospective.

The purpose of Daily Scrum is to check progress towards

the goal and completing the work in the Sprint Backlog.
This optimizes the probability that the goal is met. Daily
Scrums improve communications, eliminate other meetings,
identify impediments to development for removal, highlight and promote quick decision-making, and improve the
Development Teams level of knowledge. This is a key
inspect and adapt meeting.
The Sprint Review is held at the end of each Sprint to
inspect the product that is implemented during the Sprint.
This also includes feedback to the Product Backlog and
decisions on what needs to be done in the next Sprint. It is
an informal meeting and is intended to elicit feedback and
foster collaboration.

Gallop proprietary and condential. Not for public distribution | www.gallop.net

|6

The Sprint Retrospective is intended to reect on the

results of the Sprint and create a plan for improvement.
This plan makes the next Sprint more eective and
increases quality. Improvements may be implemented at
any time, but the Sprint Retrospective provides a formal
opportunity to focus on inspection and adaption.

2.4.2. Artifacts
Scrums artifacts represent work or value to provide
transparency and opportunities for inspection and
adaptation. Artifacts dened by Scrum are specically
designed to maximize transparency of key information so
that everybody has the same understanding of the
artifact.

Unnecessary items are removed. Only the Development

Team can change the Sprint Backlog during a sprint. It
gives a clear overview of the work that is performed by the
Development Team during the Sprint.

----------------------

that might be needed in the product; it is the only source

for requirements. The Product Manager manages the
Product Backlog. In the beginning of development it only
represents the rst known and best-understood
requirements, later on it evolves as the environment
where the product will be used evolves.
Thus, the Product Backlog is never complete and always
represents work in progress. It lists all features, functions,
requirements, enhancements and xes that are needed
for future releases .
The Product Owner and Development Team constantly
add detail or estimates to the Backlog, this is an on-going
process called Backlog renement. Items with higher
priority that are on the top of the list are usually clearer
and more detailed than those with lower priority. High
priority items need to be rened enough to complete
them in the next Sprint. If so, they are considered ready
for planning in the next Sprint.

---------- -----------------

---Product
--- ---The
-----Increment is the sum of all items completed
- and- the previous Sprints. The new increduring the Sprint---- condition and must meet the
ment must be in useable
-- -denition of done.
The Product Backlog is an ordered list of functionality
The Denition of Done is a description of when a Backlog
Item can be considered done and is dierent per Development Team. They have a shared understanding of when
work is complete to ensure transparency .
According to case-study research in ve companies the
conclusion was that SCRUM works in any environment
and can scale into programming in the large. Scrum can
result in a high productivity increase in comparison with
traditional methods.
Another advantage: Scrum cuts through project complexity
and brings order from chaos by enabling a team to organize itself, which allows a particularly productive order to
emerge.

However, there are some pitfalls in Scrum implementation

which are stated below.

---------------------------

The progress toward completing specied work is tracked

by the Product Owner and made visible to all stakeholders. This can be visualized in various ways like
burn-downs, burn-ups or cumulative ows. These have
proven useful .

The Sprint Backlog is a subset of the Product Backlog

items selected for the Sprint. It represents the functionality that will be added in the next increment and the work
to be done to reach the goal of this Sprint. The Development Team can update the Sprint Backlog during the
Sprint. Tasks are added and if tasks are completed, the
remaining work is updated.

2.5 Pitfalls of Scrum

Scrum does not provide adequate design
documentation necessary for future development. It may
not work well with projects that require a high level of
innovation as its focus is on bringing order to the development process.
Quality assurance and testing need to be done in a
dierent way compared to Waterfall, there are some
challenges in implementing a new testing methods.
Teamwork and dedication of team members is very
important.
Resistance to change is a major factor in the adoption
of Scrum.

Gallop proprietary and condential. Not for public distribution | www.gallop.net

|7

2.6 Hybrid
Another disadvantage of Scrum is the uncertainty. There
are two competing priorities: the need for certainty by
following rigid and formal engineering processes, and the
need to remain agile to deal with drift in requirements and
uncertainty.

In the traditional waterfall approach, managers were in

control: they decided what work is being done and when.
In Scrum there exists a lot of autonomy for the team. The
managers role is completely dierent; managers have to
learn how to behave dierently in a Scrum environment.
One of the problems is that managers have to understand the dierence of managing people, as opposed to
leading people. In Scrum the manager needs to listen to
the team and help them remove impediments

------------------

-------------------------------------------Testing

Deploy

--------

2.7.1 Changing Role of Managers

Coding

Design
--------

According to several studies, the following known problems

were identied and summarized in the implementation of
Scrum:

--------

Transition Challenges

------------------

--------------------

--------

2.7

Analysis

--------

A case study at two companies showed that teams

under-emphasized or failed to implement critical
elements of the Scrum framework. Water-Scrum-Fall is
considered the reality in most agile organizations today.
This results in failure to realize the business benets of
Agile: faster time-to-market, increased business value,
and improved exibility and responsiveness. Water
denes the upfront work that is required by governance
rules. It includes project planning and budget. Requirements
are specied. Teams use Scrum to develop software which
requires frequent software releases to get feedback.
However, most organizations do not have the architecture required to support dynamic, exible releases; instead,
they do infrequent releases backed by heavy process and
governance. This is the Fall part; the use of agile processes will not change the enterprise architecture.

Requirements
----------------------------------------------------Requirements

--------

Sometimes the implementation of Scrum leads to a

framework where some key parts are left out, given low
priority or traditional approaches are combined with
Scrum. This is referred to as Scrum But. Surveys show
that 50% of Scrum teams worldwide cannot get software
tested at the feature level by the end of a Sprint violating
the second principle of the Agile Manifesto.

------------------

End
-------------------------------------------

This is caused by specialization: team members dont

want to commit to others work and decision-making is
dicult.
The Role of the Scrum Master is to enforce the constraints
of Scrum and improve communication between team
members. If this is not done properly and the team has
too much freedom, the team might slowly drift back to
the old ways The self-organized team nature of Scrum
immediately surfaces negative outcomes from lack of
trust, fear of conict, lack of commitment and
accountability, and inattention to results. The Scrum
Master must identify and clarify these impediments and
then work with the team and Management to remove
them.
The transition to Scrum needs full support of upper
management. Not having the full support of upper
management is a great challenge. Lack of resources and
training can cause unmotivated employees. Scrum
creates less documentation so upper management might
insist to create more documents to enforce the command
and control structure they used in the old methods. This
conicts with one of the core values of Agile, less
documentation and can cause extra work pressure in
Scrum teams. Managers are used to command and
control.

Gallop proprietary and condential. Not for public distribution | www.gallop.net

|8

Managers are used to command and control. Team members in Scrum are able to gure out how to do their work,
if they get instructions they arent free to do their work
the best way possible. This is a signicant change in the
manager role. This problem of the Scrum Master
controlling and pushing instead of letting the team organize itself is also stated in.

2.7.2 Team Autonomy

There are three types of autonomy in Scrum teams:
external autonomy, internal autonomy, and individual
autonomy. External autonomy is the inuence from
outside the team on the teams activities; internal autonomy refers to the degree in which the team members share
decision authority and individual autonomy is the amount
of freedom an individual has in completing his tasks.

2.7.3 Clear Backlogs

A factor that inuences productivity in a negative way is
the lack of a clear backlog. Developers need to fully
understand what they are expected to do (what the
customer wants). There needs to be a focus on preparing
work to ensure that backlogs are complete and clear. To
check if a backlog is complete, a checklist could be used.
Improperly formed Product Backlog content should be
rejected
User stories should be complete, have acceptance criteria, and the usability tested before added to a sprint.
User stories need to be formed properly, prioritized and
ready before allowing them into a sprint. If the developer
doesnt understand the purpose of what he is designing,
it will seriously aect his productivity. Its considered very
important to have close contact with the customer.
The backlog-items need to be in priority order, on top are
the items that add the most value. There is always a risk
that Product Owner or stakeholders assume that they
own the backlog and prioritize backlog items that are less
important considering the whole product or the business.
Most of the time customers do not know what they want,
resulting in unclear requirements. It is important to have
a high communication bandwidth with the customer.

Doing a project that provides the most value for the

customer and provides solutions to real need benets
dedication and productivity. The denition of work items
should be consistent. Estimated and real time for completion
of a task should be tracked to get better estimates in the
future. A physical Scrum Board gives a good overview of
the status of a Sprint, with columns like Product Backlog,
Sprint Backlog, Work in Progress and Done. [1]

2.7.4 Coaching / Learning

The importance of coaching is often underestimated.
Agile master or Agile coach is an essential role during
agile adopting process in any organization.
If a developer doesnt know the constraints of Scrum,
there is a chance of falling back to old methods. A clear
understanding of Scrum is essential, and this should be
focused on in the implementation of Scrum. An
experienced coach should be in place during the
transition to propagate the core values of Scrum and to
respond on questions about the process. Usually this
coach has the Scrum Master role.
According to a survey among Scrum Masters, the following advice is given: Take your time, it takes time to get
used to Scrum, it wont all change overnight and
Prepare for constant learning and do not read the
manuals like a bible. This emphasizes that every team is
dierent and every team is implementing Scrum in a
dierent way.
A case-study also states that changing project management
and programming habits is dicult and takes time. It
comes with training and commitment to change.
Another case-study emphasizes the importance of training
Product Owners and getting outside coaches involved
early. The transition needs guidance of an agile coach.
Over-enthusiasm for agile and fast adoption can lead to
problems. Teams often think Agile can solve their problems
immediately. A drop in productivity can occur when
adopting agile methods takes more time than expected.

Gallop proprietary and condential. Not for public distribution | www.gallop.net

|9

This can cause the team to be less optimistic and fall back
to old Waterfall methods to meet the deadlines. Another
important factor is feedback inside the team. Team
members need to give continuous feedback to each other
so they can improve their way of working. This requires
openness and transparency. Often problems are not
reported because team-members perceive the problem as
personal. Another reason is lack of trust in the team or
Scrum Master. Also, if problems are not handled, the team
could stop reporting them. This continuous learning
process takes time and if work pressure is high this has a
negative impact on learning.

2.7.5 Productivity
Each Sprint in Scrum is 2 to 4 weeks. During this sprint, the
teams should stick to the Sprint backlog. Only in exceptional
cases (when productivity is not aected) work can be
added to the backlog. During sprints there is a total
inexibility in what to work on, during the planning
meeting backlogs are added and the Sprint backlog is
xed. This sometimes causes a perception of inexibility,
because direction cannot be changed immediately.
Managers thus could be sceptic about this inexible way
of working during sprints, but it is one of the most
important constraints of Scrum. Not respecting this will
cause a drop in productivity. Measurements of productivity
should be carefully chosen, it inuences the way people
work.
Over-commitment is a bad habit. If someone is pressured
to commit to an outcome that is not realistic, this can
cause serious problems in productivity. Work pressure is
high and quality might be at risk. On the other side, if
maintenance and bug xing is taking too much time the
productivity might also be at risk.

2.7.6 Resistance to Change

A study on the acceptance of Scrum shows that resistance
to change is a major factor in de adoption of Scrum. This
also comes forward in another study: The problems are
mainly caused by resistance to, or over-enthusiasm for,
agile practices within a software development team.
The abrupt change in the development structure can
cause resistance. Testing is an important factor in Scrum,
so testers might resist because of the extra work that has
to be done. Managers might feel uncomfortable with less
documentation. Costs and planning cannot be foreseen in
detail because requirements can always change.

Projects are open-ended so it is harder to accept this

technique as it creates more uncertainty.
In a waterfall-based environment the introduction of
Scrum might feel risky. It creates a feeling of uncertainty
compared to waterfall; requirements are not fully stated
upfront. Functional specialization is a waterfall habit but
in Scrum members need to be cross-functional. These
dierences can create resistance to the Scrum-method.

2.7.7 Quality and Testing

The goal of short iterations is to create the most business
value for the customer. This seems to be in conict with
the need for long-term quality. Quality requirements are
often forgotten in the need of keeping the time schedule.
If the Denition of Done is not strictly enforced, there will
be quality problems because for example testing is not
done properly. Testing in agile should be done continuously.
The developers should design unit tests while coding, this
is critical in agile development.
Automated build and deploy systems are a critical part of
agile and should be used. Practices like test driven
development, pair programming and continuous
integration are dicult to implement. Unhealthy technical
debt is a trick used by developers to solve a problem to
the prejudice of quality. Defects in software delay the
release, make it dicult to maintain and rigid in the face
of changing business needs. This is caused by a bad
estimation of the time needed to complete work items.
Over-commitment can lead to bad quality. If the completing
product backlog is taking more time than expected, teams
might drop testing and refactoring or it can cause
overtime which is not permitted. The lack of documentation
also can be an issue. Often work needs to be handed over
to another developer. In that case the documentation
needs to be clear, otherwise it will raise questions which
negatively impact productivity.

Gallop proprietary and condential. Not for public distribution | www.gallop.net

| 10

3. Conclusion and Recommendations

The transition from Waterfall to Scrum is not easy, as is
conrmed by literature research. It comes with commitment
to the values of Scrum and requires a mind shift of all
employees within an organization. The team is becoming
the central part from within multi-skilled professionals
work together to create a product based on customer
needs. The main challenges in this transition are the facilitating role of managers, the absence of a command and
control structure, empowerment of the self-steering
team, providing value to customer needs, understanding
Scrum values, resistance to change, and quality of the
product.
In this case the development teams are using Scrum but
the rest of the organization doesnt yet work in an agile
way. There still exists a command and control structure
with a layer of Prince2 Project Boards between the teams
and the upper management. There needs to be a more
facilitating and supporting role for the Project Board to
the team, for example to remove organization wide
impediments.
There also exists a Project Manager who is in contact with
the Scrum Master of the teams but it might be possible
that the Scrum Master can take over his tasks. The
pre-specication is done in a traditional way by Business
Analysts before its added to the Product Backlog. Placing
the Business Analysts in the team would solve the
eciency problem, because they are then working in an
agile way.
After the pre-specication the team delivers functionality
every Sprint, but after that the release process is traditional.
There are several big releases per year but a release takes
about two months of testing. This slow release process
exists because of the dependencies between the 42
dierent services; the complete system has to be tested
before it can go to production. These services should be
independent. Only in this way the time-to-market of the
software can be reduced, because most of the testing can
then be done within the Scrum teams. The mind shift
within the team is also an issue.
Managers need to behave dierently in a Scrum team;
instead of managing they should be facilitating the team.
Monitoring the process and removing impediments are
the main tasks of the Scrum Master. This company hired
external Scrum Masters who also function as coaches for
the team. The desire is to eventually have Scrum Masters
in-house.

This should be given high priority, because if experienced

Scrum Masters leave, there should be potential Scrum
Masters in-house to take over their tasks.
The absence of a good Scrum Master results in a bad functioning team where the process is not monitored and
impediments are not removed. Knowledge-sharing within
and between teams should be facilitated with regular
meetings. These meetings should be cross functional to
share each others working habits. Standard ways of working should be established and documented to cope with
changes in human resources, knowledge needs to be
preserved. In this way multi-skilled teams can emerge,
who can work together in a better way.
Story-points for backlog items are registered in a system to
get better estimates but deviations from these points are
not registered at the end of the Sprint. Reasons why some
backlog items are taking more or less than the estimates
should be registered and analyzed to get better estimates
in the future.
Over-commitment leads to technical debt and should be
prevented. Pushing to deliver more functionality for the
customer at the cost of quality is a bad habit. An organization
wide Denition of Done is not functioning well. The list is
too long and is a combined list of all DoD within the
organization. This gives the perception of quality control
but has no commitment because each team is functioning
in a dierent way. Each team should formulate their ownDenition of Done.
Another interesting observation is that 5 of the 7 Scrumteams are externally hired. This comes with a risk because
if a project is nished or there is a change in employees
within teams, knowledge ows out of the organization.
This is remarkable and also emphasizes the importance of
knowledge sharing.

Gallop proprietary and condential. Not for public distribution | www.gallop.net

| 11

References
1. Challenges in the Transition from Waterfall to Scrum a Case study at Port base
http://referaat.cs.utwente.nl/conference/20/paper/7427/challenges-in-the-tansition-fromwaterfall-to-scrum-a-casestudy-at- portbase.pdf
2. The Corporate Agile Journey A Practical Viewpoint
http://www.infoq.com/articles/corporate-agile-journey
3. How to transit from waterfall to Agile- Amit Malik Blog
http://amitsinghmalik.blogspot.in/2012/07/how-to-transition- from-waterfall-to.html
4. Accredited Scrum Master (ASM) - Agile Certication ACI ASM handbook
5. Blog Agile / Scrum Making the successful transition to Agile development - Making the successful transition to Agile
development. By Tom Helvick
6. Agile Journey - Steps along the way to Being Agile"- http://agileadventure.blogspot.in/
7. Scrum (Software Development) http://en.wikipedia.org/wiki/Scrum_%28software_development%29

About Gallop
Gallop Solutions is a US based Colocated Independent Testing Services & Specialist QA Stang Services Company operating
since 2003 with oces in Philadelphia & California. Our services are backed by Proprietary Testing IP (Enterprise Test Acceleration Suite - ETAS) for enhanced productivity and in-house R&D teams. We are a 100% subsidiary of Cigniti Technologies,
World's 3rd largest independent software testing services company with over 1600 consultants globally across various
domains with 400 located in North America.
Gallop constantly innovates and invests in R&D around software testing and contributes immensely to the software testing
community by thought leadership blogs, articles and whitepapers. World's largest and leading organizations have relied on
Gallop's specialist independent software testing services for more than a decade and have achieved signicant market acceleration, returns on investments in their software quality initiatives.

Corporate Head Quarters

Gallop Solutions Inc.
630 Freedom Business Center,
3rd Floor,
King of Prussia, PA 19406
Email: contact@gallop.net
Phone: +1 610 768 7736
Fax:
+1 610 768 7775

West Coast Oce

39899 Balentine Drive, Suite 200,
Newark, CA 94560
Email: contact@gallop.net
Phone: +1 510 933 8330
Fax: +1 610 910 3476