# The developers — the forgotten of agility

## Why you should read this article

Little by little, **Agility has been diverted and no longer belongs to developers.** In this article you will understand how much the developers have become forgotten from agility.

## The genesis — the agile manifesto <a href="#id-1a5d" id="id-1a5d"></a>

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MF9SNKHoihtxgGD066M%2F-MF9SdlY3Uy9NYPmZiy3%2Fimage.png?alt=media\&token=932e7929-8740-4853-90da-181bb81b26b9)

In 2001, 17 brilliant developers tried to find an answer to this interrogation: the way we deliver software is not efficient at all. How could we do it differently, so they asked themselves a lot of questions:

* We have a lot of tools and a lot of processes, **BUT** what about the people ?
* We create a lot of documentation up front **BUT** our goal is to deliver software isn’t it?
* A contract is important **BUT** we need to collaborate with our customers to discover what they need.
* Our plans are too rigid we must embrace changes. Change is everywhere in our time (concurrency, technology, politics, climate, …)

That came out from their discussions is what we know as the [agile manifesto ](https://agilemanifesto.org/): 4 values and 12 principles. It is the heart of agile and it has been designed **by developers for developers**.

## Scrum <a href="#id-1bb8" id="id-1bb8"></a>

Nowadays when you talk about agile, people will make a shortcut and will talk to you about scrum that’s because Scrum is the most used agile framework in companies.

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MF9SNKHoihtxgGD066M%2F-MF9Sm5ow7tlhiGJ6OAu%2Fimage.png?alt=media\&token=93967025-e4f2-4132-9579-df0fb563531a)

In 2018, it represented almost **70% of the agile methodologies** used in agile companies (number from the [state of agile](https://www.stateofagile.com/) ).

The rules of the game are simple, and all explained in the scrum holy bible: the [**scrum guide**](https://www.scrumguides.org/). It’s only an **18 pages guide** explaining the values, concepts behind the notion of sprint, the artefacts (product backlog for example), the different events (From daily scrum to retrospective), the roles (Product Owner, Scrum Master, Dev team)

{% hint style="danger" %}
_**Scrum is really easy to understand but what about its implementation?**_
{% endhint %}

## Observed anti-patterns <a href="#id-9923" id="id-9923"></a>

The anti-patterns described below are the ones we have observed in our coaching experiences.

### The Scrum Master <a href="#id-9a46" id="id-9a46"></a>

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MF9SNKHoihtxgGD066M%2F-MF9T-8JXcroK68nxAze%2Fimage.png?alt=media\&token=53d4e7ca-4bcb-4c5f-af67-7410f6ae4e46)

#### Anti-patterns

* “Everybody can be a scrum master” because no skills are required.
* “We have a developer that is really bad, and no one wants to work with him let’s choose him as scrum master he won’t hurt the code base anymore”.
* Scrum masters acting as a shield that block all interactions. No one has access to the team anymore
* Let’s put our project manager as scrum master it’s the same job at the end

{% hint style="warning" %}
The scrum master role is the most misunderstood role. It requires a lot of soft skills (facilitation, communication, empathy) and it’s definitely not the same job as project management.
{% endhint %}

### The Product Owner <a href="#id-5cb5" id="id-5cb5"></a>

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MF9SNKHoihtxgGD066M%2F-MF9TF30tOCqANcJyvx1%2Fimage.png?alt=media\&token=279a9ef6-57fd-4246-a972-381ba05be0c1)

#### Anti-patterns

* Is not empowered to say NO and accepts everything from the stakeholders.
* Does not act as a vision holder because he has none.

{% hint style="warning" %}
By not holding a vision it creates a loss of meaning and motivation for the Dev team.
{% endhint %}

### The Spring planning <a href="#eab6" id="eab6"></a>

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MF9SNKHoihtxgGD066M%2F-MF9TYRuD7HE0X4OswA6%2Fimage.png?alt=media\&token=458c3da0-51e0-49d5-8235-83eb6119d431)

#### Anti-patterns

* The Product Owner or the Scrum Master act as dictator and push the items from the Product backlog directly to the Sprint backlog without negotiation nor collaboration with the Dev team…

### The Daily scrum <a href="#id-0ce5" id="id-0ce5"></a>

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MF9SNKHoihtxgGD066M%2F-MF9Tpavt7031WeNQ5bG%2Fimage.png?alt=media\&token=fe0071de-140b-49ba-af82-41fd01ef8563)

#### Anti-patterns

* People justify themselves in front of their PO and SM.
* Only one guy monopolizes the attention a.k.a it becomes a One man show.
* An event not time boxed and running for 1 hour without creating any value.

{% hint style="warning" %}
This moment is often lived as a micro-management moment because in most organizations PO and SM are perceived as team managers.
{% endhint %}

### The Sprint review <a href="#e00d" id="e00d"></a>

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MF9SNKHoihtxgGD066M%2F-MF9U1vwIumX2L5OtzZq%2Fimage.png?alt=media\&token=73be9afa-6e17-4d2b-906f-0150663c8d94)

#### Anti-patterns

* The demo of the product increment is made by the Product Owner not the team.

{% hint style="warning" %}
When you work during an entire sprint on a product increment you are proud of and you don’t have the opportunity to demonstrate it and gather feedback by your own, it creates a lot of frustration inside the team.
{% endhint %}

### The Sprint retrospective <a href="#id-9935" id="id-9935"></a>

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MF9SNKHoihtxgGD066M%2F-MF9UDLebRYg4Jn1JukE%2Fimage.png?alt=media\&token=427edd5d-4446-4dbe-ab44-8f842a2bc9e1)

#### Anti-patterns

* Developers are not “allowed” to talk about technical concerns, only about how to improve the process.

{% hint style="warning" %}
Often in Dev teams they have impediments related to the technical side (environment issues or technical debt for example). Scrum Masters do not tolerate this kind of discussions during the retrospective, so when can the dev team take time to introspect and adapt on the code base and technical stuff ?
{% endhint %}

### Self-organization <a href="#id-37e6" id="id-37e6"></a>

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MF9SNKHoihtxgGD066M%2F-MF9UVkL77Dk1kGe15zR%2Fimage.png?alt=media\&token=10b51531-5c94-49d5-a712-b49b853b109d)

#### Anti-patterns

* People do not have the space for experiment: NO! It’s not in scrum.
* The team is self-organized but once it made a decision an agile evangelist comes and say you will fail, take this decision instead.

{% hint style="warning" %}
Often self-organization is a sweet dream. A lot of organizations are not ready to trust people.
{% endhint %}

### Cross-functional teams

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MF9SNKHoihtxgGD066M%2F-MF9UoUtuOVB_RyuESUR%2Fimage.png?alt=media\&token=fdd5fc3e-3703-496a-a89b-4c26f0c26256)

#### Anti-patterns

* “No roles in the dev team, everyone is a developer.” By saying this it does not tolerate that there are specialists (Data scientists, UX, Testing).
* “Everyone must know everything about everything.” Team members must be circle-shaped people (experts in all the skills required to build the product).

## Lost in agile <a href="#cb5b" id="cb5b"></a>

![](https://1936518372-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MAffO8xa1ZWmgZvfeK2%2F-MF9SNKHoihtxgGD066M%2F-MF9UxRRtWqAhqqmqv7X%2Fimage.png?alt=media\&token=097ab216-799b-4860-b914-90b8f087ab10)

{% hint style="danger" %}
Developers do not find themselves in this version of agility. They feel that is no longer in their hands. **It’s not the idea’s fault, it’s the implementation.**
{% endhint %}

They all believe in the manifesto for them “&#x69;_&#x74;’s common sense_” **BUT** they no longer feel concerned (“_It’s for project managers, PMI_”).

* In this digital era companies need them to build their products.
* In this [VUCA](https://www.vuca-world.org/) world companies must be able to adapt and change quickly.

For those reasons companies need to be more agile. They strongly need to think on **ways to re-on-board the developers in agility.**

{% hint style="success" %}
As agile enthusiasts we strongly believe that agile is a good answer to developers past and current problems. **How can we help them to embrace it again ?**
{% endhint %}

## **How to re-onboard them ?**

{% content-ref url="the-developers-the-forgotten-of-agility/the-secrets-to-re-on-board-the-devs-in-agility" %}
[the-secrets-to-re-on-board-the-devs-in-agility](the-developers-the-forgotten-of-agility/the-secrets-to-re-on-board-the-devs-in-agility)
{% endcontent-ref %}

## Resources

Here are the slides of a talk given in the Luxembourg Agile Community :

{% embed url="https://speakerdeck.com/thirion/the-devs-the-forgotten-of-the-agility" %}

