Good Judgment is Agile

a quip from the agile usability forum…

“But I still think that, in the early stages of UI design, in a project where the UI is critical, getting a usable paper prototype, as verified by user testing, is significant progress.”

as an agilist, i would agree.

i tend to run parallel tracks during initial development based on the project specifics. once i have gathered enough requirement details to have a good overview of where we need to go, i might begin some specialized “research” tracks, a.k.a. “spikes”, even as i may be gathering more requirements and building more of the object model. the overlapping activities may be any of these:

  • requirements workshop
  • a spike to work out technical architecture
  • a spike to work out User Experience issues
  • doing anything else in parallel that helps to reduce risk
    • risk of missing important requirement details
    • risk of producing an unusable app
    • risk of producing a non-performant app

The challenge is knowing when to do these sorts of things, and not allowing any single “prong” of the attack to get too far or too deep compared to the others. The purpose being:

  • you often get diminishing returns, you just need to investigate enough to get the 80% mark (for example)
  • you don’t want to waste effort on something that turns out to be obviated by something you discover in another track

It may help you to understand I have a few very closely-held tenets about software development:

  • The key to development is separation of concerns
    • the core is the problem domain built to support the requirements.
    • get this wrong, nothing else in the app matters. nothing.
      • not the UI/UX.
      • not the 5th normal form DB.
      • not the worlds most articulate UML models.
      • not the worlds best cruise-controlled, TDD, 100% test coverage,
      • not the best joshua bloch-/steve mcconnel-blessed code.
    • this core generally transcends UI, database, and even the language chosen to code the app. In other words, the “problem domain” reflects the relatively stable “business” world. I know it sounds trite, but despite all our wonderful software advances from green screen to now, the world of mortgage/insurance/banking has changed little, fundamentally, or relatively.
      • the app is all about the “business” needs
      • the User Experience/UI is a separate thing
      • The persistence is a separate thing
  • Carefully orchestrating the various tasks in parallel using agile approaches that hold dear doing the “best thing possible” given the business & development circumstances, constantly adjusting in a smart way.

it is about understanding risks, managing them, and using the elusive stratagem known as “good judgment.”