Archive for August, 2009
Agile Hype?
There is now a lot of “hype” around the Agile development methodology, possibly because it’s producing better results than traditional approaches, or perhaps it just makes people’s working lives more interesting and challenging?
Either way, I read an agile101 post suggesting that ‘doing’ agile is a sign of incompetence which put my hackles up as you might expect, given that I’m a keen advocate. But the article makes an extremely pertinent point which I’d like to stress – that Agile is only something you are going to ‘become’ with plenty of practice. Picking up a book is a good place to start but that’s all it is… Agile development is an intuitive mindset, not a bunch of rules you can follow and hope to immediately be good at.
It also struck me that as Agile has gathered pace there are now many different ways of wrapping lots of processes and metrics, management techniques and so on around the basic concepts. In my opinion this in many ways detracts from the fundamentals that are ultimately going to help you deliver, and feel these demands can actually make a team less agile as the post suggests.
Here’s my mantra, if I can call it that, which I try and religiously stick to whilst leading Agile software development teams:
- Focus, focus, focus – if it doesn’t make the boat go faster then save it for another day.
- Refactor, refactor, refactor – even the smartest and most experienced developers rarely get it bang-on first time around, especially given that priorities and requirements are often less than stable.
- Challenge the business sponsor and requirements – often I’ve found that requirements are over-complicated for the problem at hand. Get to the root of the issue, understand it, and then propose simpler alternatives which actually address the real issue.
- Aim for the best in every single line of code and development practice if you can – look after all the little things and the big things will take care of themselves!
Sure, there are many tips and suggestions that can help you and your team to a place where you are able to “move light, travel fast” but as a Technical Lead or Architect (as opposed to Project Manager, say) I think it’s more important to get an intuitive “feel” for what’s a true value-add.
Although you’ll probably have to compromise at times on some of the points mentioned above, they’ve been great cornerstones for me when I feel there are too many demands on my time from what I consider to be less important techniques or deliverables.
Incompetent Managers
Whether you have any pretensions of becoming a “Manager” or otherwise, the following post will probably be widely recognised by many in senior positions, and hopefully will be helpful to either those that aren’t or want to be. I doubt that the points mentioned are restricted to just the Technology industry.
I’m currently classified as a “Manager” in that I have leadership responsibilities, though prefer to roll my sleeves up and make sure I am contributing significantly towards results, as well as guiding those around me to help them make the correct decisions. I guess I prefer the term “Leader” and the connotations that brings with all the differences between the two titles.