The developers — the forgotten of agility

Yoan Thirion
5 min readJun 18, 2019


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

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 : 4 values and 12 principles. It is the heart of agile and it has been designed by developers for developers.


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.

In 2018, it represented almost 70% of the agile methodologies used in agile companies (number from the state of agile ).

The rules of the game are simple, and all explained in the scrum holy bible: the scrum guide. 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)

Scrum is really easy to understand but what about its implementation?

Anti-patterns we observed

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

The Scrum Master


  • “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

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.

The Product Owner


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

By not holding a vision it creates a loss of meaning and motivation for the Dev team.

The Spring planning


  • 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


  • 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.

This moment is often lived as a micro-management moment because in most organizations PO and SM are perceived as team managers.

The Sprint review


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

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.

The Sprint retrospective


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

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 ?



  • 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.

Often self-organization is a sweet dream. A lot of organizations are not ready to trust people.

Cross-functional teams


  • “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

Houston !!! we have a problem

Developers do not find themselves in this version of agility. They feel that is no longer in their laps.

It’s not the idea’s fault, it’s the implementation.

They all believe in the manifesto for them “it’s common senseBUT 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 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.

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 ?

This article has been built based on our talk “Lost in agile” from Adrien Muller and Myself