Considering the popularity of agility, we could be tempted to think that it is opposed to more traditional methodologies like the V-cycle. In a misinterpretation, it is common to believe that agility is better than anything that came before.

This would be falling for the buzz, limiting the analysis and forgetting that the popularity of agility is supported by its adaptation to the uncertainty of our time. This is what we wanted to highlight earlier.

The so-called classical models of organization and project steering have evolved to meet the constraints of "time to market". Constantly innovating, reducing costs, and being as responsive as possible are all imperatives that have driven agility. By involving the requester as much as possible and always seeking to provide the most value, an agile trajectory does not only involve development teams. The following illustration shows that the scope of agility extends far beyond project management or the production of software solutions. It is an organizational change that creates a value chain by connecting all professions.

Scrum is the most popular and widely implemented tool, so much so that there is confusion.

As if Scrum and agile were synonymous.

This amalgamation of "agility is scrum and scrum is agility" seems understandable, but it is not true, because:

• Scrum is not the only way to do it, there are other approaches like extreme programming (XP), Kanban, SAFe...
• Agility is a culture, a mindset.

The origin of Scrum and its foundations

Scrum refers to a sport's term. More precisely, the rugby's scrum! This is no coincidence because according to its creators, it shares the same values of such sport: commitment, courage, focus, openness, and respect.

The Scrum approach was created by Jeff Sutherland and Ken Schwaber in the 90s to help organizations develop, deliver, and maintain complex (digital but not only) products. They are at the origin of the Scrum Guide published in 2009.

Scrum is an empirical approach, which means that a team working in Scrum will test, learn, and adjust along the way. Thus, knowledge comes from experience, decisions are made from what is known and not from theories and assumptions.

This is also why we cannot speak about a method, since a method usually explains how to do things. Scrum is not a recipe to follow to make your software successful, avoid issues, and limit unforeseen events... It can be seen as a rule of the game: it gives a framework and the role of each player. It is up to the team to evolve and build its own strategy to achieve its objectives.

To achieve empiricism, Scrum is supported by three pillars:

• Transparency: the whole project team must understand and share the important aspects of the project, communication is crucial!
• Inspection: the team checks their work as it goes along, not at the end once the product is finished. They also inspect their way of doing and how they work.
• Adaptation: adjustments can be made to minimize the risks (delays, discrepancy with user needs, etc.).

The components of Scrum

Scrum is made of 3 main roles, 5 events, and 3 "artefacts" that we will describe in the following article. Please note that these roles, events, and artefacts are mandatory. The Scrum Guide is very clear about this: not respecting any of these roles/events/artefacts results in the loss of transparency and opportunities to inspect and adapt the product.

Scrum in detail

Having laid the foundations and detailed the basics of Scrum, let's take a closer look at its rituals. Scrum is made up of some essential elements of this approach:

3 main roles

• The Product Owner
• The Scrum Master
• The Dev Team

5 events

• The Sprint Planning
• The Sprint
• The Daily Scrum
• The Sprint Review (Delivery)
• The Sprint Retrospective

3 "artefacts"

• The Product Backlog
• The Sprint Backlog
• The Increment

The Scrum Team

• The Product Owner (PO): they carry the vision of the product to be designed. They bring their knowledge of the market and user needs. They write and keep the Product Backlog up to date, which lists all the product's features.

• The Scrum Master (SM): they are not always present in Scrum teams, and sometimes the Product Owner fills this role. They are responsible for the framework and ensures that the various Scrum events take place on time. They also play the role of facilitator.

• The Dev Team, or developers’ team : They are a group of 5-10 "doers" who develop the product.

They are also involved in:

• The stakeholders: these are the customers and/or users of the product being developed. They intervene during certain events or through the Product Owner.

• The UX designer: this is a trend that we are seeing more and more. The integration of an UX designer in a Scrum team allows for a good duo with the Product Owner, and keeps the user at the center of the creation process.

There is no hierarchy in a Scrum Team: everyone is equal, and decisions are collective. The team is self-organized and multidisciplinary.

Everything starts from the Product Backlog

It all starts with the first artefact: the Product Backlog. This is a written document containing all features, requirements and improvements related to the product. It is written and updated by the Product Owner.

The features are written in the form of User Stories.

Example for a VTC application: "As a customer, I want to be located on a map so that I don't have to enter the address of my location."

The 1st ritual: Sprint Planning to prepare the sprint

The team meets during the Sprint Planning to choose the User Stories (US) that will be developed during the Sprint. Like all Scrum events, Sprint Planning has a "timebox", i.e. a maximum duration. For it, the maximum duration is 8h (for a 4-week sprint).

At the end of the Sprint Planning, each User Story should be clear and estimated, and the Dev Team members should know what action plan to adopt in order to achieve the Sprint Goal.

How are the User Stories estimated?

To estimate a User Story, the team members organize a Planning Poker, a card game that allows everyone to vote and estimate the effort required to achieve it. Example: a very easy task that will take a long time to do is not equivalent in points to a very easy and quick task to do.

The User Stories selected for the sprint form the Sprint Backlog.

From User Stories to Incrementation: the Sprint

The Sprint objective is to develop a functional part of the product to be developed: an Increment. It is up to the team to define its duration, which should not exceed 4 weeks. When a sprint ends, a new one will start.

Each day of the sprint the team meets during the Daily Scrums. Usually at the beginning of the day and lasting 15 minutes, their aim is to strengthen the transparency and responsiveness of the team. Everyone shares their actions of the day and the difficulties they or the project encounters. The team can then adjust and set up action plans.

Deliver, test, and adjust: the Sprint Review

At the end of the Sprint, a Sprint Review is organized, also known as the Delivery phase. Lasting a maximum of 4 hours, it brings together the Scrum team and the stakeholders (the customer) and/or users.

A demonstration of the developed increment is made. The Scrum team then collects valuable feedback which will be added to the Product Backlog. It is also often the opportunity to detect bugs, which will be corrected during a next Sprint.

It is an important moment since it represents the meeting between those who make, and those who use. The Scrum team understands who they work for and why, and the users feel like they are listened to and involved in the creation process.

Self-analysis: the Sprint Retrospective

Last event: the Sprint Retrospective

This is a 1-hour meeting allowing the Scrum team to analyze themselves by highlighting what worked during the Sprint, what did not work, and to set up a continuous improvement plan with concrete actions.

"Design thinking is a collaborative problem-solving approach that is iterative, human-centered, creative, and concrete." Tim Brown - IDEO Co-Founder

Design thinking was theorized in the early 2000s in Silicon Valley following the work of engineer David Kelley and designer Tim Brown of the IDEO agency. The process is often summarized as a team brainstorming session or creativity workshops with post-it notes. But as we shall see, there is a little more to it...

This is an approach that uses the tools and methods of designers, in order to design solutions that respond to user problems that have been identified beforehand.

The Design Thinking process can be broken down into two main phases in the form of double diamond, or hourglass, as it is a succession of divergence phases (exploring, looking at the bigger picture) and convergence phases (selecting, prioritizing).

User understanding and research

Design thinking is a human-centered approach. Everything starts by observing the field, understanding the needs, habits, and issues experienced. By adopting an empathetic posture, we meet the emotions and reasoning of the users.

It is also an opportunity to do research on the subject's ecosystem. Monitor what has already been done, good and bad practices, existing technologies... This is the first divergent phase of the process, since it can cross many different areas depending on the subject we are dealing with!

A few designers' methods for user research:

• User interview, surveys...
• "Fly's eye view" observation
• "Live my life" immersion
• Photo report
• Defining a bias

This research work allows to highlight a real problem to be dealt with, which is not necessarily the first one to come to mind. It is about clarifying the perimeter and adopting a bias: identifying the right problem is the best way to find the right solution!

A few tools to synthesize user research:

• Empathy Map
• Persona
• Users’ pathways
• Ideation and creativity

This is where brainstorming and post-it notes come in! Once a real problem is identified, it is time to come up with creative solutions to solve it. This is a divergent phase, as it involves exploring and proposing concepts and solutions without restricting their feasibility and desirability. The goal is not to find THE right solution, but to generate as many problem-solving ideas as possible.

To achieve this, here are some tips for effective brainstorming:

• Come up with crazy ideas, there are no limits!
• Building on the ideas of others, those of colleagues in the team but also from other areas, other cultures...
• No judgement
• So as not to restrict creativity
• Staying focused on the user and the subject
• to be efficient and avoid 2-hours brainstorming sessions without any pragmatic solution
• Search for quantity

Prototyping, testing, and iterative process

It is time to select from all the previously produced solutions the one, or the ones, you wish to test.

To have these solutions tested, they must be materialized using a prototype. The first prototypes are simple and quick to produce, but they provide valuable initial feedback to validate or invalidate the chosen solution. As design thinking is an iterative process, it is still possible at this stage to go back to the ideation phase and produce or select new ideas to test. It is also possible to further improve your prototype to make it more complete, more precise, and more realistic, and to have your proposed solution tested once more.

A few prototyping suggestions:

• Advertising posters
• Interactive website or app mock-ups
• Scenarios and models
• Product packaging

During the test phases, you should not only test the desirability of your solution: "do you like it?" but understand why this solution is liked or not, and thus analyze whether it answers the problem that was identified earlier.

A few testing tools:

• A/B testing
• Interviews and surveys
• Focus groups
• Feedback grids

If the testing phase is successful, the solution becomes a POC - Proof Of Concept which illustrates the feasibility and desirability of the solution. It's time to move into the production and deployment phase!

Design Thinking and agility

Design thinking is not a project management methodology, but an approach to imagine and design solutions. Thus, it does not fall into the family of agile approaches (such as Scrum, SAFe, XP, etc.) which aim to deliver the product.

However, carrying out the design thinking creation process cannot be applied without adopting an agility posture.