Agile Software Development Process

Agile Software Development follows a completely different approach to software development as compared to the traditional software development methods. It primarily focuses on continuous ‘feedback and change’ to make the software development process lightweight and prompt. It promotes quick response to the changes in requirements and project deadlines.

Agile Practices

Daily Standup

One of the most common agile practices is the daily standup. Daily Standup is a meeting where all the team members are gathered and speak about their progress of work. They put up their challenges what they are facing and discuss within the team to get a solution. This meeting is very short and all the team members are made to stand up for that short duration of time. This is the first step followed to go agile.

Retrospective

Retrospective is a meeting in which the team members discuss about the previous Sprint that has already been implemented. They talk about how went what, realize if they have done any mistakes. In this meeting they also discuss how the previous mistakes can be avoided, which will save time and increase efficiency.

User Story

In software development, a User Story is a way of describing a certain requirement from a user’s perspective. User Story uses a specific template of writing and is either written on a piece of paper or in different tools used by organizations. The template of a User Story is “AS A <user> I WANT TO <action to be taken> SO THAT <a user can perform a particular action>”.

Example: AS A registered user I WANT login to the XYZ application SO THAT I can use all features of the application.

A User Story is always incomplete without an ‘Acceptance Criteria’. To verify a User Story an Acceptance Criteria is defined that follows a certain template as “Verify that <condition that validates the user story>”.

Burn down Chart

In agile, Burn Down chart is a graphical representation of the work completed in a sprint and the remaining work that needs to be completed in a particular time frame. This chart also predicts in how much time the remaining work will be completed.

Refactoring

Refactoring is the process of dividing and structuring the existing code without changing its behavior. In Agile, multiple iterations occur during the project execution and each time a new code is added or the existing code is changed or updated. It becomes really challenging for the developers to maintain the code and work efficiently. So refactoring allows the developers to preserve the source code’s external behavior while providing the safeguards to the code and avoiding bugs to occur.

Above are the few practices that are followed in Agile Software Development. By using these practices, the most complex projects become easy to implement without any hassle. These practices allow the teams to collaborate with each other, discuss the problems and find solutions, get clear understanding of the project progress and finally implement the project successfully.

Agile Methodologies

Agile is a set of methodologies that are relatively straightforward to implement and enhanced to resolve certain problems of the software teams. These methodologies talk about all the areas of traditional software engineering and contain the practices that make them as easy to use as possible.

There is a long list of methodologies that are used by Agile Software Development teams, which include:

• SCRUM
• Extreme Programming
• Kanban
• Lean Software Development
• Crystal
• Feature Driven Development
• Dynamic System Development Method

The most commonly used Agile methodologies are SCRUM and Extreme Programming. In this tutorial, we will elaborate on these two methodologies.

SCRUM

It is been found that most common methodology to agile is SCRUM that is completely focused on Project Management and Software Development. In SCRUM methodology, the software development follows a certain pattern and majorly it consists of the three roles that include:

• Product Owner

The product owner is the primary point of contact who liaises between the stakeholders and the teams. He works with the technology teams to maintain and prioritize product backlog.

Key responsibilities of a Product Owner

• Create the product roadmap, a high level synopsis defining the vision and guidelines for the project.
  • Coordinate with the multiple stakeholders to state the clear business objectives.
  • Create, prioritize and maintain the product backlog.
  • Identify and arrange the steps to be taken during each sprint and evaluating product progress at the end of each sprint.
  • Understand the customers’ expectations, anticipate possible issues and address those issues.
  • Maximize the product/software value developed by the technology teams.

• SCRUM Master

The scrum master is responsible for managing the SCRUM. SCRUM master helps technology teams to resolve any issues they face and pass through the roadblocks.

Key responsibilities of a Scrum Master

• Makes sure that the project objective and scope is clearly understood by the SCRUM team.
  • Coordinates with the product owner to help him organize and maintain the product backlog with maximum efficiency.
  • Helps the technology teams to understand the User Stories clearly and create tasks from those.
  • Helps the technology teams to organize the tasks and progress towards the sprint completion.
  • Removes any roadblocks that the technology teams face during the implementation.
  • Organizes Daily SCRUM to collaborate with the team and listen to their concerns.

• Technology Teams

Technology teams are responsible for developing and implementing each Sprint successfully.

Key responsibilities of an Agile Technology Team

• Creates tasks with the help of User Stories and manages those throughout the Sprint.
  • Reports and updates the status of each task and the progress of the work.
  • Attends Daily SCRUM scheduled by the SCRUM master and collaborate with the team members.
  • Attends meetings, planning sessions arranged by the analysts and product owner.

In SCRUM Software Development methodology, the project is divided into Sprints. A Sprint is a backbone of Agile SCRUM Software Development. A Sprint is a small iteration and an increment of a continuous software development cycle. An increment is a collection of all product backlog items completed in one Sprint. A Sprint is basically of 2 to 4 weeks duration depending on the organization.

One Sprint gets over and the next Sprint starts. At the end of each Sprint, the increment is tested that explains the project future progress. If the increment is built as per the stated requirements, it progresses with small changes based on the stakeholders’ feedback. If the increment does not satisfy the stated requirements, the root cause is determined and the changes are made before the next Sprint starts.

Daily inspection occurs during each Sprint where the status is updated and progress is reported. This cycle continues to repeat until the project is completed and no funding is required for the project.

• Sprint Planning

Before starting any Sprint, a planning is done that is called Sprint Planning. To plan a Sprint, a Sprint planning meeting is scheduled with technology teams. This is the kick-off of the Sprint in which the technology teams plan their tasks with the help of SCRUM Master to achieve the successful Sprint completion.

At the beginning of a Sprint, the technology teams review what must be done in the Sprint? Then it is planned how the increment can be turned into a potentially transferable functionality at the end of the Sprint.  Once the planning is done, the team presents the implemented functionality to the stakeholders.

• Sprint Backlog

Sprint Backlog is a list product backlog items (User Stories) in a Sprint. In Sprint Backlog, the tasks are created by the technology team from the product backlog items such as User Stories for each Sprint. The technology team picks up the User Stories from the product backlog, creates multiple tasks and prioritizes them to complete a Sprint. Each User Story represents multiple tasks in Sprint Backlog and completion of these tasks by the technology team completes a User Story. Sprint Backlog provides transparency to the work which needs to be completed by the technology teams to satisfy the objective of each Sprint.

• Daily SCRUM

Daily SCRUM is a meeting or an event for the technology teams to plan for the activities and synchronize over them for the next 24 hours. Daily SCRUM is a time bound event and held every day for 15 minutes. The technology teams discuss the progress of the activities in the Sprint Backlog and scrutinize the work progress trend towards the Sprint completion.

• Sprint Review

After each Sprint completion, Sprint review is required to deliver a transferable product increment. To review the Sprint a Sprint Review meeting is held and the developed functionality is discussed with the technology teams.  

• Retrospective

At the end of each Sprint, a Sprint Retrospective meeting is held. The Sprint Retrospective is only attended by the Scrum Master and the technology teams. The Retrospective solely focuses on the Sprint; how well it went and the areas of improvement in the upcoming Sprints.

• Extreme Programming (XP)

Extreme Programming is a lightweight Agile Methodology that is designed for smaller projects and a team of two to ten programmers. It consists of the short cycles of software development that allow progressive design process. XP strongly emphasizes on oral communication. Monitoring the software development progress through the automated tests allows the system to determine inconsistencies at a very early stage.

XP offers a flexible approach for the implementation of the software/system’s functionality and adopts continuously changing business requirements. In XP there are reduced project risks and improved productivity throughout the software development.

In XP, the risks addressed at all levels of the software development need to be communicated to the customers, managers and the programmers. XP’s primary focus is on the priority features of the software/system and the quality of the software/system to be developed.

In the last few years, XP came into picture due to its advantages over other methodologies, which include:

• Adaptation of dynamically changing software requirements
• Elimination of the risks caused by the fixed duration projects
• Application of automated unit and functional tests

XP involves the iterations of one to four weeks. In each iteration, one to three days tasks are planned.

Values of XP

• Communication

Communication plays an important role in the success of a project. XP strongly emphasizes on oral communication. The customers, managers and team members must have continuous communication among themselves. Extreme programming keeps a track of the employees/people who do not collaborate with the team members and provide continuous updates to the customers. So, in Extreme Programming, team members, managers and customers communicate on a regular basis and work together to create the best solution.

There are some common issues that can be resolved by communicating effectively, which include:

• Misinterpretation of the problem or requirements due to lack of communication.
  • Ignorance of important requirements communicated by the customer.
  • Lack of reporting about the issues that arise during the implementation.
  • Miss on asking required questions by the developers from the customer.
  • Communication gap between the developers and the manager.
  • No proper communication among the team members.

• Simplicity

Extreme Programming focuses on the simple to do things. It begins with the simplest solution and keeps on adding more functionality with the time if needed. Extreme Programming follows a completely different approach as compared to the other software development methodologies. It believes in designing and developing the solution that is needed today and does not focus on future requirements. It does not promote working on some uncertain future requirements to create a solution that may or may not be useful in future.

• Feedback

Extreme Programming defines feedback at different levels as a necessary step. The completed software/system build is delivered to the customer and the feedback is recorded each time. In Extreme Programming, the feedback is documented at different levels that include:

• Customer Feedback

The customer and the testers work together to create the acceptance tests to test the software/system’s functionality thoroughly. Constant and continuous feedback is provided to the customer about the present state of the software/system.

• System Feedback

The developers get the direct feedback from the software/system’s state by writing and implementing the unit and integration tests.

• Team Feedback

When the customer comes up with the new requirements or change in requirements, the technology team calculates and provides estimation to the customer for the features to be developed.

• Courage

One of the biggest examples of courage is to the point development. Courage offers various advantages to the technology teams, which include:

• Provides comfort to the technology teams with refactoring their code.
  • Allows technology teams to throw away the old and obsolete source code without any fear.
  • Develop the functionality only for today not for tomorrow.

• Respect

In Extreme Programming, each and everyone respect others. Developers never create any problems for their team members or the testers that delays their work. Technology teams always respect the ideas from the customers and customer also gives the equal importance to the technology team’s opinions.

Extreme Programming Principles

The basic principles of Extreme Programming include:

• Rapid Feedback – During the design, development and testing of the software/system the feedback must be quick.
• Assume Simplicity – Any simple or a complex problem must be resolved in the simplest way possible.
• Incremental Change – Any problem must be resolved using the step by step incremental cycles of change.
• Embracing Change – Any dramatic change in the requirements must be accepted by the technology teams.
• Quality Work – At the end, a good quality software/system is expected and that’s possible when everyone is happy and enjoys working.

Extreme Programming practices, activities and the lifecycle will be explained in detail in the upcoming articles.