Agile rituals: essential practices for a successful Scrum (1/2)

Agile Rituals: Roles and Structure in Scrum

There is a lot of talk about agile methods and rituals, their efficiency and flexibility. However, agility is not without a framework. Indeed, there are several agile methods, as well as several specificities in the way to implement the agile manifest. While there is no one-size-fits-all method, Scrum is the most suitable method in the context of IT. It is, in fact, the most implemented today in IT.

Be careful, this method requires a lot of rigor, especially concerning the respect of rituals.

Indeed, the whole operation of Scrum is based on a very precise framework:

well-defined roles with a clear and defined scope
time-bound rituals(time-boxed)
agility principles and values

In this first part we present the roles and structure of our teams and rituals.

Agile ceremonies and rituals: agility is not a religion, nor a sport, but it borrows some codes

In some companies, Scrum is often recognized by the presence of colored notes on the walls of the work spaces. In practice, there are other elements, such as computer tools, games to produce the product, as well as many ceremonies that punctuate the life of an agile team.

Here we will talk about the rituals that have been put in place within the Service Center (SC) of Blue Soft. But first, it is important to briefly present the actors, the types of stories and the life of the Backlog.

In our agile teams, you will find the following roles:

The Product Owner (different from the Project Manager)
The ScrumMaster
The Developer (for this role we can have up to five developers)

We believe that the right size for an agile team is seven to nine people maximum.

At Blue Soft, we are unique in that the team can be followed by an architect for up to three days per sprint, particularly in the case of our CDS agile service offerings (Agility As a Service).

During a sprint, our teams may embark on four types of stories, which can be classified into two categories:

Stories that add value to the product:

Functional story
Technical story

Stories to restore value:

Repayment of technical debt
Bug fix

All the stories make up the Backlog, which represents the life of the product.

In Scrum, we usually have several "bins" that make up the life of the Backlog:

the sandbox
the ice box
the culture tray
the starting tank

At Blue Soft we don't consider the backlog icebox.

We start from the Sandbox and flow directly to the Grow Bin, without going through the Icebox. The process continues from the Grow Bin to the Start Bin, in order to build the Sprint Backlog. This passage between the bins takes place during the Backlog Refinement workshops.

The Scrum context at Blue Soft being established, we can talk about the rituals.

The first value of agility is to focus on the interactions between individuals, more than on tools and processes. In concrete terms, this translates into a daily search for balance between the interactions of individuals and processes.

The course of all events is bounded by the notion of time-boxing.

Agile rituals: The typical Product Backlog Refinement at Blue Soft

The Product Backlog Refinement meeting is often neglected and misunderstood by some. However, it is very useful in the daily practice of Scrum.

Objective:

It is used, first of all, to prepare the product backlog. At Blue Soft, it can be planned several times in a sprint:

to refine the Backlog, before the Sprint Backlog,
at the end of the first week for a two-week sprint and at the end of the second week for a three-week sprint. The goal is to make adjustments in the current sprint,
if the team expresses the need, in order to set up workshops and points necessary for the good progress of the sprint.

Prerequisite:

The starting bin must be up to date, for a preparation of the sprint backlog
The Backlog must contain items that have already been started, in order to make adjustments during the sprint
Participants must be informed in advance of the workshop.

The participants are either the team alone, or the team with business experts and the architect or our UX-Experts, who intervene during certain phases of our product development.

Agile rituals: the Chez Standup Meeting Blue Soft

This daily meeting is officially called the Daily Scrum Meeting (DSM). Its purpose, on a daily basis, is to optimize the team's chances of reaching its objectives and keeping its commitments for the sprint.

At Blue Soft, we rely on inspection and adaptation in order to carry out a DSM:

Quickly identifying obstacles to the team's progress,
improving and measuring, on a daily basis, the progress of the team's work on the sprint,
Preparing the necessary work to finish the stories.

Prerequisite:

In order to ensure the effectiveness of the meeting, a preliminary preparation of each team member, for the respect of the formalism necessary to the ceremonial, is necessary. The whole team participates: the Product Owner, the developers and the ScrumMaster.

This meeting must last fifteen minutes maximum and is facilitated by the Scrum Master. It is a ceremony that belongs to the team.

It is recommended to meet in front of the "Scrum board". Each team member takes turns answering the following questions:

What was done the day before?
What was done on the day?
What are the tasks to be done?
Are there any blockages?

NB: this is not a "review of the troops", but the possibility to offer a global visibility on the tasks and transparency on the life of the team.

The output result consists of :

An updated backlog with tasks that are as close to reality as possible.
Visibility into the product, what still needs to be done and where the roadblocks are.
The implementation of an action plan in case of delay or strong constraint
A projection of the product trend and an insight into the life of the team.

Agile rituals: The Chez Sprint planning Blue Soft

This is the most famous Scrum ritual.

Objective:

Putting the team in the ideal situation to succeed in the sprint. In other words, it means providing a framework and the means to encourage everyone's commitment, in close collaboration.

Prerequisite:

The starting tank is essential for this meeting, and a backlog must be ready. Stories prioritized by the Product Owner and the Scrum or with the team should be prepared during a Refinement Backlog session.
The definition of Story Ready is understood by all team members
A backlog ready and sized for the sprint with stories that meet the requirements.

The whole team participates: the Product Owner, the developers and the Scrum Master.

Duration:

Between two and four hours

Procedure:

For a few years, this meeting was carried out in two phases, the first one for the identification of the stories to be included in the sprint and the second one for the division of the stories into tasks.

However, if this long format persists for some, others like Blue Soft have chosen to split it into two. The first phase is the classic one, which allows to size the sprint and to ensure the understanding of the stories by the team. The second phase includes the poker planning and the breakdown of tasks (thus making the poker planning a ritual in its own right).

In summary, the Product Owner announces the stories, in order of priority. He presents each story to the team. The team then makes sure that it is ready, comprehensive and small enough to be done.

At each story, the team must ensure:

the understanding of the expressed need, the context and the business rules,
that the story meets the criteria of realization, finishing and conditions of acceptances,
that the story meets the defined conditions, to consider it ready.

Once the team has validated all the elements of eligibility of the story, it makes a rough estimate of its realization.

NB: It is possible to take out the estimates of the tasks in another ceremonial when, by carrying out a Poker planning or Magic Estimation (These two rituals are not treated in this article)

The output result consists of :