Agile Methodology and Scrum

Here, I’ve tried to explain the basic concepts of Agile Methodology and Scrum, and a few common hurdles that we face while adopting Agile.

Today, a large portion of the IT industry is involved in following the Agile methodology. Well, today it's an accepted fact that agile has gained more acceptance in comparison to the traditional methods. This is because it provides flexibility to break down the projects and corresponding tasks into several small processes or iterations. In this, Agile Project Management plays an important key role, by providing a style that mainly focuses on:

1. Early delivery of business value.
2. Continues improvement of the project and involved processes.
3. High scope for flexibility.
4.Team input
5. Delivering well-tested products that reflect customer/stakeholder’s need.

But before adopting the Agile methodology, one must be clear about, how does it work or to quote it correctly, how agile projects work?

To understand this, one must understand, Agile approaches are based on an empirical control method — a process of making decisions based on the
realities observed in the project.

In the context of software development methodologies, an empirical approach can be effective in both new product development and enhancement and upgrade projects.
By using frequent and firsthand inspection of the work to date, you can make immediate adjustments, if necessary.

As per the Standish Group study, “Software project success and failure” found that while 29% of traditional projects failed outright, that number dropped to only 9% on agile projects. The decrease in failure for Agile projects is a result of agile project teams making immediate adaptions based on frequent inspections of progress and customer satisfaction.

Agile methodology has been adopted by multiple organizations, but its success rate depends on which level have the organization and people have accepted it. It is important to understand that for Agile to be successful, having the right mindset, is equally important than merely implementing Agile tools, practices, or principles. An Agile mindset is — be Agile and do agile i.e. an organization or a person has absorbed Agile to an extent that it becomes a part of their identity. For example, having a visual board does not necessarily mean that a team is agile. Also, when a team may understand what to do, but don’t understand why they are doing it. This will result in partial success.

There are various frameworks that follow agile methodology. Scrum is one of the most popular among them.

Scrum

Scrum is the most common approach to agile for good reasons as the rules of scrum is very much straight forward and easy to learn, and teams all around the world have been able to adopt them and improve their ability to deliver the projects.
A scrum team broadly consist of the following roles:

Product Owner:

1. Hold the vision for the product and controls the budget.
2. Works to maximize the value delivered by the team.
3. Clearly expresses what’s to be done, make the product backlogs visible and transparent to all.
4. Sets the priorities for the team in terms of which product backlog item to work on next.
5. Should be a single person, not a committee.

Development Team:

1. Self-organizing — The team decides how to deliver.
2. Cross-functional — Have all the skills on the team necessary to do the job.
3. Individuals may have specialist skills but are accountable as a team for delivery.
4. Scrum only recognizes the title “Developer” within the team i.e. irrespective of the job role each and every team member will be entitled as a developer and will have the same priority.
5. Scrum doesn’t ask for or recognize sub-teams within the team.

Scrum Master:

1. Coaches the team in the use of Scrum
2. Coaches the organization how to get the best value from its interactions with the team.
3. Facilitates events as requested or needed (Daily Scrum, Sprints, Planning).
4. Removes impediments to the team’s progress.
5. Acts as a servant leader to the team.

Sprints:

Sprints consist of the application development lifecycles that can last from 1 week to 4 weeks. It is believed that at the end of a sprint, the team must be able to deliver at least one feature/requirement to the stakeholder. This could be the working functionality or document or maybe a progress report depending on the nature of the task undertaken during the sprint.

SCRUM Framework (image credits: google.com)

The duration of the sprint should be fixed during product development, and team members themselves must decide this.

At the beginning of the sprints, the Scrum master decides the objective of the sprints. Later on, based on the objective of the sprint, for an ongoing product, the team picks up the stories either backlog or if the product is in an initial phase, selects it based on requirement after discussion with Scrum Master. These stories will be assigned story points that depict the duration that this particular story will take to get completed.

Sometimes it is difficult to stick back to the stories and story point estimations. For example, in the ongoing sprint, if some urgent work has shown up, there is a need to add more stories in the current running sprint. This will result in exceeding the capacity of the team given that now we have all the initial stories and new stories on the board but the duration is limit. In such situation, it is good to work on the higher priority stories and move the lesser one in the backlog list, maintaining the balance between overall story points and remaining time for the Sprint.

Another problem that is faced commonly in the teams is underestimating the stories that can be completed in the given sprint and taking up other stories to fulfill or attain the total story points to complete the sprint. This may result in partially completed sprint by the end of sprint. For such situations, it is important to estimate the stories precisely, and take a small buffer or margin for non calculated actions.

Useful terms related to the Scrum:

Stories/User Stories:

These are the requirements written from the perspective of the end-user. This is mainly the description of one or more features of a software system that needs to be developed.

Epics:

Epics are the body of work that can be broken down into multiple stories(or tasks). Stories are achievable in nature and act as a fundamental block of the development process whereas epics help to provide a bigger picture of the goals. Multiple sprints can be a part of a single epic and the epic will not be considered as complete or done if all the stories are not completed.

Initiatives:

Initiatives consist of the group of Epics and broadly they define the common goal of the product.

Backlogs:

This list is visible to each and every member of the team and contains the tasks which are yet to be taken into the sprint.
For an ongoing product, a list of backlogs exists based on the functionality.
It is the task of the product owner to prioritize which story has to be taken in the next sprint and communicate it with the scrum master and team.

Daily Stand-ups/ Daily Scrums:

Daily standups are important for checking the progress of the product and helps in creating transparency within the team.
The scrum master conducts this, and all the team members act as precipitants.

There are few rules associated with the daily stand-ups:

1. The timings of the meeting should be fixed and its duration should not exceed 15 minutes.
2. Mainly there are 3 areas that need to be covered:
   a. Individual’s accomplishments since the last meeting.
   b. Next plan of action on the list for individuals.
   c. Any blockage or difficulty faced.
3. This is an internal part of the team which allows every member of the team to stay aware of the current status. There is no need for status updates to the product owner or stakeholders.

Since daily standups have time restrictions, there is quite a large possibility, that requires long and deep discussions, involving few team members, they can take the discussion to another meeting in-continuity with the same daily standup meeting but with only the individuals needed for the discussion. Such discussions are held under the Parking lot.

Parking lot:

These are followed by daily standups. It is not necessary to have these meetings on daily basis. The main objective of the parking lot is to continue the necessary discussions with a specific person after the standup. This helps in managing the daily standup time constraint and also saves the team’s time by involving only the specific person in the meetings.

Sprint Review:

The sprint review is carried by the Scrum Team and also involves the Product owner and stakeholders. This meeting is conducted at the end of every sprint to get a clear picture of what we have at the end of the sprint? The duration of this meeting may vary depending on the features taken in the current and next sprint. It involves the participation of each and every member of the Team.

The main objective of this meeting is to get feedback on the current work resolve conflicts (if any), discuss blocking areas (if any) and other areas of concern. The next action/ feature that has to be taken by the Team, is also decided in this meeting.

Sprint Retrospection:

This is one of the major key aspects of Agile and is missed by many organizations. Sprint Retrospection is a meeting that is conducted by the Scrum Master, to check and verify the smooth functioning of the Agile. Many organizations adopt Agile just for the sake of adopting but they don’t use it completely. Sprint Retrospection helps in improving the work environment within the team, identify the mistakes in the process and decide a plan of action to remove such obstacles. This is a team activity that ultimately focuses on removing the glitches from the process to provide smooth functioning.

Concluding with, Agile methodology is a process which once adopted in a correct manner will help in increasing the productivity and better management for the team, as it allows everyone to take responsibility for their actions and work as a team to achieve a goal.