Introduction

Back in 2001, a small group of programmers launched a revolution in software engineering by publishing the Manifesto for Agile Software Development (commonly called the Agile Manifesto) [1] and, shortly thereafter, The Twelve Principles of Agile Software [2].

There are many lessons to be drawn from the Manifesto and its Principles. One of them is that we should favor lightweight processes that reduce managerial drag and trust motivated workers to decide how best to do their work.

With this lesson in mind, we should be moving toward ever simpler and lighter ways of structuring our workforces so they can respond quickly to change and become more effective at their tasks.

Instead, we have an ever-expanding number of complicated frameworks that require elaborate administrative roles, checkpoints, best practices, reviews, and other hallmarks of the distant Waterfall era. When you examine these frameworks and see the sheer number of process-guardian roles, it’s natural to wonder if one goal of the frameworks is to smother an organization in bureaucracy.

Unsurprisingly, any bureaucracy tasked with reorganizing itself will likely create a derivative bureaucracy. After all, as the saying goes, everything looks like a nail when all you have is a hammer. If bureaucracy is the tool that a system has, then solutions look like different forms of bureaucracy. This mentality may be why frameworks with layers of administrators are popular in bureaucratic systems. We’re only human, and it’s natural that we should stick to what we know.

The Manifesto and its Principles heralded a brighter future that still seems distant all these decades later. Indeed, about sixty percent of Agile teams report difficulties with command-and-control management hierarchies above them [3]. From these issues comes a question:

What has gone wrong?

For the full article, please see The Bureaucratization of Agile – Why Bureaucratic Software Environments Aren’t Agile