Wednesday, July 16, 2008

About OneAgileTeam - Keepin' Agile Development real with Getting Real

Agile Software Development is a style of software development which has been gaining popularity. According to a former colleague, upwards of 10% of corporate software development projects in North America are now conducted this style. Agile Development (hereafter Agile) is to beat the long lasting development style called Water Fall Model (hereafter WF).

Suppose you want to build a dream house. With WF, you hire an architect who designs all the elements of the house . You then move onto the actual building stage (i.e. foundation -> framing -> plumbing/wiring -> walling -> flooring etc). Once you start, you are relatively locked in to the plans. You cannot abruptly change things and decide that a faucet should be installed in a completely different location. Well, you could, but it would be very costly. In this model, the longer things continue to be built, the more unexpectedly things may turn out. And it may not be at all like you imagined. Within the WF model, once a project is in motion, and the "water is flowing," you cannot really go back "upstream" (i.e. the design stage). Instead you must wait for the design to run it's course, and then pay for it. Once the project is in motion you don't have much control.

Agile however addresses the above problems. Agile developers always work with the client step-by-step from the design stage to the flooring installation. Agile developers in fact welcome changes to the plans so they can ultimately build a better home. They always try to show what the actual finished product will be like along the way while working, or in the form of a mock-up made at least to scale. This way the client can confirm what the finished product will look like before it is completed. In a nutshell, Agile's strength is that it permits change derived from mutual conversation with clients throughout the development process.

One very specific and opinionated approach of applying Agile Software Development to create web products efficiently is called Getting Real. Created by Chicago-based company 37signals, Getting Real utilizes Agile Development to build the best web product possible. One of the greatest challenges to developing a successful web product is the fact that you have not met your potential users in person. Also, potential users are quite diverse in their needs and internet savvy. So, you need to explore what would be the best features and interface for millions of different users, which is pretty challenging to do at the beginning of a project. WF doesn't work here because it requires a plan for the product to be set before the construction can begin. But what is really needed is exploration.

Getting Real is quite agile, in the sense that you can create a product step by step, and in each step you observe customer behavior and take into account client feedback. From there you can adjust the product to implement the most recent feedback. If it doesn't work, you can easily go back to the previous step. This rewinding in product development can be confusing to clients at times, but this can be avoided if the changes (or "tweaks" as we call them) are small enough.

37signals' project management product, Basecamp, which I recently started using for coordinating this blogging project with my proof reader Emily (whom I utilize as I am not a native English speaker), was developed with Getting Real. 37signals created Basecamp five years ago. Currently, they have more than 2 million users, and they still continue to change and tweak the product little by little fairly frequently (sometimes weekly, or even daily). It seems that Emily understood how to use Basecamp almost instantaneously. In fact, she did not even ask me any questions about how to use it, and she figured out very quickly what can and cannot be done with the built-in wiki called Writeboard. For several reasons, we are drafting the actual blog posts on Google Docs and doing the rest (like To-Do management and messaging) on Basecamp. The point I am making is not that that there is anything wrong with Writeboard, but that she had to spend only a few minutes exploring Basecamp to grasp what it could and couldn't do. From there it was easy to make a decision—that we should just use Google Docs for editing my blog drafts. It is very easy to understand and therefore made it very quick to reach a decision. We did not have to spend hours figuring out how to do this and that. 37signals has spent five Getting Real years slowly crafting Basecamp in to the outstanding work of art that it is, and as a result it is easy to use, intuitive, and requires no manuals or training.

While Agile development may seem like a logical model, it is actually rare to see it implemented in the real world. I'm sure you have experienced this already. For example, when you call customer service at a company to complain about something, the customer service reps seem like they are listening to your concerns, but they are probably just being polite. If the service reps were working in an agile manner on a web product, they would need to report your complaint to their boss, who would then compile a list of all complaints and once a month report to the VP of Engineering. The VP of Engineering would then prioritize the complaints and pass the highest priority items on to the developers. In this case there are several steps or filters that your complaint must pass through to go from your lips to the ears of the guys actually developing the project. Although the developers try to be agile, there are too many steps in the process. This is what happens in most businesses. Getting Real, however recognizes this problem and recommends doing everything as a very small team. For example a team consisting of myself acting both as a core developer and customer support staff at the same time so as to avoid unnecessary steps in between input and action.

So my company OneAgileTeam remains small, and applies the Getting Real approach wherever applicable. We strive to fully understand both identified and unidentified business needs and fulfill them in the most agile, simple and timely manner possible. And by timely, I mean a few hours to a few weeks at the most. This is the main objective at OneAgileTeam.

No comments:

Post a Comment