Agile Soup

OK obviously something happened to get me back into the blogosphere. That “something” is actually two things. First, I spent the whole summer hunched over my table saw building a fireplace and that project is finally done. I am proud of that sucker. I spent a lot of time on the phone with my dad figuring out what I was doing, but we made it happen and that room is damn toasty.
Second, as I recently mentioned, I went to the Higher Ed WebDev conference in Cincinnati. The conference itself wasn’t totally amazing or eye opening, but it did help re-enforce some motivators I had just stewing in my head. We will call it the catalyst.

We will also call these stewing ideas “Agile Soup.” Agile is a model for a software development life cycle. You might even call it a project management methodology. The old, most accepted method was called a Waterfall. There’s also an IBM version of waterfall called RUP, which is what I followed religiously for years. I recently started reading about these crazy developers though in California who were trashing the idea of requirements and actually developing on site with clients instead. Gone were requirements documents. In came user stories and use cases and note cards. It sounded like fairy tail land… until I started reading up on it. Agile sounded like it could be a legit model for small projects so I tried it.

Now I’m not only drinking Agile Kool-Aid, I’m serving up some Agile Soup. This article will serve as a quick intro on how Agile can be thought of as more than just an SDLC and how you can use the principles to run your whole business.

First off, let’s review the AGILE Manifesto. If you’re familiar with Agile, then you’ve seen this before:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

I love every part of that. That manifesto is sort of the creed that drives a software development life cycle, but nowhere in it do you see any detail about how exactly the process works. It’s minimalist. The actual Agile process (or at least the one I use, called SCRUM) involves prioritizing client needs, figuring out how many of these needs can be accomplished in a 2 week development “sprint,” and then delivering, regrouping, and re-prioritizing every 2 weeks until the client decides, “hey, this is good enough.” A colleague of mine at Ohio State, Beth Snapp developed her own version called “Rapid Iterative Development.” Her idea is very similar to SCRUM, where we have this software development paradigm that is based on quick, well coordinated, flexible delivery. It focuses on developing working software in small chunks rather than working on abstract documentation followed by long development periods. I like this quote:

The problem with abstractions (like reports and documents) is that they create illusions of agreement. A hundred people can read the same words, but … they’re imagining a hundred different things. That’s why you want to get to something real right away. – Rework

So the goal is to develop these small chunks rather than spend a bunch of time writing documentation and then disappearing into a cave for months building a monster. This way, you’ll be able to change direction easily. The more expensive it is to make a change, the less likely you are to make it. It’s also a lot easier to completely scrap everything you’ve done in a 2 week sprint than it would be to scrap an entire project. So if you screw up or miscommunicate something, you catch it before you become attached to it and you can scrap or change course before it’s too late. The concept is pretty simple, really.

My first light bulb moment piecing Agile into a business philosophy wasn’t really an “agile” moment at all. It came while listening to someone talk about the right approach to social media. His point was that you have to be authentic. These days people don’t value press releases as much as they value customer comments. A facebook or twitter account that is maintained on behalf of a company by a nameless, faceless PR firm or communications office will get exposed and ignored. But if Bill Gates or Steve Jobs get real, people will listen. So the idea is to embrace who you are as a company and be authentic if you want a successful social media campaign.

So I thought about that and I got comfortable with the fact that I’m a small web development freelance ringleader. Then I started reading the book Rework by Jason Fried and David Heinemeier Hansson and the light bulb really came on. The book is presented in a bunch of really short 2 or 3 page chapters. The chapter names have Agile oozing all over the place:

• Planning is guessing
• Ignore the details early on
• Good enough is fine
• Your estimates suck
• Make tiny decisions
• Speed changes everything

After reading that great book, listening to people tell me how being authentic is hot, and really embracing the Agile SDLC, I came up with my own Agile Soup… also known as the Home Base Web Solutions manifesto:

Fostering relationships over volume and efficiencies
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Personal attention over following protocols

OK two of those didn’t change. Get over it. I thought about it for a while and realized that I was just rewording the original Agile Manifesto. The end result is the same though. My business is unique. Each of my clients are unique. Every project I work on is unique. If I stay lean and focus my efforts on rapidly deploying software that meets my core requirements and continually improving both product and process, I can’t go wrong. If I’m focusing on building relationships and collaborating with clients to help their businesses grow rather than negotiating terms and conditions to put money in my pocket, I think everyone is better off because if my clients are successful and they like me, not only will they use me again, but they will recommend me to their friends.