Iterate, Iterate, Iterate—Thoughts On Agile Design

Over the next several days, I’m going to put out a series of posts on application design in an Agile environment. There are a couple of reasons why I want to do this; the biggest one is that I’d like to sort out these issues in my own mind. Aside from that, in my experience working for companies which emphasized being “agile” or following capital-A Agile practices, the term “agile” was used as a crutch to avoid making hard decisions. As a result, among companies which do Agile As She Is Practiced, there tends not to be much time for design—there’s time for grooming, planning, development, and retrospectives, but design doesn’t belong in any of those areas.

When I talk about “design” here, I’m talking about something more fundamental than how to implement a single story; individual stories require design time to figure out the best way to fit new (or modified) code in a current framework, and that design time usually gets baked into grooming and development. Instead, the “design” on my mind is that fundamental, architectural design (either within one system or across systems) which manifests itself in clean, understandable code; a comprehensible database layout which performs well and scales to business needs; and relatively few painful parts of the code that nobody ever wants to touch or look at because of how complex and fragile those pieces of code are. This kind of design takes time, a deep understanding of the business, and foresight—all things upon which Agile As She Is Practiced frowns.

I’ve already used the term “Agile As She Is Practiced” twice, so I think I should explain the term; when I use this term, I’m being slightly condescending, but I want to differentiate the idea of Agile from its typical implementation. Yes, there are some companies which do Agile right, and I’m sure it’s unicorns and rainbows over there; for most of us, however, we have different people with different ideas of what it means to be “agile” in development terms, and some of those ideas are (to be polite) somewhat lacking in perspicacity. Some people will take “agile” to mean “no more documentation” or “no design” or “no long-term planning.” The short-sighted and lazy among us may rejoice in this, at least until they code themselves into a corner and end up forced to maintain terrible code.

With this series, my goal is to figure out how, at least in my mind, we can couple the benefits of Agile with the necessity of good design. I think the secret here is in my title: iterate, iterate, iterate. The core component of being Agile—as opposed simply to following Agile As She Is Practiced—is rapid evolution and shortening reaction times to stimuli. Keep reading and hopefully I’ll come up with something decent…

Advertisement