Full text of video:
Do your Agile practices feel like a leash instead of a launchpad?
I’ve observed a problem when I visit my clients: I meet developers who tell me they’ve lost a sense of autonomy. They say “Scrum feels like micromanagement” or “ever since we started practicing Kanban, it feels like managers have taken control of everything we do.” If you’re feeling the same, something has gone very wrong. I’ll explain…
Let’s begin by remembering a few statements from the Manifesto for Agile Software Development — and I only bring it up because my clients do. Their developers say things like “I’ve been assigned to an Agile project, and it feels like I’m being micromanaged.” Because they associate this feeling with a broad concept called “Agile,” I’ll refer to the document that coined the term: “Agile.”
A few statements from agilemanifesto.org provide clues that something has gone wrong if developers feel that way:
We have come to value “Individuals & Interactions over processes and tools”
And the 5th, 9th, 11th, and 12th principles:
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
9. Continuous attention to technical excellence and good design enhances agility.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Those statements make it obvious, don’t they?
THE TEAM reflects on how to become more effective. Not MANAGERS – the team! Attention to technical excellence – not management excellence – TECHNICAL EXCELLENCE! And the BEST outcomes emerge from SELF-ORGANIZING TEAMS – not micromanaged teams!
Let’s think about the business world through the 90s and into early 2001 when that document was written. Particularly in the software industry:
The Fortune 50 companies included General Motors, Walmart, oil companies, Pepsi, banks, military contractors, manufacturers. Many were founded around the turn of the 20th century. Very few of those companies were tech startups – but a few, including Hewlett Packard, then later Dell, Compaq, Motorola, Cisco.
Tech startups did exist though: Atari, Apple, Microsoft, Borland. Then later: Amazon, Netscape, Napster, Google.
The contrast between those companies couldn’t have been more stark: Big enterprises with strict bureaucracies and long chains of hierarchical command. And scrappy startups led by software gurus – a new breed of entrepreneur.
It was in that contrast the Manifesto for Agile Software Development was written.
The established companies were starting to consume not only the tech products and services, but the developers as well. Companies like Home Depot, Texaco, and Kroger were hiring developers and webmasters. They approached the management of software like they approached manufacturing and supply chain logistics: command, control, piecework, specialization, centralized decision-making, carrot and stick management by objective.
For anyone interested in the creative field of software development – it was a dehumanizing transition. I experienced it in 2006 when I decided to end a 14-year stretch of web development freelancing and took a job in a state-funded college – a large government bureaucracy. I did so because I wanted to learn how to make enterprise software – but what I discovered was a bureaucratic nightmare.
That’s a huge reason the Agile manifesto and ideas like Scrum, Crystal, and OpenAgile resonated with me. Because I saw, in those ideas, a way forward for enterprises. The nightmarish bureaucracy could be disrupted by Scrum — to allow greater autonomy for developers. It was like an uprising — not because I wanted to overthrow the establishment, but because I knew software quality and business results were limited by the micromanaging nature of the establishment enterprises.
But that’s not the whole story. There are some really rough edges on this problem. Like this one:
Let’s acknowledge there’s a natural tension between transparency and scrutiny; and between autonomy and anarchy.
Let’s consider Scrum for a minute. The design of Scrum intends to disrupt centralized decision-making and common bureaucracy. It intends for a group of developers to self-organize around business goals, to imagine and deliver solutions for the business and for end users, to strive for mastery and quality – and to do this in partnership with key stakeholders. A Scrum environment should feel liberating for developers.
Scrum and other Agile practices were originally designed to push authority and autonomy toward the development team, not pull it away. But the deal is: the work of the team must be as transparent as possible.
Why transparent? Because transparency increases the quality of decision-making. When everyone involved can see what’s going on and can be open about the challenges they face, then rapid feedback can increase the quality of decisions. (Just imagine: if you hide information from people, information they need to make decisions, then you can expect bad decisions!)
So the arrangement proposed by Scrum is a simple one: self-managing teams are supported; transparency is expected.
And this can feel really awkward! Transparency can feel like scrutiny. And, to be honest, there’s a fine line. Developers who once "just built things" may find themselves explaining every move. Daily Scrums might morph into status reporting. Instead of owning outcomes, developers might feel watched. A line is crossed when transparency leads to surveillance instead of empowerment.
And some workplaces are just badly managed – truly – and developers feel scrutinized because their managers are truly in the weeds, measuring every little movement, penalizing every mistake. It happens.
So consider your own context: What’s Really Happening? Perhaps one of two possibilities:
Developers unused to regular demos and feedback can feel exposed. That’s normal at first. Visibility is uncomfortable at first — but it’s necessary for team growth and shared learning.
Managers might overreach. Scrum might be hijacked for surveillance in disguise.
To conclude: when I consult with my clients who are trying Scrum, I emphasize that Scrum’s design empowers teams. I teach managers to observe, not control; and to measure outcomes, not activity.
Share this post