8th Light Blog

At Agile 2007, we put on a workshop called RailsFest. The original intent was to provide a one-day session that conference attendees could visit to get an opportunity to work on a Ruby on Rails project. What that project was to be, we didn’t really know. In the way that things sometimes work out, we ended up with the opportunity to work all week with a non-profit organization that has touched more lives than most of us ever will.

The organization that we were working with is called Mano a Mano. Their mission is to “improve the health and well-being of impoverished Bolivians.” Segundo Velasquez, president of Mano a Mano, was our on-site customer, and I was lucky enough to work with him for part of the week. At first, he was a little unsure of his role in the process, but by the end of the first afternoon he had become comfortable in expressing what he wanted the software to be. It was a lot of fun watching Segundo learn about and adapt to the approach that we were taking in creating software for his organization.

Mano a Mano works in a very different way than most other charity organizations. Though they provide aid to the economic poor in Bolivia, it is not a free handout. The intent of the whole process is to bootstrap poor communities. Segundo told me of a specific project where they were able to increase the per capita income by 100% (from $150 to $300) the first year. By helping to provide the basic necessities that we often take for granted (e.g. potable water, roads to allow for the transportation of goods and people, etc.), the citizens were able to stop worrying about these basic things and concentrate on improving the lives of themselves, their families and their community.

Though RailsFest ended last Friday, there is still work to be done. If you are interested in giving back a little bit through your craft, please drop me a line at jim@8thlight.com.

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.”

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 though, how exactly something can be classified as un-agile?

What is Agile anyway? Can it 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.

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 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 the 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.

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. Those guiding lights we need are 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 principles for extreme programming. Baby Steps, Failure, Quality, Redundancy, Opportunity, Flow, Reflections, Diversity, Improvement, Self-Similarity, Mutual Benefit, Economics, and Humanity(2) 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. UncleBob 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 Principle(3), 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 principles: Frequent Delivery, Reflective Improvement, Osmotic Communication, Personal Safety, Focus, East Access to Expert Users, Automated Tests, Configuration Management, and Frequent Integration (4). 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.”(2) 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:
1) Mark 7:1-16
2) Beck, Kent. Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional. 2004.
3) Martin, Robert C. Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. 2002.
4) Cockburn, Alistar. Crystal Clear: A Human-Powered Methodology for Small Teams Addison-Wesley Professional. 2004.

The most widespread and common greeting in the American culture is the handshake. Handshakes are shared between anyone meeting for the first time, to finalize a business deal, and to end a conversation. I spend a good deal of time around 2nd and 3rd generation Korean-Americans. In Korean culture, like many Asian cultures, the handshake is replaced by bowing. In these transitional immigrant generations, the bow and the handshake have been merged into one awkward action. I was recently walking through the reception line at the wedding of 2 second generation Korean-Americans and I went to greet the 1st generation parents. I was going to try to be respectful and offer a bow instead of a handshake, but just as I began to bend, a large hand was thrust out in front of me. I felt myself lucky that I didn’t end up with the guys finger in my nose.

One of the things I immediately noticed as I began working with the craftsmen at 8th Light is that everyday I walked into the office, every member of the team shook my hand. As each team member left for the day, he shook the hand of everyone who was left. I expect this on the first day, as you always shake hands with everyone on your first day. On the second day, I thought maybe they had all forgotten that they met me yesterday. As I realized that this would continue, It really made me start thinking.

As I went to work with another team for a little while I came to really miss the handshakes. I’d walk in the morning and maybe get an eyebrow flash from my teammates. A “Hello” would come if I was really lucky. I decided enough was enough, so I just started shaking hands. At first, I got some really weird looks and was left hanging a few times. The looks seem to ask “Why are you shaking my hand, we see each other every day.” But slowly it started to catch on. My teammates began to expect a handshake from me at the start and end of each day.

Here’s what I think these bookend handshakes do for a team. First, believe it or not, a handshake becomes an intimate gesture. It communicates genuine care and concern for each other. To me it’s a physical expression of the XP value of Humanity.

Second, it communicates respect. Sometimes design and project discussion can get very heated, especially if you are working with a passionate group of people. If your days begin and end with a handshake, everyday is bookended by a statement of mutual respect. There is a proverb that exhorts people to “Not let the sun go down on your anger.” That handshake is a way to let go any residual anger from the day and commit the next to dealing with each other with respect.

Third, It’s an honest statement about the hours you are working and the time you are putting in on the project. In a handshake-free environment, if I’ve had to leave the office early, I’d usually try to sneak out without anyone noticing. At the time I was in an office culture that promoted flexible hours, but you always felt like people were watching you to make sure you were still putting in your hours. I always put my time in, but because I sometimes played with my schedule quite a bit, I was always afraid that someone would perceive my time poorly. When an handshake begins and ends your day, you are being direct and up front about your time. You are communicating at the start of the day “I’m here, I’m ready to work” and at the end of the day “I’m gone, my day is over.” There are no apologies, no sneaking in or out, and no elaborate time-tracking system. Your teammates trust that you are working as much as you should be and you are not likely to try and cheat you company or your team out of your time week-to-week.

Try it in your team. It’s a morale boosting behavior that will cost a team nothing to implement, but will be one baby step to improving the strength and productivity of the team.