Well, to start, Josh Holmeshas said he’ll shave his head if Technorati has indexed at least 500 codemash blog posts by the end of the show this evening. So, this will bring him 0.2% closer to that…

I didn’t make it to CodeMashquite as early as I’d have liked, but I did have the opportunity to use the water park with my family for a little while, and then to meet up with Scott Guthrieand several others for dinner last night. One of the topics of conversation was about Agile methodologies, and how it seems like one of the common themes that all developers at the show, regardless of the language they use. Everyone loves Agile. But of course, who doesn’t want to be “Agile”? It’s hardly desirable to be “clumsy” or “awkward”, which would seem to be the alternatives. I understand the politically correct term for “not agile” as it relates to software development is “orchestrated.” Personally, I think there are many places where agile methods (and by this I mean no design, just write tests and code based on user stories, minimal meetings, close business interaction) excel, but there are also some areas where high level design is going to be necessary. For instance, when developing a framework on which many other applications will be built, it’s impossible to have all of those future customers involved in the process, so the only two options available are to let the developers run amok or to actually do some formal design. In this case, I think formal design makes a lot of sense.

Related to this in our dinner discussion, others described situations where agile techniques were used, and eventually a milestone was achieved, but in hindsight it was clear that they team had taken “the long way around” to get there. With a little forethought (and perhaps 20/20 hindsight), it might have been possible to achieve the end state with much less interim effort. The problem here is that without a clear design, the flexibility (and agility) afforded by agile methods can result in taking a path that is much longer than the shortest one, which led me to quip that the project team might say “We’re not sure where we’re going, but we’re making great time!” An option that was discussed to perhaps mitigate this effect is to let the dev team be agile, but have someone who is designated as the (and here the moniker is subject to change – these are my own) scout or navigator, whose task is to look ahead at where the team is heading now, and where the project needs to end up, and try to come back to the team during stand up meetings with some directions that can optimize the overall path to the destination.

Scott described one scenario in Ohio terms: “We were trying to get to Cincinnati from Toledo, and we ended up going through Cleveland. We should have seen that we could have gone straight through Columbus and saved ourselves a lot of travel time.” Having a navigator might help prevent “taking the scenic route” on Agile projects.