Agile Bureaucracy: When Practices become Principles

In Good to Great Why Some Companies Make the Leap… and Others Don’t, Jim Collins writes that great organizations work to both preserve their core values and principles and then stimulate progress by adapting as needed over time (this book, written in 2001, still ranks in the top 200 books on Amazon). As with many things—easy to say, hard to do.

The Agile Manifesto was carefully worded to promote adaptability—to steer people away from rigid interpretations of the principles. Take the delivery principle for example, “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” It would have been much easier to write this principle as “Deliver working software every two weeks,” but that wording would lead people to rigidity (they get there on their own anyway).

Furthermore, what happens in too many organizations is that practices become static and then quietly elevated to the level of principle—something that can’t be violated. A good practice, “daily standups,” becomes bureaucratic when it is interpreted as “You must do daily standups, or else!” When questioned, the proponents of this newly crowned principle usually respond with “well, Joe Jones who wrote the book on Agile says so on page 48.” They lose track of why they are using the practice and it becomes a de facto standard rather than a guideline.

What happens is that slowly and surely, good practices become bad principles, or pseudo-principles, and comments like “you can’t do that because it’s against our company or team’s principles” become more frequent. Principles and values are a critical part of keeping individuals in organizations aligned and engaged, but the more pseudo-principles are piled on top of principles, the less and less organizations are able to adapt. This plethora of principles becomes barriers to change and adaptation. It’s often difficult to get rid of these pseudo-principles because some group within an organization feels strongly about them. Pseudo-principles sound reasonable on the surface, but the numbers of them become unwieldy. A couple may actually be ok, but dozens lead to problems.

Unfortunately, most pseudo-principles are not as easy to identify as the standup example above. And even good principles can be mis-applied. I once knew a team lead who was verbally belligerent to team members. His response to complaints was, “One of our team values is open and honest communications. I’m just being open and honest.” He had to be removed from the team.

Principles are invaluable to teams and organizations. One of the reasons the Agile movement has been so successful, over more than 10 years, has been its foundational principles expressed in the Agile Manifesto. However, principles can be abused and the rise of pseudo-principles leads to Agile bureaucracy that reduces the very adaptability and flexibility that the Agile movement was all about in the first place.


    1. Thank you, Jim, an excellent reminder to us all.

      I’ve even run into very basic practice vs principles issues with the Manifesto. Detractors love to harp on how it says “better ways of developing software” and “Working sofware over..” They then argue that this is clear evidence that Agile is only for software and has no place anywhere else.

      I admit to be frustrated a lot at the Snowbird team for using “Software” instead of “product” or some other broader term. At the same time I face these detractors or resistors head on promoting the spirit and passion of the Agile manifesto as more important then the exact words. After all, agile is about inspect an adapt. To me that means even the manifesto. Make it work for you, don’t let it be a barrier.

    2. Fredrik says:

      Good points Jim. For Scrum, the sprint retrospective is a good opportunity for every team member to bring up topics like, “I don’t think our daily scrum is valuable because…”. Ideally the team should inspect and adapt their process accordingly.
      Also I suspect that many organizations are tempted to modify the rules of Scrum before they have tried them. e.g. “where not going to have daily standups because our product owner cannot be available every day”. This has the risk of hiding the true cause of a problem (the PO not being present) which is what you should focus on. I’d say that before you deviate from the norm, make sure you fully understand the rules. They are there for a reason.

    3. I agree with these things you said, but you said this: “One of the reasons the Agile movement has been so successful, over more than 10 years,…” – and here comes the question which pops in my mind: How do you know, that the Agile movement is successful? What is the success of this movement?

      To make things clear: i think, this Agile movement is the more or less best answer to many questions in software development and other comparable problems. But how do we know, that there is an success and not playing the old game under a new brand. Its easy to say “we are agile” … and so i am not sure, that we can talk about an success for now.

      That’s why i think that we are more in the beginning than in the middle of something. And i think, that it does NOT matter much if you are doing scrum or kanban or something else. The process does not make any difference, if you understand the agile principles. And if you don’t understand it, the process does not help anyway. So maybe we are successful in teaching the process, but failing much more often in creating understanding.

      Maybe the only way is not to teach scrum or kanban or any process… if a team does understand the agile principles, the will learn how to do it.

    4. Hello Jim,

      This post is great! I have translated it into french :
      Bureaucratie Agile – Quand les Pratiques deviennent des Principes


    Speak Your Mind