Wednesday, June 25, 2008

Getting Real First or Agile Development First?

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!

No comments:

Post a Comment