Modeling and Agile Development

Posted by Keith McMillan

March 5, 2008 | Leave a Comment

Daniel has an interesting post on his site, What To Fix, regarding his thoughts on the role of modeling in an agile project. We’re working with some of the same people currently, so I have some insight into his points.

On one hand, people say its all emergent — put a bunch of really smart people in a room with the Product Owner and fixed time-boxes and the conversation and code will follow along naturally. I don’t think there is any denying that it’s a true statement that software can emerge from shared conversations about problems.

On the other hand, there’s the role of modeling in software development. Diagrams seem to help people understand and talk about things better, so couldn’t they be part of a conversation as well?

[Read the whole post]

I’ve had some of the same misgivings, and the same thoughts. I think that modeling in an agile environment serves more than one master. First, it allows us to visually organize our thoughts. Visual models are a very information-rich way of communicating information, you can put a lot of details into diagrams if you know the language. They’re a very efficient way to communicate thoughts.

The second thing that modeling in an agile environment does is allows us to capture details to guide those who come after us on the project, or who don’t have the benefit of working collaboratively. Yes, yes, I know that in agile, we’re supposed to collaborate and work together, preferably all in the same place. That’s sadly not always possible, and until we learn time travel, people who start on the project next month, next year, or next decade won’t have the benefit of having been there when the conversation takes place.

Finally, recording decisions allows us to not have the same discussion over again. I’ve worked projects where we ask ourselves 3 months in, “Now, I remember why we decided that, but why?” This was in projects where we had models, and I can only imagine the types of revisits we’d have if we didn’t document anything…

I’m also convinced, as Daniel is, that you’re kidding yourself if you think people aren’t doing this in their heads already. What’s the harm in making that easier by putting it in the open?

I can see how these structural concepts are captured and modeled in some teams — I watch it while they are estimating. Somebody says “What size is User Story X?” and then the developers do it. They sit there, staring up into the air, while they review all of these design details in their head. I can hear them muttering to themselves things like “Yeah, is that a buffered array or a flat structure?” and such. Sometimes things like “Yep. We could do that if we used the paging mechanism for that other module”

So, how do we reconcile this impasse? I don’t think my answer is that far from the spirit and intent of agile modeling, frankly. The fundamental tenets of agile are: don’t do work you don’t need to do, and don’t do work before you need to do it. We can reconcile this with modeling. Modeling as details emerge from collaborative conversations fits the bill nicely. You don’t commit the cardinal sin of Big Design Up Front (BDUF) this way. We’ll call this emergent modeling.

Assuming you see merit in this position, and haven’t already dismissed me as some sort of anti-agile lunatic, how do you model? Well, you can capture your models using a white board, and erase it when all present are satisfied that they understand, if that’s appropriate for your project. If you choose to take this approach, then you need to understand what you give up: anyone who isn’t present doesn’t get to play. If you want to allow space and/or time separated individuals to play along with the development effort, then perhaps it’s a good idea to capture what your decisions are. As an added bonus, not everyone has to have a perfect memory of what you decided when you discuss it next. The level of detail and the tool you use to model should be selected based on the needs of your project.

By practicing emergent modeling we defer the decisions until it’s time to make them, and we capture the details that arise out of the conversations, rather than investing a bunch of time in designing up front. By capturing the decisions as they are made, with an appropriate level of detail, we don’t over-invest in a model that has more detail than we need.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.