What is Agile?

The English definition of “agile” means to move quickly or at a rapid pace. In software development, the term “Agile” is used for iterative development. Iterative development entails breaking down the development from large chunks to smaller pieces. Agile, in software development, is a set of values and principles under which Agile requirements and Agile solutions are built through cross-functioning and self-organizing teams. It is a much-disciplined methodology which encourages flexibility and is also very fast-paced.

One example of a business using Agile is Spotify. Spotify has a lot of significant competitors, and Spotify is made up of many teams worldwide, meaning that they constantly have to be on top of their game to be better than the competition. Because they use Agile and specifically Scrum, which we will learn about later - they can continually develop and push out new software without disturbing other teams or waiting on documentation. They love the Agile method so much that management even employs separate Agile coaches to join the teams.

Two of the most widely used methodologies in Agile are Scrum and Kanban. We will discuss these a bit later. Firstly, let’s get stuck into the values and principles of Agile.

Values of Agile

Individual interactions over process and tools

Investing in team communication is vital for a project to be successful. Employees drive the processes and tools, and if they understand the need of the project and its scope, the processes and tools necessary to achieve the goals will fall into place due to the fast-paced nature of Agile. Communication and interaction with the team are critical to ensure the project’s success.

Working software over comprehensive documentation

As seen previously, there was a big emphasis on documentation during the SDLC process. The Agile process values working software more than documentation, which takes enormous time. However, Agile does not eliminate documentation. Instead of fully scoped specifications, Agile utilizes user stories that the developer will use to develop.

Customer collaboration over contract negotiation

With Agile, the customer is involved throughout the development process, which ensures that the customer’s needs are met and the requirement is as close to the customer’s needs as possible. With Agile, there may also be periodic system demos, especially if the project is big; this is mainly used for customer interaction to ensure that their requirements are being met.

Responding to change over following a plan

In the traditional SDLC, the development would only start after the specifications had been approved and signed off by all the stakeholders. The process would be repeated if any functionality changes were needed, wasting time and costs.

The 12 principles of Agile

The Agile software development manifesto is based on 12 principles of Agile, which are:

1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between businesspeople and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity - the art of maximizing the amount of work not done - is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective and adjusts accordingly

📄 DOCUMENTATION

Agile docs: The 12 Principles behind the Agile Manifesto.

Scrum

Scrum is a project management method used within the Agile framework and is one of the most widely used project method frameworks. Scrum is used when the scope of the project is not clearly defined and when there are many complexities.

Scrum roles

Like in the traditional project management methodology, Scrum also has a set of roles which are linked to responsibilities. The Scrum roles are as follows:

• Product owner – 1 person and usually a representative from the business
• Scrum master – 1 person who is the Scrum Coach and assists the team in reaching their goals
• Development team – usually between 3 – 9 people.

Product owner

The product owner is a representative from a business who is responsible for the product backlog. They usually prioritize the product backlog and will determine which user stories are of importance to the business. Product owners understand the business and can easily translate the requirement from the business to the development team.

Scrum master

The Scrum Master fully understands the Scrum process and tries to facilitate and help the development team understand the Scrum processes by training and coaching the team. The Scrum master also assists the product owner by constantly giving regular feedback on the development process.

The Scrum Master usually forms part of the development team. The Scrum master can also be part of more than one project.

Development team

The development team is responsible for the delivery of the product backlog. The development team manages their own time and is not driven by orders given. User stories which are assigned to the development team during the sprint planning are to be completed at the end of every sprint. All development team members are responsible for successfully delivering the user stories in the sprint, even though some of the user stories are assigned to only one person.

Now that we have a better understanding of the Scrum team let’s have a look at the different events in Scrum in more detail.

Sprint

One development cycle in Scrum is called a “sprint”. Projects are delivered incrementally in Scrum, and these are referred to as sprints. Unlike the traditional software development life cycle, where a project is delivered as a whole, Scrum uses iterations to deliver sprints. The project is broken down into smaller, manageable pieces. A sprint can range between 2 to 4 weeks. The sprint is the container for the four other Scrum events.

Sprint planning

Sprint planning is usually conducted in a time-contained meeting. During this meeting, the product backlog is discussed and assigned to the development team. The development team will then decide on the user stories to be delivered to the sprint, and the time it will take to deliver these.

Each product backlog is noted on sticky paper and pasted to the board. During the sprint planning meeting, these sticky notes are broken down further into detailed tasks, which are then assigned to the development team.

Daily Scrum or stand up

Each person in the developments has a few minutes to speak about three things.

• What they have done on the previous day
• What they are going to do today
• If they are facing any blockers (Something blocking you from completing your task).

In case you needed a visualization of Scrum, here’s NASA in the 1970s during a daily stand-up:

Sprint review

At the end of each sprint, the Scrum team meets with the stakeholders to discuss the product backlog items completed during the sprint and marked as “done”.

Sprint Retrospective

Before a new sprint begins, the Scrum team has a meeting to discuss and give feedback on the sprint they have just completed. In this meeting, the process of the sprint and any lessons learnt during the sprint is discussed.

Activity

💻 WATCH

Video: Scrum: The Basics (1h)

---

Lesson Task

Brief

In this task, you will be required to demonstrate your understanding of Scrum through its roles and events and how they relate to one another.

Level 1 Process

1. List the Scrum roles and briefly discuss each in your own words.
2. Draw a flow diagram illustrating the Scrum events.

Level 2 Process

1. Discuss each Scrum event in detail and list all the Scrum roles which are involved and/or responsible for each Scrum event.