Brugge Blog

Can you get an elephant to dance? Large software teams usually have so much friction with them, thanks to all of the communication channels (or lack thereof) and internal integration to manage that it’s been a good dodge for managers or organizations who don’t want to think about agile processes. “That stuff has only been tested on small teams, and even then nothing has really been proven.”

Perhaps, but there are a lot of relevant insights in what the agile folks are doing, no matter what size your team is. Seven Agile Team Practices That Scale points out areas where you can do agile things without having to embrace a full-scale XP/Scrum/Crystal process. Shorten your iterations, be more focused on the short term deliverables than about laying out a grand plan, continuous integration, write executable tests.

Having lived through a large project, with upwards of 70 people working for over a year, and working with others to try to imbue some of these characteristics into the project, I can say that these are all valid points, and we got tremendous mileage out of them. Without a full suite of unit tests run every hour, and nightly releases to a shared server, I don’t know that we would have delivered anything, and we almost certainly would have felt more pain leading up to the first production release.

But I can also say that these are not at all easy to bring into a large team, and I wouldn’t say that the whole team shared in an agile spirit. People followed along by the rules, which perhaps is just as good in the end, but the project still has another year of active life at least, and maintaining these practices still takes constant attention.

I also wonder if taking on these practices piecemeal will take you along the path to a fuller and more complete agile environment, or if it will simply give you just enough benefit to call it good enough and stop. Bob Martin gave a talk on QA on Agile Teams at the local MadJUG last week, and when he told stories of teams who took their abysmal quality standards and turned themselves around by applying XP, I challenged him as to whether you had to be a shop that had hit bottom before you could turn yourself around. Is a place that is doing kind-of-good-enough with waterfall-ish methods, or half-hearted RUP practices going to have the desire to look for value in other practices when that means “change”, and “change” means “more work?” He agreed that is probably more of an addiction pattern of turnaround now, but I think that dynamic could change as some of the individual practices become more mainstream.

I think time can play a healthy role here, with the ideas of the agile community becoming less scary as they gain some life history to them. I agree with the claim that the practices that make up a model like XP add up in value to more than just the sum of their parts, that they amplify each other, but I think that that has always, and will always be the case. Software development is such an organic process that we are still coming to grips with the subtleties of all of the feedback loops going on. And once we hone in on something, like objects, it changes while we work with it. That’s what keeps me in the game.