Agile With Infrastructure Projects

Agile is really designed around software projects. Infrastructure is a different animal. With an infrastructure project some things start to break down:

  • You usually aren’t writing much code, maybe some database install scripts so no unit tests.
  • Often there’s no continuous integration to speak of.
  • Configuration tasks on new software are often difficult to estimate.
  • Many tasks end up being time-boxed research items.
  • Team members tend to be specialists DBAs or Linux system admins.
  • Most of your team are system admins, but often they aren’t dedicated.

I’ve done a few of these now and generally the most difficult part has been having dedicated staff. System admins and DBAs structure their days around reacting to issues and answering many small requests. The idea of dedicating whole days or weeks to a project is novel. Too novel perhaps as often their management chains are unwilling to dedicate resources.

Our approach has been to use some Agile practices like daily stand-ups and task boards, but these practices haven’t made for smooth infrastructure projects. Since our QA team has been investing in automated functional tests we now have regression suites for some of our major projects, but that’s about the only automation we’ve been able to make use of. It often comes down to a PM/Scrum Master who’s willing to constantly remove impediments by walking around making sure the project keeps moving forward.

Mainstream Agile with XP?

I hadn’t realized the Head First series now has a book on software development. Curious, I took a glance at the table of contents. Topics include:

  • TDD
  • User Stories
  • Burn Down Charts
  • Continuous Integration
  • Test Coverage

Agile and XP practices are starting to be assumed. Maybe Ambler and others are right that Agile has really crossed the chasm. Just a year or so ago I bemoaned the lack of unit testing examples in Head First Java 2nd Edition where they went with the lame old main() method to demonstrate code. Now we have whole chapters devoted to TDD.

If you can’t honestly put unit testing or continuous integration on your resume you might want to stop sitting on the sidelines and get up to speed.

Standup in the Dark

The lights went out to work today after a winter storm rolled through Sacramento. In an agile spirit we still held one of our standups after moving near one of the windows.

Scrum Master: “OK, anyone have anything to report?”
Team Member #1: “I was really productive right up until the lights went out.”
Team Member #2: “I have an impediment, no machine, and no light.”
Team Member #3: “Turns out I won’t need a migration to the QA server today.”
Scrum Master: “Oh, and the review is at 12:30 next week, and I’m scheduling the retrospective today if we get power.”
Team Member #4: “And you can add lunchtime sprint reviews to that list of things to look into right now.”

Scrum Master Stand In


A sign of team self-management success is when the Scrum Master is out or busy and someone just fills in. I’ve known one of our Scrum projects was moving along pretty well, but our organization still has a tendency to try to have another PM fill in at the daily standup. In the old command and control phase this made sense, but with a self-managing team it just becomes a minor impediment. Today I left a Scrum meeting with a big smile as one of the business analysts on the team had facilitated the standup.

Next step is having a rotating facilitator instead of always looking for the Scrum Master to lead.

Off To Agile Open California


I’m off to my first open space conference later this month at Open Agile California. Should be a great chance to recharge some batteries and talk about issues with sustaining agile. I know after three years of Agile and two years of our official effort that we no longer do a lot of questioning and looking outward for new ideas. I’m focused on how you re-energize an organization at this phase, especially when many of the original high level sponsors of the effort have moved on.