Agile Update

I admit, I was pretty skeptical when we first started our Agile project.  I still don’t think it’s the way to run all projects but for this one it’s pretty much the only way this project can work.

Why is that?  Gosh, where do I begin.  The client knows what they want…..sort of.  The sprint goals we had in Sprint 1 have morphed into something maybe not completely different, but they’ve shifted from a very narrow and specific goal to something a bit more broad and generic.  Or maybe a better way of putting it is that they started with goal A in mind and A has gone through seven, three week cycles of steady and incremental improvements so that instead of handling one specific scenario it can now support an infinite number of scenarios.  Some of the things we’re coding for now didn’t even come to mind until sprint 4 or 5 because the project owner didn’t even know they needed/wanted the feature.

Agile in this case is good because in traditional waterfall methodology we would have setup a big timeline with deliverables and gone away for 9 months, spend a couple hundred thousand (or more) and come back with something they didn’t want.  I live in a town (Kansas City) where that is the norm with a certain telecommunications company that shall remain nameless.  I dare you to ask any software developer or engineer that’s ever worked for them (and there’s a lot of ‘em!) and see if doesn’t work that way.  It’s a disaster and everyone loses in the end.  A lot of big corporation projects are like that I guess.

Agile is causing the client to rethink their internal projects.  They’ve even started moving some of their internal projects to agile.  However, with the thousands of people in their organization I bet there will be at least one spectacular failure because of the entrenched bureaucracy and it will give agile a bad name.  That’s my prediction only because the reason why it works for us is because we’re adapting as time goes on.  I’ve never met an organization that size that can spin on a dime.  Only time will tell if that prediction will come true or not.  Heck, I might not even be involved with the organization by then.

Agile has allowed us to do some fantastic work with the interface.  What their internal groups have struggled with for years, we’ve been able to incrementally improve during the course of the project.  One of the first comments we get from people seeing the prototype for the first time is how awesome it looks and how intuitive it is.

So how does REALbasic fit in?  We have been using RB to create incredibly rich and detailed prototypes which in turn is driving conversations inside the organization on the future of the project.  We have an interesting mix of mockups and real code.  The mockups are done first in a graphics program and the images are put into the prototype to show where we’re heading.  It has also provided an avenue to discuss requirements not yet defined and gives us developers a very clear direction on what to code.  It drives requirements which is interesting since normally the requirements drive the development.  So for us the prototype drives the rest of the project.

The REALbasic 2008 series has been exceptionally stable and secure.  The exception to that statement is Release 2 that killed us with the Windows apps not being able to catch nil object exceptions.  Otherwise, the number of bugs or limitations has dropped with each release and some of the newer technologies like introspection have started making its way into the project.  And since installation on the client machines is so easy (unzip a folder) we’ve not had too many issues.