One of the great things about being a parent is that you have an excuse to re-read some classic books. My five year old and I have been reading The Little Prince, and the story of the Lamp Lighter reminded of a common problem teams have with organizational inertia when trying to transition to agile software development.

For those who haven't read the story, or who don't recall the details, the Little Prince relates the story of his journey to various planets. One one planet he encounters a Lamp Lighter who lights and extinguishes a lamp every minute, not having any time to rest. When the Little Prince asks how this absurd situation came to be, the Lamp Lighter discussed this with the Little Prince:

"Orders are orders..." "It's a terrible job I have. It used to be reasonable enough. I put the lamp out mornings, and lit it after dark. I had the rest of the day for my own affairs and the rest of the night for sleeping." 

"And since then orders have changed?" 

"Orders haven't changed," the Lamp Lighter said. "That's just the trouble! Year by tear the planet is turning faster and faster, and the orders haven't changed!"

This is a very apt metaphor for many teams which are trying to adopt agile without re-examining their entire application lifecycle. The team may be developing using good technical practices, but the requirements management policies is too heavy weight to keep the backlog populated, or the release management policies discourage frequent deployments, leading to code line policies that place a drag on the team. In addition to organizational resistance to change, some team members might also be using using development tools and practices that make in hard for other agile practice to work as week as they could.

It's important to remember a three things when you are trying to be more agile:

• Agile is a system wide change. Changing practices in one part of the development lifecycle will quickly reveal roadblock in other parts.
• It's important to periodically examine how well your team is doing. Iteration retrospectives are a an important part of improving how you work.
• When reviewing how you work,  the practices that are now problematic are not often not "bad" per-se, they just don't apply  to your current situation.

Jerry Weinberg makes a great point about old rules in his Quality Software Management: First-Order Measurement where he says:

Survival rules are not stupid; they are simply over generalizations of rules we once needed for survival. We don't want to simply throw them away. Survival rules can be transformed into less powerful forms, so that we can still use their wisdom without becoming incongruent. 

"Survival" sounds a bit strong until you consider that the motivation behind working a certain way is often a desire not to fail, and sometimes, "failing" is scarier when you fail when not following established practices. That's why applying techniques such as those in Agile Retrospectives: Making Good Teams Great can make it easier for teams to consider how they can improve.

Standards and conventions ("orders") can be helpful to working effectively, but it's important to review those orders from time to time to see if they still apply.