A Basic Idea on Agile Software Development


The “What Is” Factor

Planning always starts with You!

Out of the many basic models available to develop software, Agile is considered as one of the most pragmatic development approach. This model involves breaking down the entire product into small bits and progressing with them in iterations (not the Iterative model).


We Know Waterfall

The most archaic and commonly used model in SDLC, this methodology has never lost its limelight. It is a very easy-to-manage-and-understand kind of a structure, that follows a very simple mantra –

Wrap up one and move on!!!

Based on the information and lessons gathered from its previous phase of development, the entire project plan is sequentially laid down.

Then The “Why” Comes

Even though Waterfall can help wrap up a project easily, need of flexibility and “ongoing project” factor can act as a needle to the balloon. Once a phase of development is completed, there is no room for revise-and-fix until the Maintenance stage of the workflow. Then come the challenges of timelines, extended work hours and defects, which ultimately articulates as –

We cannot move forward for Go-Live…

With Agile methodology, a lot of these can be curtailed. This model accentuates interaction among the customers, analysts, developers and testers, and speeds up the process of problem solving. Need of exhaustive documents is diminished, leaving time for in-depth analysis and the verification of code becomes possible at each stage of development. The entire design being broken down into pieces, the team defines –

  • “What to be developed” in each iteration
  • How much time is needed to code a piece
  • Review of code
  • Testing the developed piece
  • Running through integrated test scenarios and scripts

and delivers what was asked-for.

Since the users are able to verify the working code post iteration completion, the evolutions (if identified) are easily implemented with the upcoming iterations. This helps tune the requirements at a stage when they are easily modifiable.

The Types

Extreme Programming a.k.a. XP

To understand this method of development, think of a kid building the blocks.


Day 1: The kid sees the picture of a castle, so he knows what he wants and by when. So he gathers the set of blocks that he needs. He builds the top of the castle first and keeps it aside. Then he starts building the body, while doing which he keeps on changing what he’s building every time, as it’s not meeting his desire.

Day 2: He finished building the body and now starts working on the base. After completing the base, he’s now ready to attach the three parts. Before doing so, he revisits the top part of the castle and finds a color mismatch in them, so he decides to change it.

Day 3: He attaches all the parts of the blocks and is ready with his castle. He matches it against the picture he’d seen and is happy with the results.

The above is very novice layout of how this process works. Below is a formal illustration –


The user stories are mainly written or at least reviewed by the customer. Based on these stories the functional and technical designs are created. The coding of one story will involve at least 2 developers and post development of the story the same gets tested by the user, owing to which, the end product is an assured success. An important term that is used and tracked in this methodology is Velocity. This mainly derives the number of stories completed every iteration, thereby driving the project schedule and release plans.


  • The stories for coding come directly from the end-users’ perspective.
  • Developers are provided the time needed for the coding of any particular piece.
  • Allocation of items to resources is done based on the individual’s knowledge.
  • Review of code is done by a different developer than the one coded.
  • Testing of the coded piece is done by users prior to release.
  • Resultant design is achieved faster and successfully.
  • Parallel development becomes a possible chance, with proper merge of code on completion.


  • One piece of code may be touched by more than one developer.
  • If code review is not done properly, next iteration’s development on the same piece may get impacted.
  • The end-users are expected to be involved throughout.
  • A piece of code being worked upon by multiple developers need to be properly integrated and coordinated with, in order to avoid overwriting.
  • Allocation of items may not always be sequential; one resource may get assigned a story that can be developed after another resource’s completion.


You are told what you have to do and by when, in the beginning itself – you don’t know anything else!


The captain of the team lays out the plan –

“Bob to John; John to Tim; Tim to Marty; Marty scores. Pass on the ball within 25 seconds and the rest of us will take care of the obstacles. GO!!!”


Product backlog is a consolidated list of requirements, which are not planned for any development yet. This includes all the enhancements, defects and cosmetic changes as well. The Scrum Master is a person responsible for the entire cycle of the model, starting from allocating time and resources to backlogs till the code merge and release.

The entire process in this methodology is tracked by the use of a Burndown Chart. This mainly derives the number of backlogs completed in every sprint, thereby driving the project progress and further sprint plans.


  • In each sprint, the team identifies the changes needed for any implementation.
  • Developers are always documenting their code along with any clarification and/or learning gathered during the development.
  • The allocation of items, since done by one person (Scrum Master), is always taken up proceduraly (what needs to be developed first).


  • Assigning backlogs is not done based on a developer’s technical strengths. This may lead to delay in completion.
  • Time allocated against each backlog is based on the technical difficulty rather than developer requirement.
  • Since only one person is the owner of the entire process until the end, it may become an overload for the individual.

What Will Suite Us?

The unceasing communication between teams and rapid development of small bits of the entire product is the main tune of the Agile methodology. For an efficacious project, the vision till the testing process should be clear from the beginning.

Being the enterprise-wide GRC solutions provider and having delighted some of the world’s market giants with their team work, MetricStream can definitely think of Agile as a winning alternative to Waterfall. Having the teams sitting together already, it will be a piece-of-cake factor to make everyone work with proper coordination and beat the complexity of multiple resources working on one piece by introducing Object (form) locking.


With the combination of XP and Scrum, Agile can make the project more control and direction oriented. This method, apart from making everyone work together throughout, also gives them a huge exposure different learnings as well as client interaction. Meetings like –

  • Design Review: where the proposed design is reviewed by the users and approval is taken.
  • Daily Stand Up/Scrum: where the daily progress, roadblocks (if any) and updates are discussed.
  • Planning: where the planning for the upcoming iteration or sprint is decided along with resources’ leave plans.
  • Retrospective: where the team talks about the positives, negatives and improvements (if needed) from the past iteration/sprint.
  • Demo: where the developed piece is demoed to the business to take feedback and sign-offs.

will always make sure, to keep the project on track.

Then again, we always have to keep buffer for unexpected things; like Monday sick-leaves!