Agile
Agile Culture
I’ve read a couple of posts recently which I thought I would pass on as I thought most helpful.
Mark Schumann discusses some of the problems an Agile team might face in terms of external pressures.
And Jeff Patton explains why thinking of Agile as a culture and not just a process explains the resistance and difficulty in teaching and learning the approach within an organisation.
Both impressed me so much I even commented which means they must have struck a chord!
And they’ve both got cartoons on them which is cool ;o)
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.
Laws of Productivity
This article discussing productivity of technical teams is really good stuff. It’s all backed up by research, which is especially helpful for those who might be building or managing a technical team and need to make a case to business sponsors or stakeholders.
A nod to Tales from a Trading Desk where I first discovered the article.