The moment we were all waiting for - Scott Ambler. Ok, that's an exaggeration. I've read his articles, listened to webcasts, read some of his books. I really was looking forward to seeing him in person.

His talk was entitled Agile Model Driven Development, but he covered a lot more along the way to that topic. His view of Agile is very pragmatic. He took a few swipes at the dogmatics, which was good, because I could see where he was coming from, and I often find myself on the highway to hell, um, I mean, the religious aspects of Agile. His exaggerated lack of respect for the general tone on some agile mailing lists definitely helped remind me of what it is we are trying to achieve. I think the reason why I wasn't offended was because he pretty much attacked all of the sacred cows in our industry - it was very South Park in that way... :)

I took a boatload of notes, so I'll summarize the highlights:

There was much more, but I think I am heading past attributing and into stealing his content, so I'll just leave it there. If you ever have the opportunity to see him speak, DO NOT miss it. I think when you look at those currently practicing the art of software development, he's one of the 3 most relevant people (at least to me) right now. [The others would be Joel Spolsky, who might be falling a little and Steve McConnell, who is always that much needed voice of reason]

The first talk I attended on Wednesday was Chris Armstrong's presentation on Agile Enterprise Architecture. I'm going to have to be honest - he started with a 10 minute rehashing of the Agile Manifesto, in his own thinking, and for me it went down hill from there. He is one of those delusional folks that thinks RUP can be Agile (anything with distinct phases for the different activities (requirements/design/coding/testing) is NOT agile). I just couldn't get over the fundamental difference there, and his constant reference to such BIG PROCESS things like TOGAF and IEEE processes didn't help. For an old-school architect, what he was saying was indeed agile, but it wasn't the kind of agile I was expecting. My friend and coworker Jim Patula (no blog) found him to be a half-way decent, so it could just be me.

There were two useful points he made, that I agree with completely - Agile is about minimizing rework (probably more than just that - what about other wastes, but a good thing to keep in mind all the same), and "At the end of the day, Microsoft Project doesn't work".

The final presentation of the day yesterday was a Birds of a Feather group discussion about what was important to make an agile project succeed. It was lead by Chris Sims, who did an excellent job facilitating. I don't know that I necessarily learned anything, about agile, but I did learn another way to give a retrospective, which in many ways was what Chris led. Going around the room and giving everyone a turn to mention something (after having them write up a list) seems like it would be very empowering to those who often don't speak up - I'm definitely going to give it a try the next time I facilitate a retrospective.

If you're keeping track of fads, Scrum and 2 week iterations are the most popular way for people to do agile, at least according to the show of hands...

I have spent my whole career wearing multiple hats, probably mostly because of ADD or something. I do tend to get bored if I'm not doing a wide variety of things, no matter what the reason. I've been lead developer, technical support, network engineer, database administrator, product manager, business analyst, build manager, installation developer, and probably other roles. I'm not saying this for the ego stroking, but to point out that there are real world examples of generalizing specialists, and I firmly agree that it is a good thing.

Lately I've been doing a lot of installation, build, and source control work. It fits in well with my other role of leading/mentoring, because it can be interrupted fairly easily (unlike, say, trying to figure out the subleties of fixing some problems with getting NHibernate and our crappy legacy data model to play together nicely, which is the work I probably should be doing - fortunately, there are some very talented people on the team dealing with that problem (although I do get sucked in to that, too) so I can focus on helping everyone else). Since I've been reading and exploring agile development, I've come across a lot of very good resources, which I either have shared or plan to share via this blog. We've finally hit the point where the rubber hits the road - our team has embarked on using Scrum (not very well at the moment - I thought you could just implement it little by little, and while its helping keep things on track than the chaos we used to have, it isn't giving us the full benefit it could - we're working now to correct that...). Anyway, enough mental masturbation context setting...

One really awesome resource for Scrum, beyond the usual suspects, is Henrik Kniberg. His latest article on agile version control is exceptional. I had been contemplating branching for every story, and merging the story branch back into the trunk, in order to keep the trunk releasable. It aligns with one version control practice I have read about of a branch per feature, but a story is finer grained than that definition of feature, so trying to maintain that would have been a nightmare. Henrik's method is to have a branch for each Scrum team, and then merging finished stories into the trunk, which seems like MUCH less trouble. The one complication is trying to figure out what files should be merged into the trunk. I think we can accomplish this by using StarTeam Change Requests to manage what check-ins belong to each story, and migrating change requests up to the trunk.

One other thing that will make this us do is ensure that stories are independent, and our code is properly broken into classes with a single responsibility each. Otherwise, this will still be hard to manage. But that "pain" will decrease over time, as we get better at writing GOOD user stories and GOOD object-oriented code.