Development using Agile

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.

If you’re new to reading my blog check out my Zombie posts regarding our automated testing efforts and have a look at the video I posted of our R&D smoke test for BDS.

5 thoughts on “Development using Agile

  1. Interesting read.
    I wonder if you guys tried pair programming. If so, how did it go?
    I did that for some time a while back and I became so annoyed at having someone constantly next to me that I couldn’t concentrate.
    I found out that feeling some guy breathing on your arm while you type some code is /very/ annoying!
    I Decided to end it before loosing all my marbles. And I probably could never get any work done if I was paired with one of the cute girls!

  2. Hi Eric,
    I don’t know of anyone on the Delphi team who has tried pair programming. I’ll agree that it seems like an odd concept. I have seen a few people from the JBuilder team use it but I haven’t discussed their outcome nor how they felt it worked out.
    -Steve

  3. Steve,
    The company I worked for adopted XP a couple years ago. We are still process incrementally improving and still are not Agile. Your ‘updates’ do not point to ‘flaws’ but to the need of being Agile in your process.
    Pair programming takes a while to get use to… but is well worth it. Can you imagine going on vacation… you don’t get a call from the boss and your boss says ‘sure, any time you like’ when you submit a vacation request. Your skills improve and you learn even from the ‘junior’ geeks. But to get the full effect of pairing, ALL of the development staff need to ‘tear down the walls’ and create a work center bullpen.
    Don’t give up on XP. There is a delay in the effort to result. It may take a few years until you see the big gains in your product line.

  4. Hi John,
    Thanks for the comment. I’m not giving up on Agile and like you we have work to do to improve our process and use of the Agile methodology. There are things that I think are good but there are trade offs too and the team is struggling a bit to figure out exactly how things should work.
    -Steve

  5. I’m *very* excited by the news that you are starting into agile. I am convinced that the more you guys are using unit tests, the easier it will be for us to use them and testing will get easier for my team.
    Go CodeGear!

Comments are closed.