What is agile software development?
The term was coined when a group of developers were in the process of creating some software – they began to observe development teams within other companies and noticed that some of their processes made completing work much easier. Eventually, they compiled all of their observations into a document known as the Agile Manifesto.
What does agile development involve?
Basically, the Agile Manifesto outlined what the industry should be valuing instead of the things that its employees currently value. This includes:
- Individuals and interactions instead of processes and tools.
- Working software instead of comprehensive documentation.
- Customer collaboration instead of contract negotiation.
- Responding to change instead of following a plan.
The afore mentioned developers found that valuing each of the factors on the left-hand side made for a much better and smoother process.
To ensure that you are practising agile software development within your own company, there are twelve theories and techniques that you should ensure you and your employees are following. Delving into each of these theories and techniques, however, is another story altogether – and one we will eventually get to.
Scrum has been used by many big companies like Microsoft, Yahoo, Google, IBM etc. and for various purposes including commercial software, in-house development, contract development and even non-software projects The Scrum methodology involves self-organizing teams and a series of typically two-week timespans known as “sprints”. The items to be completed are listed in the “Product Backlog”.
Implementation of Agile (Scrum) Software Development Methodology
The implementation process of Scrum’s methodology can easily be explained with the help of the Scrum Framework. The framework is divided into three parts: Roles, Ceremonies and Artefacts.
Three defined roles are a part of the Scrum methodology. These are:
The features of the product are defined by the Product Owner. The Product Owner makes the decisions on scope and schedule and achieving financial goals of the project is the responsibility of the Product Owner. The product backlog is prioritised by the Product Owner, based on the business needs the Product Owner adjusts features and priorities every sprint, and the work results at the end of each sprint are accepted or rejected by him.
The Scrum Master
The Scrum Master owns the process and can make adjustments to it. He/she also facilitates ceremonies. This does not make a Scrum Master a technical lead or manager. They are also responsible for scrum values and practices and to help removes impediments, improve the team’s productivity, enable close cooperation across all roles and functions and shields the team from external interference.
The team typically consists of five to nine people. Consisting of programmers, testers, and business analysists. The teams are self-organizing and the membership should only change between sprints.
Ceremonies are the processes involved in the implementation of the Agile (Scrum) software development methodology and include the following:
The sprint planning meeting consists of the team, the Scrum master and the Product Owner. In the meeting, the product backlog items are discussed so that they can be prioritised and then the team selects which ones to do. The sprint planning meeting determines what will be worked on and it also helps to develop a considerable understanding of what needs to done in order to carry it out. One notable thing done in sprint planning is that tasks are measured in time (whereas before it was done in story points).
The daily Scrum meeting is held daily for about 15 minutes. This is not a problem-solving meeting. The daily Scrum helps avoid unnecessary meetings. In the daily Scrum everyone answers three questions, the questions are:
- What did you do yesterday?
- What will you do today?
- Is anything in your way?
The Sprint Review
In the sprint review (or review & demo) the team presents what has been accomplished during the sprint. It is a demonstration of new features or the existing architecture. It is an informal presentation and the entire team participates in it.
It involves looking at what is working and what is not. The time period for the sprint retrospective is around thirty minutes and is done after every sprint. It involves the participation of the Product Owner, Scrum master, the team and even the customers. In the retrospective, the whole team gathers to discuss what they want to start, continue or stop doing.
The artefacts can be called the tools of the Scrum methodology and include the following:
The product backlog captures the requirements listed as items or work on the project. Each item is expressed in a way which provides value to the customer, prioritised by the product owner and reprioritized at the start of each sprint.
The sprint goal is a short statement about the focus of the work during the sprint. Sprint backlog determines the work for the sprint, is updated every day and each item has its own status. In the sprint, backlog work is never assigned but individuals choose their own work; the remaining work is estimated daily, and any member can add, change or delete the sprint backlog.
Sprint Burndown chart
The sprint burndown chart shows the total sprint backlog hours remaining each day and also the estimated amount of time to release. The sprint burndown chart should ideally come down to zero at the end of the sprint. The X-axis of the chart shows the time left in this sprint and the Y-axis shows the hour’s estimate remaining.
Benefits of Scrum
- Scrum methodology eliminates the need for comprehensive documentation
- Mistakes can easily be rectified
- Clear visibility of the project development progress
- Iterative in nature and requires customer feedback
- Short sprints and constant feedback makes coping with changes easier
- Individual productivity improves as a result of daily meetings
- Issues are identified in advance and hence can be resolved rapidly
Pitfalls of Scrum
- Tasks can be spread over several sprints if it is not well defined.
- Success and Failure of the projects depends on the commitment of the team members
- Heavily relies on a dedicated product owner. The lack of it cascades down and hinders the quality of the backlog… which makes an impact on pretty much the entire process
- Works well only with small teams
- Needs relatively experienced members
- Works well for project management only when the Scrum masters trusts the team.
- The product owner defines the scope of the sprint based on the time estimates set at the sprint planning and team’s capacity for the next sprint. This scope needs to be clearly communicated to the team since completing these tickets will be a commitment for the sprint
- A daily Scrum meeting is held in order to synchronise the activities while the team works through the sprint backlog tasks
- One or more times during the sprint, backlog grooming sessions are held to present and discuss upcoming user stories for the next sprints. The output may be an estimation of a story in story points, or if the team needs more clarifications, questions that the product owner needs to research. A sprint review is conducted at the end of the sprint cycle and the finalised product is released
- Performance and improvements based on the previous sprint cycle are discussed before starting with a new sprint, this is called a sprint retrospective
- The sprint cycle continues