Koichi Hirano's Weblog

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.

A few months ago, I read 37signals' book "Getting Real" and found it fascinating. Its smart methodology helps application developers decide on a vision for their product, while still offering the advantages of Agile Software Development.

Since then I have been applying their techniques to some of my projects and have found them extremely helpful. However, I have encountered some conflict between key points in Getting Real and Manifesto for Agile Software Development.

My question is— is it better to maintain the "Always Working Code" (in the sense of Manifesto for Agile Software Development) without going back to the mock-up stage? Or is it better to halt the "Always Working Code" and go back to the mock-up stage, or even the vision definition stage (which is the origin of mock-ups in Getting Real? I have been at a loss as to how to resolve these conflicting ideas. Getting Real is really smart in the way that in the development process it avoids non-essential codes and features that go beyond a product's vision. For example, it states "Hand-written UI as a mirror of the vision, then move onto its mockups, followed by making the html/css work." That way, when you code, you cannot implement anything which does not reflect the product vision.

However, as I coded, I would often have thoughts such as "Oh, an interface that would make the app work more smoothly is missing here." So, the hand-written UI turned out to be imperfect (as always). In these cases, I generally tended to continue coding, i.e. I would add the missing UI in the coding process. Soon or later, however, I would find that the added UI was not really clean and pretty or it had too many features. Then I would think "Oh no.... I am contaminating the app and it is no longer Getting-Real-ish!"

In the spirit of Agile Development Manifesto's "Always Working Software" strategy, I did the right thing by adding more coding. At the same time, I was not able to stay true to the simplicity of Getting Real's approach because I was over-coding beyond the mock-ups that were supposed to be the mirror of the product's vision. I could have stopped coding the always-working-software by going back to the mock-up process to add the missing UI.

After some experimentation, I discovered that to stop coding and go back to the previous mock-up process to complete the UI worked much better than continuing coding without having the missing UI's mock-up. This not only forced me to spend more time thinking about how to convert the vision into UIs, but it also made me interact with my teammates and potential users while showing the added mock-up. This may not be necessary for die-hard Getting-Real folks, but I found it useful.

If you have felt similarly conflicted on this issue, I would love to hear from you about how you resolved it!