Four short links: 22 Mar 2009

Agile and ITIL, agile sys admins, why to work in small batches and how to handle bugs in an agile context – the topics for todays four short links.

Agile and ITIL: A Powerful Combination (Joe Pearson, PM Hut) – I’ve also given a lot of thought on how to join the lean values of agile with the accepted practices of ITIL. One of the biggest barriers to this, however, is the entrenched operations staff who view agile as the “new kid on the block” – not to be taken seriously, or, even worse, something which rocks the boat.
ITIL exists because the establishment takes extreme care of their infrastructure and their processes. It provides a secure starting point for a lot of IT staff to get their hands around difficult IT issues. But we all know that getting comfortable eventually means getting lazy.
Agile + ITIL is the best of both worlds – ensuring that there are no “established” processes by constantly challenging accepted beliefs and demanding continuous improvement.

2009: The year of the Agile Sysadmin ? (Patrick Debois, JEDI) – If you think that Agile + Operations is a pipedream, think again. Patrick’s compiled a list of Agile2009 submissions pertaining to just this topic. Take a look at a paper that interests you and support the cause!

Work in small batches (Eric Ries, Startup Lessons Learned) – I couldn’t agree more with Eric: Working in small batches was the single most successful shift in our development organization we made. It changes everything (for the better): faster ROI, faster feedback and less risk. But, it’s also one of the hardest things to introduce. Especially in an existing code base which doesn’t have any automated tests. It literally feels like a complete stand still for the first couple of small batches ’til the whole process and the minds of the involved people have adapted to the new way of working.

Handling Bugs in an Agile Context (@testobsessed) – Elisabeth is bringing up a hot topic here. I’ve seen a lot of agile teams drowning in a flood of open issues. Her approach for enforcing “Done” and getting rid of technical debt (see the comments) is very worthwhile to read.