Thursday, 17 July 2008
I just can't shut up about it
Agile. I use that word so many times a day now I'm starting to sound like a salesperson. Not good. But I'm deliberately keeping my vocabulary small (keeping it simple) so that at least what people hear is consistent.
I have been interviewing business analysts lately and it's important to me - surprise, surprise - that they have experience with both analysis and project management in an agile environment. As it turns out, the guys that I've liked have a similar idea to mine about agile methodology: One should be agile about that, too!
What I mean by this is that if you're truly agile you don't lock yourself into one single methodology for running your project. It's better to mix and match, pick and choose, chop and change. Construct your own methodology from a set of others and make it fit your situation, your constraints, your experience.
Why is this important? Because the less you impose process, the more nimble you are.
I've had some interesting discussions around this recently. I'm leading a new project, a new and exciting build. It's the ever elusive greenfield. A chance to do something new, something different, to try different shoes on and throw away those that don't fit. This is why I accepted the challenge, because of all these opportunities. And I have been adamant that we should be nimble, flexible, agile all along, and that we should use this opportunity for all that it's worth to try new things.
But my ideas were almost stopped dead because the company that I'm working for currently has a massive IT initiative underway to put in place required processes to manage their rapidly growing development team (which is up by 300% in a matter of months) while at the same time refactoring and rebuilding an aging and highly coupled trading platform.
The team undertaking this work is already so big and now growing so fast that they need process. I argued that the team that I'll be leading is so small that we really don't need all that process. I argued long and hard and had to turn to many different people before I could finally convince the IT leadership that it really is OK to go light on process and tools and support systems when you're in the early phases of something like this.
There is no need for a full blown Team Foundation System setup with all its bells and whistles. Subversion does the trick, and it does it beautifully. There's no need for meetings about every aspect of what we are about to embark on. There's no need to define processes for this, that, and everything in-between. In my case, we're kicking off a proof-of-concept project that later will - hopefully! - end up becoming a large scale development with full IT and business backing. Right now, we just need to get on with our POC with minimal hassle and minimal interference. Later on, when the business says "Yes this is great! Here, have a wad of cash", that's when we should start looking at any extra processes and tools and systems we might need to put in place.
I've spoken before about things being a problem only when they are a problem. Anticipating a need for process months prematurely just creates a problem from a notion of something that doesn't exist. Remember that. YAGNI applies not just in best-practice coding guides, it applies to everything that can be labeled as agile.
So, in final words and a note-to-self: Shut up and do it!