All You Need To Know About Agile

Reading Time: 8 minutes

What is Agile?

As per dictionary, Agile means “living, responsive” but we translate it more often as “flexible.” In the software development industry, this term appeared in the early 2000s, when the “Manifesto of Flexible Software Development” was published in Utah. Since then, “agile” is understood as a set of approaches for “flexible” software development.

The essence of the agile approach is stated in the “manifesto”, but for the customer it can be briefly formulated as follows:

• Development is carried out in short cycles (iterations), lasting 1-4 weeks;
• At the end of each iteration, the customer receives a valuable application (or part of it) that can be used in business.
• The development team cooperates with the customer throughout the project;
• Changes in the project are welcomed and quickly included in the work.
• Currently, agile-principles are used in the work of tens of thousands of teams around the world.

What is Scrum?

Scrum is one of several methodologies for agile software development:

• Scrum
• Lean
• Feature Driving Development
• Extreme Programming

Artifacts in Scrum

In the Scrum, only four artifacts are used:

• Sprint Breakdown chart
• Product Backlog
• Sprint Backlog
• Sprint Goal

Product backlog:

This is a list of all the requirements that need to be done on the project. When there are no requirements in Backlog, the project is considered complete.

• All requirements are described by a single template, which is called the User Story.
• The requirements are formulated in such a way that it is obvious and understandable how valuable they are to the user.
• Requirements are sorted by priorities, which are revised with each sprint.

Sprint backlog:

This is a list of all the requirements that need to be done in the nearest sprint.

• During the sprint, new requirements cannot appear in the Sprint backlog.
• All requirements should be divided into tasks and evaluated.
• Sprint Backlog is the team’s commitment: what they need to accomplish in the next 2 weeks.
• Each requirement is divided into tasks that are presented on the Kanban board.

Sprint Goal

The goal for the sprint helps the team make informed decisions. This artifact is necessary so that the project team can independently make a decision in the event of the appearance of alternative ways of solving the problem. To ensure that the team’s decisions are realized, the Product Owner determines the purpose of the sprint.

Sprint Burndown Chart

• Literally called “combustion diagram”
• The “burning” elements are man-hours or ideal units (Story Points).
• The diagram is updated every time when a task is completed.
• In practice, such a diagram is very clear: every day you can quickly find out how much the team has moved forward.

Roles in Scrum

Only three roles are used in the scrum:

• Product Owner
• Scrum Master
• Team.

Role of the Product Owner

• Formulates requirements
• Prioritizes requirements
• Adjust priorities at each sprint
• Is personally responsible for the value of requirements for the market / users
• Responsible for interaction with the market
• One man army

Product Owner is a representative of the division that owns the product being developed. For example, in a bank, this could be the Department of Card Products. It is not easy to define Product Owner correctly. This role requires a combination of the following qualities:

• Have personal involvement in the project and its results;
• Have a good command of writing requirements.
• In some cases, it is permissible to assign more than one person to the role of Product Owner.

Role of Scrum Master

• Monitors the correct application of Agile principles and processes
• Organizes the work of the team and provides it with everything necessary
• Protects the team, is responsible for its effectiveness
• One man army.

It’s a very difficult role. In the classical project management there is a Project Manager. In Scrum such a role is not provided. The best synonym for the role of Scrum Master will be the “administrator”. Scrum Master organizes the work of the project team, but does not interfere with its work.

• Scrum master does not assign tasks to people – this is done by the team itself;
• The master does not force people to do work – this is the responsibility of the team;
• The wizard does not ask the Product Owner what requirements should be written – it is the job of the owner of the product.

However, if there are violations in processes (someone from the team is late for a daily-meeting), then the master must intervene and correct the situation.

The responsibilities of Scrum Master are much broader, but to explain them all we need a separate article. Write in the comments if you need one.

Team (project team)

• Cross-functional
• Interchangeable
• Self-organizing
• With a fixed composition (during the sprint)
• 4-10 people.

The team is responsible for developing the product by iterations (sprints). The team determines by itself:

• Duration of the sprint
• Command capacity
• The size of its focus factor (Coefficient of Coherence)
• The complexity of the requirements that will be implemented in the sprint.
• The sequence of tasks and much more.
• The team makes no decisions.
• The priority of the requirements is determined by the product owner.

Rituals (processes in Scrum)

In Scrum, there are several processes that are commonly called rituals. Each ritual is carried out rigorously and in strict accordance with the approach. In practice, such processes tend to adapt a little, but the key principles do not change.

Rituals in the Scrum are:

• Sprint Planning Meeting
• The Daily Meeting
• Sprint Review
• Retrospective

Sprint Planning Meeting (Sprint Planning Meeting)

• Run by the whole team before the start of the sprint.
• The team selects requirements from the Product Backlog and forms Sprint Backlog.
• If it is necessary to take into account the interrelationships between operations, this is done here
  The command decomposes the requirements into tasks (tasks).
• Each task is evaluated in terms of labor or universal units
• During the meeting, the Product Owner answers the team’s questions.
• The meeting, which takes place before the start of each sprint.

The structure of the meeting is:

• Presentation and explanation of the Product Owner’s list of requirements
• Questions from the team
• Decomposition of requirements into tasks (tasks)
• Evaluation of tasks using the Planning Poker method.

The meeting is simple in nature, but extremely difficult in content. In the beginning of the project it can take 5-6 hours. And only after 3-4 sprints the meeting becomes more operative and lasts 2-3 hours. Be strong.

The Daily Meeting:

From the title it is clear that the meeting is held daily. Basic principles are:

• Runs daily and only at the same time;
• The meeting is only standing;
• Therefore the duration of the meeting is no more than 15 minutes;
• Everyone has to answer just 3 questions: what did I do yesterday, what am I doing today, what are the problems?
• Scrum Master monitors the course of the meeting, encourages participants to speak out completely and listen to the speaker.

At a daily meeting, the team exchanges experience. It also becomes clear who will work on what tasks. It is important that the team does this ritual on their own. I generally recommend that the Scrum Masters not interfere with the course of the meeting as long as all the requirements for this ritual are met.

The meeting of the team is effective to hold across the board Kanban, which reflects all the tasks of the sprint.

Sprint Review – Sprint Delivery To Product Owner

At the end of each sprint team must demonstrate the result. I will explain the value of this ritual separately.

The value of Scrum for a typical customer is largely that the result of the work (good or bad, not important) will be demonstrated in any case. This is known to both the team and the Product Owner and other interested parties. If the team does not conduct a demonstration (otherwise called Sprint Review), then it discredits all the benefits of agile processes.

The structure of the meeting:

• The command reads the requirements from Sprint Backlog
• For each acceptance criterion, a demonstration of the results is obtained
• Each question on the part of the Product Owner is recorded in order to be able to answer them later.
• Each new Product Owner requirement is issued to later include it in the Product Backlog.

Any employees of the organization or simply interested persons can attend the meeting. It is important that only participants in the Scrum process (Product Owner, Team, Scrum Master) have the right to vote.

Retrospective

Ritual, which is aimed at sharing experiences within the team. The meeting is held after the Sprint Review. At the meeting there is the whole team and Scrum Master. The meeting may be attended by Product Owner, if necessary.

The methodology of the meeting varies depending on the project, its team and just the traditions in the team. Nevertheless, answers to the following questions should be voiced:

• What decisions should the team take to make the process more predictable?
• What problems prevent the team from fulfilling its obligations?
• How to improve interaction with Product Owner?
• What mistakes the team makes and why?

Solutions must be written on a separate board. After a general vote, decisions are taken for execution from the next sprint. Scrum Master monitors the course of the meeting and monitors its regulations.

Why did Agile appear?

Now a few words about how and why this approach appeared? The history of this approach was a response to the industry’s requests:

• The customer cannot formulate clear requirements for the software
• New technologies have increased competition and demanded operational application in business.
• Customers and software developers are not satisfied with the process of interaction.

# 1 The customer cannot formulate clear software requirements

In the initial phase of the project, the customer cannot formulate comprehensive requirements for the product. There are several reasons for this:

• The Customer only has an idea for the application and does not represent all of its functionality;
• The project team has a different view of the functionality of the application;
• The team cannot agree on how it will be more convenient / more reasonable to implement this or that part of the functionality of the application.
• One of Agile’s principles is “Use prototypes and make product shipments as often as possible.” This will remove the uncertainty in the requirements and verify how real users will work with it.

In traditional “waterfall” model, the project manager minimizes changes in the project, using separate processes for this purpose – change management. But if the requirements change every month, then change management becomes time-consuming and slows the progress of the project.

In Agile, the reaction to change is more important than following a plan. Agile is welcomed when the customer and users make new demands to make the product more competitive.

# 2 New technologies strengthened competition and demanded operational application in business

By the mid-90’s, the software being developed was mostly desktop and needed to be installed on every single computer (for example, MS Word). With the advent of web applications, the introduction of new functionality began to happen more quickly: it was required to deploy the application only on the server and all users could access it.

This innovation has seriously intensified the competition between companies: the one who applied the new technology earlier than the others – wins the market and customers.

The Agile approach provided the businesses with the one more advantage – fast delivery of new functionality. This allowed each month to produce a product and receive feedback from users on-the-fly.

# 3 Customers and developers are not satisfied with the process of interaction

With a tough deadline and constant changes, the developers are forced to formalize the processes of interaction with the Customer. Developers put the assembling of detailed requirements and specifications as well as the risks for possible changes in budget work. At the same time, the Customer is forced to pay for documents that do not carry real value for business.

The main idea is agile – cooperation with the customer is more important than contractual obligations. And so agile methods tend to reduce the amount of documentation. This allows the customer to pay only for the result, which has value for business.

At the same time, agile does not refuse to formulate requirements. The customer (in the agile – the owner of the product, product owner) makes demands in a simplified form and on the scenarios of users’ work.

Summary

Agile-philosophy is simple. Agile principles are reasonable. But moving to the real use of agile is a serious challenge for every team. It is required not only to master a new approach to project management, but also to select people who can work in agile mode.