Daily Common Sense

Complacency is the enemy of product development, but it's in our nature to seek it in our lives and our work. This is reflected in the processes we traditionally use to make things:

• Document everything out up front so we don't have to worry so much about it later.
• Schedule out all the work that needs to be done to insure that we know what the cost, schedule and scope is.
• Implement process rules. If the rules are followed, everything will work out.

Agile addresses the first two clearly, but it is a danger with many agile adoptions to get too complacent about the practices. It's a natural law that complex things decay. Processes, machines and organizations break down all on their own. If there isn't constant attention paid to this, then things can get real bad.

One of my favorite Ken Schwaber phrases is "Scrum is about making things visible so you can make common sense decisions". We often view processes as doing more for us, maybe solving our problems. This certainly isn't the case with agile.

Examples of the practices being 'practiced', but something is wrong:

• We might be meeting everyday, but if there are no impediments being reported and the build is broken.
• The builds are stable, the Sprints are all successful, but the game is not fun.
• We're pair programming and writing unit tests, but the continuous integration server is showing errors half the time.

The list can go on. The main question is how do we build a culture where improvement is the consequence of visible problems everywhere in the organization?

The Agile Champion

Being the champion of using agile in your company can be a challenging, frustrating and rewarding experience. Too often the frustration is too much and the champion gives up, or worse, leaves the company. Some of these problems could have been avoided if the focus of the champion is on the people rather than on "agile".

One of the Agile Manifesto values is "Individuals and interactions over processes and tools". I originally took a more shallow view of this value to mean "agile practices over non-agile processes and tools". Later on I realized that the "processes" part could also include the agile label as well.

A champion is the first to be educated about agile practices. They are enthused. They see the light at the end of the tunnel of adopting the new practices. This is great, but the problem lies in how things go from there. Too many times the buy in of agile is harmed by the focus on the process over individuals. People resist change and when you tell them to change "because Scrum says to do it this way" you lose them. Agile gets labeled and resisted. The champion becomes more resisted and can be labeled as well. Their reward for trying to improve the way things are done is frustration.

A champion has to learn to be a coach. They have to communicate that the road of adopting agile is about constantly improving the product and how people work together one step at a time, and introduce some practices that can help them take steps on the road. They need to realize that there is no "light at end of the tunnel". It's all about making things brighter from day one and never stopping. The goal is about improving the product and the way we work together, not "being agile".