• Mar 3

We allowed ambiguity over who is doing what in the name of agility

    Back in 2001, Fowler, Beck, Alistair, Uncle Bob and a few others met in Snowbird, Utah. They wrote a short manifesto saying we value individuals and interactions over processes and tools. The point was to find better ways of developing software.

    The situation

    I am asking myself how did we get from that to this? The process changes every year. New trend. Squads. Tribes. Standups where we don’t stand anymore...

    I am thinking do these folks know what they are doing? Do they know that their sole contribution is to lower our productivity?

    The problem

    There is no single point of accountability.

    Look at football teams. When Manchester United keeps losing, who gets fired? The coach. Not the striker. Not the left winger. The coach.

    Now in our world, these folks try to convince us that we are all accountable. Bullshit.

    When the shit hits the fan, they hide. And they leave us to deal with it. In front of upper management, it becomes: the dev team didn’t deliver.

    I can’t help but remember that part from Essentialism: The Disciplined Pursuit of Less book where he explains what happens when you create ambiguity over who is doing what.

    I can’t remember how many teams I joined where people were trying to look busy instead of doing real work because no one knows how we are judged, because roles were not well defined.

    There is hope

    In football, the coach decides the formation. He benches someone if needed. And when the results are bad, he takes the hit.

    The referee makes sure the rules are followed. He enforces the framework and keeps the game fair.

    The players play. Senior or junior, doesn’t matter. They train, they execute, they improve. They’re judged on performance, not on how loudly they talk.

    That clarity makes the whole system stable.

    If the product owner acts like a coach, owning outcomes instead of hiding behind “shared accountability.” If the Scrum Master really acts like a referee, protecting the rules instead of redesigning the game every quarter. And if we, engineers, are simply allowed to focus on playing well.

    Then maybe there is hope.

    If you're designing systems like the ones discussed here, this toolbox might help.

    • Free email delivery

    The Software Architect Toolbox

    The set of diagram pieces you can use to create awesome architecture visuals. The library package is regularly updated. Every time I find a new artifact or draw one myself, I add it because I think you should have it in your arsenal.

    You're signing up to receive emails from Justified Code.