That last part is crucial. I gave up trying to micromanage projects and I gave up trying to portray some sort of corporate atmosphere on my website and embraced the new AGILE and family oriented business model. AGILE is more than a word. It’s more than a project management methodology. It’s how we do business. I think I’ve gushed enough about this recently so I’ll leave it at that.

Since I am a football fan though and now is the time of year that coaches are either fired or rained with praise, I have been hearing a lot of quotes about programs being run like a family. When a player is recruited to Ohio State, he is part of the OSU family and that family actually extends beyond the football field. I work for OSU and I feel part of it. At Home Base I’m trying to instill the same values. So our newest installment of awesomeness is what we call the Sunday Code Marathons. Brittany and I try to cook a great meal every Sunday for clients and employees alike and we all sit around and code and work on projects for a few hours… or all night… or for 10 minutes before we start playing some board games or watching football. It’s great. We can all sort of feel the excitement and energy of the company being on the move. We have some great clients right now and some great projects and every week we are introduced with new, fun challenges that we are ready to tackle together.

2010 was a great year that ended on an especially high note. I am very optimistic that 2011 will be even better. We are all looking forward to churning out really cool projects like a well oiled machine. Happy New Year!

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.

Rework

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

Hamid Shojaee covers all the SCRUM bases: product back logs, release back logs, team roles, burndown charts, and more.