The latest buzzword that’s doing the rounds in the Software
industry is ‘Agile’. Even if you are not directly connected to the Software and
IT industry, chances are that you must have heard this term a number of times.
More and more software companies and teams are using the Agile method to
develop and test software. Agile Scrum coaches and practitioners, developers, testers
and managers who have experience in ‘Agile’ methodologies are in great demand
these days.
But what is this ‘Agile’ methodology and why is it so
popular? Why are so many IT organizations big and small switching over to the
‘Agile’ way of doing things? How exactly does ‘Agile’ function and what are its
inherent advantages which make it so favoured? If you are new to Agile then I’m
sure that these questions will be popping up in your mind frequently. With this
blog, I aim to explain the ‘Agile’ way of doing things and unravel the reasons
for its popularity.
To fully understand ‘Agile’ we have to look at the following
points:
a)
The software methodologies used before Agile
came into practice (Ex: the Waterfall model)
b)
How the ‘Agile’ model originated. What its’
salient features are (the Agile manifesto).
c)
What benefits do organizations, companies and
teams derive by using this methodology.
Let’s define ‘Agile’ first. What exactly does ‘Agile’ imply?
The dictionary defines ‘Agile’ as the physical ability to move quickly and
easily. In mental terms, it means to think and understand things quickly. In
the broad sense, it means to be
positively responsive towards changing conditions and to adapt quickly. In
other words, it implies flexibility and quick acceptance of change. This
feature is the crux of Agile and the foremost reason why it is so popular
nowadays. In today’s rapidly changing and evolving software landscape Agile
helps teams respond to change more effectively by being more flexible and adaptable
to changes in the product. And how exactly it does that is what I will cover
later.
To understand how Agile came into place, let’s take a look
at how software was developed before Agile. Before Agile, Software companies
mostly followed the Waterfall methodology of developing software. The waterfall
method is a linear way of designing and developing software in which each phase
of the SDLC is an independent process which follows a linear path. After one
phase is completed, the next phase starts and so on and so forth until the last
concluding phase is reached. As indicated, Waterfall follows a straight path.
Each phase starts only after the preceding phase ends. There is very little
scope for phase overlap. The ending of one phase signals the start of the next
phase and so on till the last phase is done. The figure below shows a typical
waterfall process flow:
In the early days of Software development, requirements were
more or less static and there was very little scope for change, if any. Well
not exactly, but Software was more or less simple and the requirements were
more or less straightforward those days with no frequent changes in scope and
functionality. In a typical waterfall scenario, the effort would have proceeded
in this manner:
a) Requirement Gathering:
-
Client or BA(Business Analyst) team prepares the
requirement documents containing details of the application / product to be
created
-
Project team liaises with the Client / BA team
to discuss the following app / product
-
Queries are raised by respective teams (Dev / QA
/ DB) etc. which are resolved by the Client / BA team.
-
Client signs off the requirement document after
all queries have been successfully resolved.
-
This acts as the trigger for the next phase.
b) Planning:
-
Planning phase is kicked off after requirement
sign-off.
-
Dev / QA team create plans for their respective
objectives.
-
Plans are reviewed and approved by stakeholders.
-
Planning phase ends. Next Phase starts.
c)
Design:
-
Design process starts after plan is approved.
-
Dev team starts coding / QA team starts
preparing the test cases
-
Dev teams creates prototype of the app and runs
unit tests.
-
Product is released for testing after Unit tests
pass.
-
QA team reviews and sends test cases for sign
off.
d)
Execution:
-
QA team conducts a sanity test and starts
testing if sanity is cleared
-
Defects are logged and sent to development team.
-
Defects are resolved by Dev team.
-
After acceptance criteria has been met, testing
stops
-
QA team prepares report and releases app for UAT
testing.
e)
Closure:
The QA team prepares a test summary report for reference to all stakeholders.
The software is released for UAT after which it is deployed to Production.
-
QA team prepares Test summary report for all
stakeholders.
-
Software is released for UAT and sub-sequent go
live.
So as can be seen, Waterfall is a fairly simple and
straightforward process.
Let’s take a real world example. Let’s say your company has
got a project for making a desktop calculator application. You are the project
manager and have the choice of choosing the workflow for making this app. Which
approach will you adopt? The requirements have been clearly spelt out by the
client. You have an experienced Dev and QA team to handle the proceedings. In
such a case, the waterfall method is the best way. So you proceed in a phase to
phase manner.
- Your project team sets up a project kick-off
meeting with the client. The client outlines his product scope and vision and
provides the high-level requirements.
- The BA team liaises with the client and prepares
the calculator requirement / scope document.
- Based on the high level requirements and the
scope document, the project team clarifies requirements with the client. Once
all requirements have been clarified, the client and the project team signs off
on the requirement.
- After Sign-off, the Project team begins planning
phase. Respective teams prepare estimates and start the planning process. Risks
and mitigations are identified and strategies are made for coding and testing
respectively. Architects plan and prepare the architecture for the app.
- The design process starts after the Planning
phase. Development team starts coding and the QA team starts preparing the test
cases. The dev team makes the first prototype of the app and releases it to QA
after unit testing. Design phase ends.
- Execution phase starts. QA team conducts a
sanity test and based on outcomes determines further testing.
- After execution is done and the test completion criteria is met, execution stops and the QA team prepares the test summary report.
It looks perfectly simple and logical right? I mean, what
could go wrong with this one? Why all the hullabaloo over Agile when you can
develop the product in a simple and straightforward means by Waterfall? Well,
that’s because the software requirements were not very complex. Application
requirements were clear from the start and there was very little scope for
change. The team knew what to work upon and could thus, plan and strategize
effectively for developing and testing the product.
But what if any change request came about from the client?
Let’s say, the client requests another new button or tab or new functionality
to be added. What then? Two factors would come into play in such a case:
a)
The Nature of the change request (How big is the
request, how will the scope be impacted, what is the workaround required)
b)
When the Change request is made. A change
request (or CR as it is abbreviated) introduced earlier can be effectively
integrated into the cycle without too much workaround. If introduced at a later
stage, it could be a cause for concern as it might lead to more product rework,
re-coding, re-scripting of test cases etc.
Usually, the earlier the change request is made the better.
If the CR comes in the early stages, the project team can calculate the
necessary rework and impact to the current scope and schedule (which probably
won’t be much since much of the work has not started anyways). The team makes
the necessary changes in the plan for incorporating the new CR and work starts
again.
If however, the CR comes at an intermediate or late stage of
the project, then incorporating it would look a bit dicey. Here, the factors a
and b mentioned above would come into play. If the CR is either too large in
scope and / or comes very late in the project (ex: a scope change during the
testing phase), the PM should not hesitate to point out to the client that
incorporating this CR is a huge risk and should recommend adding it in the next
release.
The typical risks associated with attempting to incorporate
the new CR at a later stage of the project include:
- Team will waste precious time in understanding
the new requirement instead of focusing on existing tasks. Release timelines
might get impacted.
- It will lead to additional rework on the team.
Attempting to add the CR within the given time-frame could lead to stretching
the teams’ efforts to late nights. This would result in fatigue and low team
morale.
- The quality of the application will surely take
a beating.
All this will impact the PM and the teams credibility. It all boils down to the PM and his team on how firm they are in dealing with
CR’s.
Taking the above example of the calculator, let’s say the
client has come up with a change request. He/she wants a new button/function to
be added to the calculator. You as the PM get together with the team and
analyse the CR. On the surface, it seems to be a simple change. I mean, just
adding a new button should not be much of a change right? Maybe, but there
could be a lot of hidden factors involved. This small change might require some
big and complicated changes in the Database architecture, code etc. So, after a
fair amount of Brainstorming, you decide to add the CR. Your team says it’s a
piece of cake and won’t take much effort. You know this team is experienced and
have led this team before. So you agree to their decision. The CR gets incorporated
and fortunately, things work out as planned. The new functionality gets added
and the client is happy.
If the CR did require some serious amount of rework, the PM
would have taken the call to postpone the CR to the next patch request or to
add it to the current scope if the client was willing to accept the change in
the delivery timelines due to the CR.
As seen above, the waterfall model can also add change
requests pretty well. So why all the fuss over Agile? Well, in the above CR you
must consider the following factors:
a)
The CR was not a complicated one. The team was
experienced enough to handle it and the CR got integrated smoothly.
b)
This was a one off case and there were no
regular and frequent CR’s requested by the client.
But what if you were developing a complex application? Let’s
say for example, a web and mobile based social networking application (Similar to Facebook, Hi5 etc.). Such an
application is complex in scope and is subject to various change requests.
Would the waterfall model work well in such a case, or would it make sense
switching to Agile?
That’s what we are going to analyze in Part two of my Blog.
Thanks for taking the time and patience for reading part one.
Stay tuned for part two.
Regards,
Srinivas Pavan Addanki
