1

TestNext Symposium 2016

My Journey as a Software Testing Professional from Waterfall to the

Agile World

Sourav Kumar

Email id:Sourav.kumar@optum.com

UnitedHealth Group

HITECH CITY 2 BUILDING No.H09,

GACHIBOWLI VILLAGE, TS, INDIA-500081

2

ABSTRACT: We will find multiple articles or definitions online about the waterfall and the Agile

model but we seldom get the opportunity to learn from the experiences of a software

testing professional about the challenges he faced and the experiences he had while

changing from Waterfall model to Agile in projects.

This paper discusses in detail the experience of a software testing professional in

UHG while the Organization was changing its delivery model by moving from

Waterfall to the Agile World. This paper includes the challenges that the software

professional faced initially when he was reluctant and opposed to the change and the

advantages he sees at the end when he started working completely in agile model.

This paper will try to explain in detail how difficult it was to move from waterfall to

the agile mindset for the professional and will try to narrate the entire experience

gained while working in a project over the period of two years .The project that will

be discussed started off with 100% waterfall model, gradually moved to hybrid

(waterfall -agile) model and eventually when it was a 100% agile model. Once it was

pure agile, it became easy to work and deliver quality products in short span of time

with highest user satisfaction. It will also illustrate how difficult it was to work with

continuously changing requirements, how to give estimates on the go and complete

the work in an environment where every minute was worth in gold and was being

tracked.

This paper will be limited to the views of software professional and it might not

comply with all professionals, however the paper is written with a positive mindset

keeping in mind the benefit of entire target audience who will be part of it.

INTRODUCTION: Before I go ahead and narrate my experiences of moving from waterfall world to the

agile world,its important for me to explain clearly what does waterfall and Agile actually

mean.This paper is not limited to audiences who are familiar to Agile and Waterfall

model but also to everyone else who have not yet heard of these models in the Testing

Community.In order to benefit all readers let me start off with a very brief introduction of

these two models followed by the detailed answers to the questions that actually occurs to

every software testing professional when they move from the waterfall to the agile world.

What is AGILE model?

Fig 1: Agile Model in Detail

3

Agile is a concept or methodology that involves iterative development in short cycles.

It includes a high level of interaction with users or business representative, and its

flexible response to change is a positive for both business teams and project teams.

Agile development is based on a concept known as the Agile Manifesto, which is:

We are uncovering better ways of developing software by doing it and helping others

do it. Through this work we have come to value:

Individuals and interactions over processes and tools, working software over

comprehensive documentation, Customer collaboration over contract negotiation,

Responding to change over following a plan.

For a better understanding of entire steps followed in an agile model, see the fig

above.

What is WATERFALL model?

Fig 2: Waterfall Model in Detail

Waterfall model is a process that involves stages that are run from start to finish

before commencing the next stage. These stages are generally classified as:

1. Analysis - a preliminary analysis, proposes alternative solutions, describe costs

and benefits and submit a preliminary plan with recommendations.

2. Requirements – gathering the requirements of the system and what needs to be

developed

3. Design – designing the system

4. Implementation – developing the software system

5. Verification – testing the system, both system testing and user testing

6. Maintenance – ongoing support or maintenance of the system

In this methodology, the requirements are gathered at the start of the project, with

the aim of confirming them at the start to reduce cost and time impact later in the

project. It is a common belief that finding discrepancies and issues earlier in the

project will result in less time being spent than if they were found later in the

project.Waterfall is the more traditional method of development. It was the main

methodology that was taught during my college and trainings and even in the initial

years of my working in IT Organization.

Waterfall vs Agile One of the biggest discussions in IT project teams lately is the discussion of can we

switch to agile methodology from the existing software development methodology for

some of the projects? If this has left you also a bit confused, or if you just want to

know what the differences of agile vs waterfall are, or if you want to know the

answer of some of the generic questions that come up during the transition from

waterfall to the agile, please read on.

4

With the help of this Paper I have tried to come up with the answers for the below

set of questions which play a very important role in understanding the minute details

needed for transition from Waterfall to the Agile world for a software professional.

1) How a Software professional will be able to convince oneself to build

everything but with limited time, limited resources and ever changing

market?

2) How tools like ALM used mostly in waterfall was replaced with Rally as a

single consolidated tool for all testing activities like test cases, execution

report, defects logging and pulling all reports that were pulled using ALM

earlier?

3) How this paper will help understand the basic similarities and differences

between the Waterfall and Agile model and will help to achieve quality

work in future with a model suitable for their project?

4) Why it’s always a win –win situation with Agile compared to waterfall

model?

5) Real Life Examples /Case Study/Images illustrating the two models and

their challenges/benefits.

Keeping above questions in mind, let me try and answer them in an easy to

understand manner and based out of my experiences.

Fig 3: Waterfall vs Agile

1) How a Software professional will be able to convince oneself to

build/test everything and learn alongside but with limited time, limited

resources and ever changing market when his model is changed from

Waterfall to the agile one?

Software professionals can build/test everything and learn alongside with limited

time, limited resources and ever changing market by applying the continuous, fast

learning and delivering technique followed in agile. What I experienced in my initial

days of Agile methodology was when I was encountering on a daily basis with so

many Agile terms as shown in the image below and my first challenge was able to

understand each of them and their relationship with each other. If you really want to

succeed in Agile, make sure that you are really familiar with all fundamentals of Agile

and rally tool. Since I was new to this methodology, I had lot of challenges but

eventually with lot of hard work I was able to learn fast.

5

Fig 4: Commonly used terms in Agile

To keep pace and able to deliver quality products to my end users/customers, it was

very important for me to follow below rules of agile.

Fail fast but Learn Quickly.

Fail Often but Learn continually.

Fail Cheap but Learn inexpensively.

I was eventually feeling happier to see the amount of work I was getting done at the

end of each day in this new model .Within the first six months I noticed a big change

in the pattern of my work style and delivery. I could also see that initially my project

was operating in a waterfall model and then slowly we started operating in hybrid

(waterfall-agile) model where team was operating partially in waterfall because they

were unable to adapt fully to the new model. On this day when we are fully operating

in an agile model I could easily make out below points which were contributing for a

better productivity and better quality while working in Agile:

a. Documentation reduced significantly for me as well and I was able to focus

more on my actual tasks leading to more productivity.

b. All documents/requirements were present in one single source Rally and

attached to the particular user story/requirement I need to work on which

saved a lot of time which used to get wasted in searching the right version of

a document.

c. My interaction with Business/stakeholders increased due to the

demo/acceptance of my work scheduled for each user story I worked on.

d. All my test activities progress and status were also tracked through single

rally tool.

e. Based on the progress made each day, we were able to identify whether the

team is on track to complete the remaining work in the sprint.

f. With each defect logged, we were able to add the hours to the defect and

showcase why the project got delayed due to the delay in solving the no of

defects present in the release along with time consumed for fixing the same.

g. Multiple Reports could be generated on a daily basis to monitor progress on

sprint level, release level, team level or project level.

h. For any changes done to any user stories/tasks, defects, test cases

notifications are present within rally to track the same if needed.

i. Lastly if needed we have the option to sync all defects from rally to ALM in a

particular instance during the initial phases of transitioning.

j. Only in some cases, where we felt that a user story could have been well

documented like it was in case of waterfall model. In those cases we have to

go back to business and ask them to attach/update the user story with

sufficient details so that we can proceed working on it independently.

k. I was working more closely with all team members and the work style was

very much transparent.

6

2) How tools like ALM/QC used mostly in waterfall was replaced with Rally

as a single consolidated tool for all testing activities like test cases

creation, execution report, defects logging and pulling all reports that

were pulled using ALM earlier?

This will be the most important answer for the testing community as most of the

traditional testers use ALM/QC for all testing related activities and even the managers for

pulling various metrics/graphs from it.I will try to illustrate through various images the

same functionalities being present in rally tool and can be used to replace ALM ,an

overhead tool to manage the project .In case of rally we can have everything from

requirement to user acceptance at one place rather than maintaining traditional multiple

documents for many phases of testing .Considering the limitation of this paper ,I would

just illustrate/compare the basic features like Requirments ,Defects andd Reports

Generation of ALM and Rally through images/figs .While I would give the image for

both but would be explaining only Rally considering most of the testing community is

aware of ALM as it’s the traditional tool out of the two.

REQUIREMENTS

Fig 5: Requirements in ALM

Fig 6: Sprint (usually two weeks) in a release for a project

7

In the Image above I have numbered them from 1 to 8 to illustrate what they mean and

how they are used.They have been described below:

1.Velocity at which Sprint is planned(units of worked planned to be completed in sprint)

2.Showing that this iteration of a particular sprint is has how many days remaining.

3.How much percentage of requirements/user stories have been delivered and accepted

by the customer.

4.No of defects found in the Sprint.

5.Total active tasks still in the sprint.Tasks are defined within a user story upon

completion of which a user story is marked as complete.

6.Burndown chart indicates how the team and work is progressing

7.All other activities like test cases planning ,test plan,defects,reports and various imp

phases are present under these tabs.

8.Actual user stories/requirements written by business along with development on which

the entire team works upon.

DEFECTS

Fig 7: Logging a Defect in ALM

Fig 8 : Logging a Defect in Rally

8

Similarly while logging defects in rally ,we need to keep in mind that all the relevant

information is filled out as we used to when we fill it in ALM/QC.As noted above I have

numbered them from 1 to 5 which are all described below:

1.Summary of defect

2.Description which will include detailed explanation and expected and actual output

3.All properties of the defect including attachment are entered here.Some of the fields

will be mandatory as in ALM.

4.Team ,link to test case and assigned to will be covered here.

5.All comments by different stake holders are captured under discussion tab.

Reports Generation

Fig 9 : Reports in ALM

Fig 10 : Reports in Rally

All reports which were generated using ALM can also be generated using rally.There

are some default reports present which are most commonly used in projects by scrum

master and other team members.However we can always create our own reports by

configuring the parameters based on our requirements.

3) How this paper will help understand the basic similarities and

differences between the Waterfall and Agile model and will help to

achieve quality work in future with a model suitable for their project?

9

Fig 11: Cost and Schedule Driven vs Value Driven

Fig 12: Value vs Risk with time

Here are some of the main differences between Agile and Waterfall Models:

The main advantage of the Agile model is the backward scalability. Under

Waterfall approach it is not easy to change decisions which were made in the

earlier stages. Any changes in the waterfall model demands the building of the

entire project right from the start.

The flexibility of error checking during any phase of development makes the

Agile model the best approach for less erroneous results as compared to Waterfall

model. The Waterfall model can only test bugs after the development of the

modules.

Agile model provides flexibility for making changes as per customer needs and

guarantees client satisfaction. The Waterfall model suffers drastically in this

respect since it does not allow any modifications midway through the

development process.

Agile development promotes modular partitioning with options for segregation.

The rules are set down before the project is executed. The Agile approach

supports simultaneous development of different modules as per client

requirement.

10

Fig 13: Waterfall vs Agile

Here are some of the main similarities between Agile and Waterfall Models:

Traditional and Agile Share the Same Goal.

The Traditional World and the Agile World Use Many of the

Same Principles

institute multiple reviews

move forward in a step-by-step, sequential manner

move forward only when all parts of the previous steps were

complete

capture all details with extensive documentation

The Traditional World and the Agile World Use the same basic building blocks

scope

cost

schedule

performance

Once we are aware of the differences and similarities of the two models we can always

chose the best that applies to the project.

4) Why it’s always a win –win situation with Agile compared to Waterfall

model?

In a perfect waterfall world, I will end up spending time determining exactly what the

customer needs. Me and my team team will work hard developing/testing. Months or

years would pass. Then, we would meet with our customer again and would reveal the

most perfectly built system in the world. Our customer would say , “It’s exactly what I

always wanted!” But remember how many times have we actually seen that happen?

In the real world, this can go wrong if I have not fully understood my customer needs,

documented vision does not fully encompass what is wanted, customer doesn’t have time

to wait for the perfect end-result, my team runs into issues and the deadline keeps sliding,

economic or business priorities shift while we are still in development/testing.

11

Agile methodologies gave us the chance to analyse. One mis-conception with agile

projects is that planning or fully developed requirements are not needed. In many ways,

the requirements are better understood by the customer (because they often write them

themselves) and by the development team (because they must agree the requirement is

well written). The development team quickly agrees on how much effort each task will

take, which can be much more accurate than a project manager’s estimates (depending on

methodology) with a long release deadline. Another plus is that we have a better idea of

the progress being made by the team. If our team uses the agile tool correctly, I’ll know

within hours or days that a feature is at risk.

Fig 14: User Experience changes from Waterfall to the Agile World

Using an agile method, we understand as soon as our customers’ needs change and can

shift our team’s efforts accordingly. This is because we are consistently communicating

with them. Quicker release cycles mean our customer can see where features or

functionality were missed and those can be re-prioritized over other less important items

in the next cycle. The whole structure makes it easier to collaborate with our customer

and makes them feel heard and in control.

Other problems can arise in an agile project. It assumes we’ve hired good people and that

they are all-in. It expects them to be responsible and develop with speed and quality in

mind. Agile can require more discipline because it’s easier to lose focus on the big

picture and instead drive for the delivery of features. Care must also be spent ensuring re-

factoring and clean-up tasks are included in each release or every few releases.

5) Real Life Examples /Case Study/Images illustrating the two models and

their challenges/benefits.

If you see the below image closely enough, it will not take much of your time to

understand how an agile model delivered a better product which complies with

the user needs and expectation .This was possible because of intermediate

reviews of the product with product owner and making appropriate changes as

and when needed. This intermediate review was not possible with the waterfall

model which resulted in delivering something which was not actually what the

customer wanted.

12

Fig 15: Waterfall vs Agile (Real life example of delivered product)

CHALLENGES AND BENEFITS

Fig 16 : Challenges and Benefits go hand in hand

Challenges and Benefits go hand in hand when it comes to applying any

methodology and benefiting out of it. But the benefits that we have from this new

methodology outperform the challenges that we are facing.

CHALLENGES:

•Agile methodologies (e.g. Scrum, XP, Kanban, Crystal etc.) are often more

difficult to understand than linear, sequential ones – at least initially.

•Because of the emphasis on working software there can be a perception that

documentation can sometimes be neglected. The focus should be on appropriate

documentation to the audience that needs it but, if not implemented well, this

isn’t always the case.

•When implemented badly Agile can introduce extra inefficiencies in large

organizations or can be working against long standing organizational processes.

BENEFITS:

13

•Working software is delivered much more quickly and successive iterations can

be delivered frequently, at a consistent pace.

•There is closer collaboration between developers and the business.

•Changes to requirements can be incorporated at any point of the process – even

late in development.

•It gives the opportunity for continuous improvement for live systems

•It is highly transparent

CONCLUSION

Today, after working for almost two years in agile software methodologies I am in

huge favor of this methodology over others and I believe my experiences illustrated

in this paper would make many of you agree to it. I also believe that technology,

businesses and markets change so fast these days that software development needs

to be adaptable above all other qualities and since Agile methods are more flexible

than the waterfall method which means that customers’ requests are more likely to

be met .

Fig 17: Source: Version One State of Agile Survey 2013

Fig 18: Waterfall vs Agile (average success/challenged/failed)

I also felt that the rhythm that Scrum creates helps to build highly motivated teams

where productivity increases over time compared to traditional waterfall.

Having said all that, there are still circumstances in which the waterfall method can

be suitable –

For example:

14

Example 1: If an organization and the people involved in the project are not in a

mature enough state for Agile it may be more appropriate to use traditional project

management methods.

Example 2: Where requirements are guaranteed to be unchanging and there is very

little uncertainty or if the project if very simple – but those circumstances are

becoming fewer and farther between.

But these circumstances are becoming rarer with each passing year and believe me

agile is here to stay and extend to most of the project. If only we do our homework

well before moving to this methodology ,we will not only find the transition easy but

also a more productive one.

REFERENCE MATERIALS

1. https://en.wikipedia.org/wiki/Systems_development_life_cycle

2. http://info.110consulting.com/blog/bid/317786/Why-Move-from-

Waterfall-to-Agile

3. http://manifesto.co.uk/agile-vs-waterfall-comparing-project-

management-methodologies/

AUTHOR’S BIOGRAPHY

Sourav Kumar is an enthusiastic Software testing professional and an active speaker

on topics related to testing. He is an Engineering graduate and currently works as a

Senior Engineer QE in UnitedHealth Group. He has around 7 years of experience in

Specialized Software Data warehouse Testing and Automation. He is an ISTQB

certified, ORACLE certified and an AHM certified Associate .His interests include

automation, agile testing, ETL, Data warehouse, Healthcare and Banking Domain

and other forms of testing. His hobbies include playing chess and table tennis. He

has participated in TNS white paper event in 2012 , 2013 and 2014.

He has also been awarded 5th (Topic: Testing on the Cloud) in TNS 2012 and 1st

(Topic: Production Defect Reduction Strategies) in TNS 2013.

15

These experiences have given him immense confidence to come up again and

participate in TNS 2016.You can always reach out to him through his official

mail id : sourav.kumar@optum.com if you are within UHG and mail id :

sourav_nist@yahoo.com if you are from outside UHG.

APPENDIX

ETL – EXTRACT TRANSFORM LOAD

RALLY-Rally is Software that provides agile software solutions that help

streamline your agile business processes.

IT - INFORMATION TECHNOLOGY

SCRUM- Scrum is an agile software development model based on multiple small

teams working in an intensive and interdependent manner

SDLC-SOFTWARE DEVELOPMENT LIFE CYCLE