I’m a big fan of agile. I’ve long been convinced that the agile movement truly is uncovering ways to do software better. It’s revolutionizing the way that companies approach software. At 8th Light we’re using Agile to help us deliver the highest quality software possible to our clients. I wonder how something can be classified as un-agile?
Removing the religion from software development. I had feared those words. I’d often been tempted to use them myself, but something told me I shouldn’t. As I sat in a planning game on a previous job, I heard the words. They still make me cringe. “We can’t do it that way. That’s not Agile.”
What is Agile anyway?
Can Agile be measured? Can one thing really be more agile than another? If I had a yardstick and I was going to measure Agile, what would the markings be along the stick? What units would I use? ‘Points’ has already been taken, so maybe I should invent a new unit. I’ll call it the Agl.
For every hour of pair programming an organization does it gets 10 Agls. Unit tests are worth 1 Agl each. Acceptance tests get 100 Agls.
I’d use negative values too. For every page of documentation written, an organization looses 40 Agls, but the group running in iterations gets 1000 Agls. One week iterations are worth 2000 Agls.
The Problem
The problem is that as a development organization adopts Agile and buys into various processes and practices, the temptation quickly grows to covert that development process into religion. “We can’t do code reviews, that’s not Agile!” “We don’t write documents, that’s not Agile!”
What may start as genuine excitement and passion can quickly become religious dogma when those involved in the process lose sight of why they do what they do. Let me say that while I am a religious guy, I hate religion.
Religion, to me, means action without thought: doing or saying something because that is the thing that you are supposed to say or do. I’d rather call what I have faith. Faith comes from beliefs or values held and turned into day-to-day living.
Since we are talking about religion, I thought I story from the Bible might be appropriate. Jesus and some friends were sitting down to eat when some super-religious folks showed up and started berating Jesus for letting his friends eat with dirty hands.
These religious-types had established an elaborate ceremony for washing hands that had very little to do with removing bacteria. Jesus comes down hard on these guys for exchanging true principles for religious dogma.
He responds by handing them a principle that does really matter. “Nothing outside a man can make him unclean by going into him. Rather, it is what comes out of a man that makes him unclean.”1
Here one of the most well-known religious leaders of all time shows his followers that it is the true principles that matter, not the religious practices or rules.
Agile is just a label
In software planning situations and day to day development we are faced with hundreds of little decisions about how to do our work:
- Should we throw this code out and start building the whole thing from scratch?
- Should we iteratively improve the code and slowly arrive at a better design?
- Do I write a test for this code?
- Should I pair with someone or just write this myself?
When making these decisions we need guidance, something to help us understand if one thing is better than another. “Agile” is not that thing. Agile is just the label put on a whole spectrum of practices. The guiding lights we need are principles.
Principles
Principles are the domain-specific set of beliefs that an organization has adopted. They reflect what the organization values. I think it’s possible that many organizations get swept up in the excitement and freedom of agile practices that they skip this critical step of establishing the their principles. Kent Beck lays out a set of principles2 for extreme programming:
- Baby Steps
- Failure
- Quality
- Redundancy
- Opportunity
- Flow
- Reflections
- Diversity
- Improvement
- Self-Similarity
- Mutual Benefit
- Economics
- Humanity
These principles help direct an organization when it is trying to figure out the how of software development. Whenever I’ve heard Kent speak, he always comes back to the principles and values behind the practices in extreme programming.
Uncle Bob has established a great set of principles that help us discuss and qualify designs. The Single Responsibility Principle, the Open-Closed Principle, the Don’t Repeat Yourself Principle3, and others are guiding lights for design decisions. These give teams concrete evaluators that keep design discussions productive and prevent them from deteriorating into contests of dogma.
Alistair Cockburn writes about 7 properties in Crystal Clear that can be translated into principles4:
- Frequent Delivery
- Reflective Improvement
- Osmotic Communication
- Personal Safety
- Focus
- East Access to Expert Users
- Automated Tests
- Configuration Management
- Frequent Integration
I don’t want to delve too deeply into these principles here, but an organization in the process of adopting agile should. Each of these manifesto-signing authors have explained these principles wonderfully in their books.
At issue in my planning meeting was whether or not to require a certain feature in a third party library for which we are shopping. At the time, we didn’t have a need for this feature, but we anticipated that it may show up an upcoming story. The person who spoke up saying “That’s Not Agile” was really referencing the XP value of simplicity. “Solve today’s problems today and tomorrow’s problems tomorrow.”3
This would suggest that one shouldn’t take on additional complexity until it is needed. However, when purchasing a third party library, perhaps the principle of Economics might suggest that paying a little more for this library today will save a lot of time and money later and potentially avoid purchasing the library twice.
Which is the right decision? I don’t know, but after having agreed on the principles that guide our decisions, we can have the conversations around those principles and pick a way forward.
An organization transitioning to some flavor of agile ought to first clarify what its organization’s principles are. Read Beck or Martin or Cockburn or your favorite Agile author and choose the principles that you want to live by. Second, make the principles visible. Put them up on a wall. Have meetings where team members present a principle. Refer to them as you pair. Write about them, read about them, explore them.
At 8th Light, we’ve put them on our website. Revisit them when starting a new project. If you are working with a consultant, ask them to take you through a values and principles exercise. If you are a consultant, please don’t miss this critical part of transitioning to Agile.
Making your principles part of the every day vernacular of your organization will take you to a place where design and planning discussions stay productive and you’ll hopefully never hear “That’s not Agile!” again.
End Notes:
- Mark 7:1-16
- Beck, Kent. Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional. 2004.
- Martin, Robert C. Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. 2002.
- Cockburn, Alistar. Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley Professional. 2004.