Since the beginning of the Highlander (vNext BDS) development cycle the team has been using Agile and at this point, it’s safe to say I’m still on the fence about it. The decision to use Agile wasn’t quick nor was it made on the first day of the project, rather it came after numerous discussions and actual training sessions with an Agile instructor/consultant. Now, I’m not blaming the consultant and in fact, if anything the instruction was useful for us to improve our development process for reasons unrelated to learning Agile. I believe there are projects which would/could benefit from a strictly Agile approach however, given our team size, the disparate skill sets our staff has, the size and complexity of the IDE I think we’re likely to have to reexamine and adapt our use of Agile which isn’t a surprise and I’m sure at least some people in the Agile community would say that that’s what Agile is all about.
Prior to this year I’d say our development process was a modified version of waterfall which has seen it’s ups and downs. One point I’d make though is that when there are changes in the engineering staff, the technology, the market, the business and the management is it fair to blame the process when things go wrong? I’ll be the first to admit our process can and needs further improvement and we’re committed to and actively working on those improvements today. In fact, I’ve blogged a lot about our development process much of which has evolved even since last year and not just because of our use of Agile.
Like most engineers my team has lots of ideas about how things could be improved and in many cases those ideas are acted upon independently and our process incrementally improves. Perhaps one of the best things to come from all the focus on Agile and XP is simply the fact it has gotten engineers actively interested in thinking about the development process. Of course, it hasn’t hurt that the discussion has been accompanied by lots of tools for things like unit testing and continuous integration which I believe really helps drive engineering interest.
It’s interesting, I think most of the process improvements our team has enjoyed this past year occurred organically driven, not by management, but by individual engineers with a desire to utilize the maturing set of tools that are available today. I believe one critical turning point was our single minded focus on quality for the BDS 2006 release. I believe the release itself was high quality but since November of last year we’ve released at least seven updates more than triple what we normally ship. It’s this same desire to ship quality code that has fueled much of the process changes we’ve put in place in the past 12 months.
I haven’t really talked about why I’m on the fence about Agile and at some point I’ll fill in the blanks but one thing is clear, IMO the BDS development team is actively moving in the right direction.