Sunday, July 22, 2007

Agile Communism - what is Agile anyway?

For a long time now, I've considered Agile a good thing - I've listened to Podcasts, read a book or two and plenty of Blogs.
A recent post on Agile Advice - comparing (or questioning) Agile's parallels with Communism, sent me on a web surfing frenzy as I followed link after link, reading post after post and comment after comment.
Along the way, I stumbled on a few key points, that made me think again about how (or even if) I label what I do, in terms of managing a software development process.
In the past, I've been exposed to, and tinkered with all sorts of approaches to SD. From Waterfall and RUP to Agile. It's always been in such small teams though, that full on formal processes have never been required or really even possible. In really small teams, formal processes just fall by the wayside as they add more laborious overhead, than they deliver value and because communication is easy anyway.
I've always maintained that communication and common sense are what is important especially in small teams. I've also always basically, looked at each project I've had, assessed fairly informally, what kind of communication and records are required, what sort of team members we have and picked the bits of different (acedemically labelled) methodologies, and used them. Sometime, with high level management or investors involved, you need some formal upfront requirement and planning type documents to keep them happy - so write them! Then you break it down. Sometime you need documents for both end users and developers to work from and communicate with. Use them - User Stories, or Use Cases whatever. If the developers sit next to the users, user stories or cards might work for this, if the testers are in Auckland, and the developers are in Melbourne while some other users are in Sydney, you tend to need version controlled Use Cases and weekly status reports to keep everyone on the same page. In all scenarios, as long as everyone understands what the developers are working towards and in what priority, people generally stay happy. If that takes a weekly or daily meeting, phone calls or formal status reports, to keep your work flowing towards it's goal - do it!
The company I work for developers software for builders. Imagine builders using just one technique for every house, every wall, every room, carport etc they build. Plenty of basic principals apply to all, but buildilng a house in Perth is different to Queensland. Terrain is different, climate is different and so on...a countless number of variables. A software product and it's environment probably contains more variables than any other undertaking. As Steve McConnell say, "programming is one of the most complicated things you can do." You have to draw on your knowledge of the customer, the budget, the users etc. etc. (i.e. the terrain) and morph a process that solves the problems and meets the needs you're faced with. There are plenty of books and blogs discussing what has been done in the past, but none to describe your next project.
So imagine my surprise when several years back, I stumble over writings about XP and then Agile. "Hey - this is for me" - basically, morphing whatever process you need, to get the job done, this Agile is a label someone has given, to what most leaders of small teams and small business do anyway.
For decades now, as the IT industry strives for acceptance amonst the more established disciplines and industries (and desperately wish to label themselves as "engineers") we see attempts to formulate methodolgies, patterns etc. But now, we have the Agile manifesto, full of noble and wise ascertions/rules and guidelines, attempting to formalise and document common sense. Adapt to your environment, deliver what your users and audience need to keep your project moving towards a desirable goal, and you're Agile - if that's it, then I'm Agile! So be it. In XP, Scrum, RUP, Waterfall whatever, we have many many useful tools at our disposal. Use them, don't use them, whatever!?! Get the job done, and you're "agile" - if you really feel the need for a label, keep doing what you're doing and call yourself Agile.
Oh, and Agile vs Communism, for the record I would say, good Agile = Democracy. One (and only one) methodology for everything, a Dictatorship! As for communism I don't think the analogy quite fits...we're talking about production methods, tools and techniques, not ownership of resources or organisation of communities or teams.