Repeatable releases

Agile teams are well-placed to deliver good software. But the acid test of an agile team is whether they can keep on delivering good software, frequently and reliably. Some development teams find it hard to believe that it a regular and repeatable release cycle is possible, given the blood sweat and tears they require to "go-live". Or if it does seem possible, the prospect of the effort required just seems too painful to contemplate on anything less than a six-monthly basis.
Consider your project: how difficult do you find your releases? Think about the reasons for this: which of them are under your team's control and which arise from the way your organisation is structured? (It seems to me that all-too-frequently the software development, QA, and production support arms of an organisation are too remote from - and wary of - each other to be able to accept a short and frequent release cycle.) But persevere: there are many benefits to be had from addressing deployment issues in order to release "little and often". (This post was prompted by the appearance of another milestone build of the open-source Eclipse IDE: the Eclipse team delivers new stable releases roughly every six weeks.)

Meta Group: CIOs must transform negative view of IT

IT spending is apparently still seen as a drain on costs. I wonder what the cause is - other intangible spends such as marketing don't get the same bad press. Is it: the business - technical language barrier? the failure to measure return on IT investment? the over-selling of 'snake oil' cure-alls by suppliers? the short lifespan of many (desktop) systems? the fact that IT staff are expensive to employ? the number of projects in chaos? Hmmm, could be...

Mind the communication gap

Dr Dobbs Journal recently ran an article about communicating with managers. Coming from such a technical magazine it indicates the high degree of interest in software development's soft issues. (It's nearly 30 years after the publication of Peopleware and the software industry is still coming to terms with the fact that most problems are people-problems and not technical-problems, sigh.) As far as the article goes, I'm not sure that the strict categorisation of good and bad managers is particularly helpful. Using that kind of language, we could rewrite the whole article to discuss how managers can communicate with good and bad developers. No, in a nutshell it boils down to this: "communicate early, communicate often, and communicate honestly."

New feed! New content!

To mark the Atom-enabling of this blog by the good folk at Blogger I have published all the draft ideas that I have been sitting on for the last 3 months. As a result the syndication / XML feed that you need to bookmark is now http://coachspot.blogspot.com/atom.xml
(The posts were sitting around doing nothing and it's not like I didn't need to be kicked into action after a loooooooooooooong period of blog inactivity...)