Have the Orders Changed?
One of the great things about being a parent is that you have an excuse to re-read some classic books. When my son was five years old, he and I read The Little Prince. The story of the Lamp Lighter brought to mind a common problem teams have with organizational inertia when trying to transition to agile software development.
For those who haven’t read , or don’t recall the book, 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 (legacy) requirements management process is too heavy weight to keep the backlog populated. The (legacy) release management policies might 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, which, while comfortable and routine, make it hard for other agile practice to work as well as they could.
In short, even though the context has changed, the organization and team may still be following old orders. But if you are trying the be agile, you need to act as if “the orders have changed.”
When you are trying to be more agile remember these three things:
- 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 periodically review those orders in light of your current context to see if they still apply.
This is an update from an article originally posted on Accidental Simplicity on March 10, 2012.