Agile methodology

Agile methodology refers to a set of software development methods that are opposed to the Waterfall Model and other traditional approaches. It proposes a less structured approach that focuses on the objective of delivering to the customer - frequently and in a short time - working and quality software.

Among the practices promoted by agile methods are the formation of small, self-organised development teams, adaptive planning and the direct and continuous involvement of the client in the development process.

The Agile Manifesto is based on four principals:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

Waterfall Model

The Waterfall Model is the most traditional model describing the software life-cycle. According to it, the software development process is structured into the following five clear phases:

1. Requirements analysis
2. Design
3. Development
4. Test
5. Maintenance

As we can see, the most important distinction among the two models is the fact that Agile provides a development for subsequent refinements which the Waterfall Model does not.

Scrum

Definitions

Scrum is an Agile Framework. You can think of it as one possible implementation of the Agile guidelines: if Agile provides the recipe, Scrum puts in the ingredients to realize it.

To create a product with Scrum, we receive specifics from stakeholders, i.e. from all those interested in creating the product itself.

In Scrum those specifics are called user stories or just stories and they are a brief description of a requested feature under the user's point of view. The way user stories are written is overall standard:

As a <type of user>
I want <some goal>
So that <some reasons>.

All the stories are grouped into the product backlog which is a required list of features related to the product.

In Scrum people necessary for the realization of a product are divided into:

• Product Owner - represents the stackeholders and is the voice of the clients. He ensures that the product developed provides value to the business and writes the stories assigning them a priority. Then he adds them to the Backlog.
• Scrum Master - removes obstacles that limit the team's ability to achieve the sprint goal. He is not the Team Leader
• Development Team - they are responsible for product development; generally consisting of 3 to 9 people, it self-organises and self-manages.

A Sprint is the base development unit of Scrum development. With a fixed duration (from 1 to 4 weeks), during the Sprint the team works and develops all the user stories that pledged to deliver at the end of the Sprint. The delivered product at the end of each Sprint is called increment.

Workflow

The most common events that occur during a Scrum process are the followings:

1. Backlog refinement - The Product Owner meets the team to discuss the stories currently in Backlog. He shares the priority of each story and defines the concept of done, i.e. when a story can be considered as finished.

2. Sprint Planning - The team chooses the stories it undertakes to deliver at the end of the Sprint. This choice is made considering the priorities assigned by the Product Owner.

3. Sprint - As already discussed above, during a Sprint the team works to develop the user stories assigned to the Sprint. At the end of each Sprint, the value of the stories (generally measured in story points) contributes to give an estimation of the speed's team. A certain number of story points corresponds to a certain amount of hours that the team expects to need to finish the story.

4. Daily Scrum - The Scrum Master meets the team and each member answers to three simple questions:

   • What have I done yesterday?
   • What am I going to do today?
   • What are the obstacles I encountered yesterday during my work?

5. Sprint Review - The team shows to the Product Owner and the Stakeholders what he did during the Sprint. Generally, this meeting includes a demo of the new functionalities implemented in the application.

6. Sprint Retrospective - The Scrum Master meets the team and tries to identify the things the team does well, what it should start doing to improve performance and what it should stop doing.

The following diagram describes in which order these events occur:

Implement Scrum

Jira is a professional and complete tool implementing Scrum. It's often used by large companies and offers a board where all the stories for a given Sprint are presented.

Stories on the board are sometimes called tickets. Jira includes a distinction among tickets to simplify the planning part. They are divided into:

• Epics - Very big tickets that generally contain a general use case that is a collection of user stories (i.e. authentication).
• User stories - Represents a user feature (i.e. forgot password).
• Sub tasks - Development tasks to accomplish a user story (i.e. implement HTML/CSS of login screen).
• Defects - A bug was found in a released story and needs to be fixed (i.e. login button doesn't work on Safari).

A less popular and less professional tool to implement Scrum is Trello. It is very simple to use and - despite having less features than Jira - it is recommended for projects that don't require a strong management infrastructure for building, fixing and releasing software. It is also definitely a good starting point for learning how Agile development works.

Trello provides a public board where you can learn more about Scrum and using the tool.

Why does Scrum fail?

What we learned so far is that Scrum is great and provides a useful support in planning, organization and development. Then why does it (sometimes) fail? or rather, to be more precise, why Scrum fails in large enterprises?

There are various reasons behind that:

• The Product Owner is not involved in the process as much as he should and doesn't have a customer mindset.
• Team members lack in experience (and consequently fail a Sprint).
• The Scrum Master fails in removing the obstacles encountered by the team.
• No clear roles distinction.
• Bureaucracy prevents a successful Sprint (i.e. tickets are blocked because they are not approved).
• Bad management and pyramidal scheme.
• The team is not informed on the big picture and completes user stories blindly.
• Lack of testing strategies.

We can reconnect most of these problems I mentioned (and those I didn't mention you can add to the list) to a main one: lack of communication. Meetings and discussions are important but they need to provide additional value to the entities joining in: the team must have a clear vision of what they are building, the Product Owner shouldn't start doing commands or speak one-to-one with developers, the Scrum Master must fulfill his role of "man in the middle".

Unfortunately large companies have always difficulties in integrating Agile in their structure and/or they do not have sufficient experience in understanding how to do it properly: they have different business units, more processes and, most important, a strong culture that defines how things are done, and this is something that makes an integration even more difficult.

Conclusions

Agile methodology and Scrum offer useful mindsets and tools to deal with development for subsequent refinements and in turn propose a successful working strategy. Unfortunately, large companies often fail in implementing it due to their culture and their complexity. However, by putting effort in integrating it, Agile proves to be a reliable method for software developing.