Knowledge-base
  • Home
  • Samman Technical Coaching
  • Software craftsmanship
    • Practices
      • Pair Programming
      • Code Review
      • Co-designs
      • Design sessions
      • Interview Domain Experts
      • Dev ethics
    • The Software Craftsman
    • Egoless Crafting
    • Technical debt workshop
    • Functional Programming made easy in C# with Language-ext
    • F# for OO programmers
    • Domain Modeling Made Functional
    • Testing
      • Clean Tests
      • Improve the design and testing of your micro-services through CDC Tests
        • CDC testing made simple with Pact
        • Pact broker : the missing piece of your Consumer-Driven Contract approach
      • Improve your test quality with Mutation testing
      • How to name our Unit Tests
      • How to write better assertions
    • Katas
      • TDD
        • Stack kata
        • Fizzbuzz
        • Outside-in TDD (London Style)
      • Improve your software quality with Property-Based Testing
        • A journey to Property-Based Testing
      • Clean Code
      • Clean Architecture
      • Write S.O.L.I.D code
      • Mocking
      • Gilded Rose (Approval Testing)
      • Mikado method
        • Mikado kata
      • Pure functions
      • Theatrical players refactoring Kata
        • Let's refactor (OOP style)
        • Let's refactor (FP style)
      • Functional Programming made easy in Java & C#
      • Refactoring journey
      • Refactoring du Bouchonnois
        • 1) Se faire une idée du code
        • 2) "Treat warnings as errors"
        • 3) Let's kill some mutants
        • 4) Améliorer la lisibilité des tests
        • 5) "Approve Everything"
        • 6) Définir des propriétés
        • 7) Tests d'architecture
        • 8) Use Cases
        • 9) Tell Don't Ask
        • 10) "Avoid Primitives" - Commands
        • 11) "Avoid Exceptions"
        • 12) "Event Sourcing"
    • Software Design X-Rays
      • Workshop
    • The Programmer's Brain
      • How to read code better
  • Software Architecture
    • Fundamentals of Software Architecture
    • Aligning Product & Software Design
    • DDD re-distilled
    • Test your architecture with Archunit
    • NoSQL
  • Agile coaching
    • How to run a Community of Practices (COP)
    • The developers — the forgotten of agility
      • The secrets to re-on-board the devs in agility
    • Coaching toolbox
      • Echelle
      • Learning expedition
    • How to improve Team Decision making ?
      • Decision Making Principles and Practices
    • Learning 3.0
    • Retrospectives
      • Back to the Future
      • Mission Impossible
      • Movie themes
      • Rétro dont vous êtes le héros
      • Sad/Mad/Glad
      • Speed boat
      • Star wars theme
      • Story cubes
    • Technical Agile Coaching with the Samman Method
    • Xanpan - a team centric agile method story
    • XTREM WATCH — Découvrez la puissance de la veille collective
    • Become a better speaker through peer feedback
    • Project-to-Product Principles
  • Leadership
    • Bref. J'ai pris une tarte dans la gueule (et ça fait extrêmement de bien)
    • Forward Summit 2020
    • Learn leadership from the Navy SEALs
    • Learn to lead and help your team(s) to be successful
    • Towards a learning organization and beyond
    • Leadership is language
  • Serious games
    • My serious games
    • Libérez vos entretiens d’embauche avec la gamification
    • How to create a game
    • How to debrief a game ?
    • Lego Serious Play (LSP)
      • LSP in your job interviews
  • Xtrem Reading
    • Cultivate Team Learning with Xtrem Reading
    • My Book Infographics
    • How to make book infographics
    • En route vers l’apprenance avec Xtrem Reading
    • Resources
      • Book notes
        • Agile People: A Radical Approach for HR & Managers
        • Agile testing : A Practical Guide for Testers and Agile Teams
        • Boite à outils de l'intelligence émotionnelle
        • Building a better business using Lego Serious Play method
        • Building evolutionary architectures
        • Code that fits in your head
        • Culture Agile
        • Culture is everything
        • Domain-Driven Design: The First 15 Years
        • Dynamic Reteaming - The Art and Wisdom of Changing Teams
        • How to avoid a Climate Disaster
        • La liberté du commandement
        • Réaliser ses rêves, ça s'apprend
        • Refactoring at Scale
        • Succeeding with OKRs in Agile
        • Team Topologies
        • The Good Life
        • Tu fais quoi dans la vie
        • Who Does What By How Much?
  • My Activity
    • Retour sur mon année 2020
Powered by GitBook
On this page
  • Why you should read this article
  • The genesis — the agile manifesto
  • Scrum
  • Observed anti-patterns
  • The Scrum Master
  • The Product Owner
  • The Spring planning
  • The Daily scrum
  • The Sprint review
  • The Sprint retrospective
  • Self-organization
  • Cross-functional teams
  • Lost in agile
  • How to re-onboard them ?
  • Resources

Was this helpful?

  1. Agile coaching

The developers — the forgotten of agility

PreviousHow to run a Community of Practices (COP)NextThe secrets to re-on-board the devs in agility

Last updated 4 years ago

Was this helpful?

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, …)

Scrum

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.

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

Observed anti-patterns

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

The Scrum Master

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

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

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.

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

The Spring planning

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

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.

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

Anti-patterns

  • 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

Anti-patterns

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

Self-organization

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.

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

Cross-functional teams

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

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.

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

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 ?

How to re-onboard them ?

Resources

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

That came out from their discussions is what we know as the : 4 values and 12 principles. It is the heart of agile and it has been designed by developers for developers.

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

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

In this world companies must be able to adapt and change quickly.

agile manifesto
state of agile
scrum guide
VUCA
The secrets to re-on-board the devs in agility