Archives for March 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.
It’s a sad reality. Most IT departments are drowning in a sea of unresolved trouble tickets. Every staff member does her best to keep afloat by working off issue after issue from the never ending stream of trouble tickets. Motivation and quality plummet because, in such a work mode, people tend to
- work alone
- feel high pressure due to the amount of unfinished work
- lack concentration due to continuously incoming “super urgent” requests being even more urgent than the “super urgent” request they are currently working on
If this sounds familiar to you, it’s time to fundamentally change the way you organize your work.
“You butt-head developers!”
“You pedantic sysadmins!”
Developers and Operations teams are frequently at war. I have seen such trench warfare as a systems administrator and as someone on the dev team. It’s a conflict that happens each day in businesses all around the planet. What’s the root cause?
CI in development
Developers are really nice guys and they have figured out a lot of cool agile stuff. One of these things that really interests me as a sysadmin, is Continuous Integration (CI). Let’s have a look at the wikipedia definition:
“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.”
Appliance recipes are plain Capistrano recipes which enable you to setup a complete server by just using one of the pre-defined ones like apache_lb, rails_22, memcached or mysql_master.
This is a guest post by Thomas Eisenbarth. Thomas studied computer science at the University of Augsburg, currently works at BINconsult GmbH, Berlin and co-founded makandra GmbH in Augsburg. He and his teams develop and operate web applications.
We’re also using Munin for some time now to monitor our staging and production stuff. There is only one little problem. Most of you guys out there have machines at multiple locations and nameservers which may not be collocated. Most setups that I’ve seen so far do their testing and development at the office while the production sites hopefully run out of a datacenter with reasonable bandwidth, security, etc.
- How Do Story Points Relate to Hours? – One recurring question I get asked when talking about agile (and specifically when estimating in Story Points) is how those things relate. Mike Cohn does a great job in describing that the relation between Story Points and hours is a distribution rather than a direct mapping.
- Agile is All About Feedback – Bret Pettichord debunks a couple of myths about agile while coming to the point. Agile is all about getting feedback about the software you’re building on multiple levels: pair programming, acceptance testing, iteration planning, etc.
- Do We Need Projects? – I like James Shore’s view on software “projects”: The end of a development project is usually not the end of the software being built but the starting point of its life! One has to consider operations, maintenance, etc. instead of thinking software is “done” just because the initial development project ends. I’ve made especially bad experiences in that respect with external contractors whose assignments ended with the project which, of course, killed their motivation to care about how the software they’re writing shall be later maintained and operated. I prefer to think in products and releases like James does!
- Beware the Hero by Elisabeth Hendrickson. Elisabeth tells a tale about the lonely hero in an agile project simulation who was very close to ruining the complete project. Unfortunately, I fear most of us have experienced a similar situation in real life!
Let us know in the comments what your favorite posts about agile are!
Source Code Control
I started my work last December of course by spending a lot of time with the different departments and a brief introductory visit with our offshore team. I migrated the subversion repository to a neutral site, enforced comments and enabled email notifications for commits so I could begin understanding how the team worked on the codebase, and more importantly, correlate reported bugs/features to bugfixes and newly generated source code. Because of this, I’m able to do quite a bit of trivial bugfixing on my own which frees up the rest of the development team to focus on lower priority, but time critical, project work.