You may have noticed some tweets from me on Friday morning on the subject of Agile methodologies. Work arranged for a couple of speakers to come in to speak to us on the subject.
Our company is made up of three types of people.
- Those that are fully invested in agile and use it on a day-to-dat basis.
- Those that think they know agile and perform some bastardised version of it.
- Those that need a warm up before they can even say the word agile.
If I’m honest, I fit into the last group. I understand the approach and know some of the terminology, but I’ve never worked in a truly agile team, just those that play at it. I’ve also seen terms like agile, RAD and extreme programming used as an excuse to avoid doing the job properly, so there is a slightly bitter taste in my mouth.
In the recent office reshuffle, the DBAs have been put into a development team. We are still responsible for all production stuff as well, but we share the office with a development team and as usual, will be involved in a number of projects. As a result, getting involved in the whole agile thing is quite important…
The first speaker up was Kay Johnson from IBM, who has been involved in the rollout of agile throughout IBM. She started off with an overview of agile, then talked about how to scale agile through a company as large as IBM. It’s interesting that even the CICS team at IBM now use agile methodologies. Kay is a really enthusiastic speaker and great at getting the crowd involved. I really enjoyed the session. If you get chance to see her speak, you really should make the effort.
Next up was Gavin Barton from the BBC, who was talking about how the BBC has implemented agile throughout the web team. Gavin was a very relaxed and confident speaker, very open and honest when answering questions. Once again, you should definitely make the effort to go and see him if you get the opportunity to hear him speak. As you would expect, there was a lot of common ground between what he said and what Kay said, but it was good to hear how two sets of people arrived at similar conclusions via different routes, and of course some of the differences between the two.
If I combine a few of the take-home messages from both speakers, it would go something like this:
- Agile is not an excuse to avoid planning and documentation. If anything it requires more discipline than the traditional waterfall approach. The point is you don’t spend so long planning that the requirement has changed by the time you come to code. Likewise, you don’t spend months producing documentation nobody will ever read. Keep it all direct and to the point.
- Agile is about being user/business driven. Work with the user/business to give them what they want. Don’t assume you know better.
- Sprints should be no longer than 2 weeks. Gavin suggested for many things they do, 2-3 days is actually better. As Kay said, there is always a way to break stuff down to something smaller, so even massive projects can be broken down to 2 week chunks.
- Sprints should produce something that is production ready, even if it hasn’t completed UAT and doesn’t make sense to release it on its own. That means the developer should have confidence in what they have produced. A sprint might be one function or one page that can’t be released on its own, but in itself is production ready.
- Each sprint should include planning and a retrospective look at how things went so you can learn from previous successes and failures.
I’m going to stop here before I embarrass myself with my total lack of knowledge. Suffice to say, it all sounds really great providing you invest in it. Do a half-hearted version of it and it’s going to suck. Kind-of like everything in IT I guess.
It was a great morning. I’d like to personally thank Kay and Gavin for taking the time to come and speak to us and of course Dawn for organising it. Everyone I’ve spoken to about it has come away with a really positive view of the event.
I’m not going to act like I’m Billy-Agile now, but over the coming weeks as I get agiled-up, I will no doubt mention it a little. Especially how it fits in with the DBA role. I think that is something that is not so obvious as it maybe is for the developers. Please bear with me. It’s a learning curve and I will make mistakes, but I’m more than happy for you to call me on them…