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.

Continuous Integration can be a great place to do governance. With good reason developers get the shakes when someone mentions we need more governance. Past history has taught them governance often means someone above them says no.

Continuous integration allows you to inject good development practices and ensure some governance without having to always be the bad cop. Let the build box be the bad cop.

If you’re a Java or .NET shop you can add all sorts of checkpoints to the build and tell at a glance where projects are at and dig into the details. The sorts of things you can do include:

• Requiring every active project have a build script and be setup on the build box.
• The code must checkout completely and compile successfully.
• There must be tests and all tests must pass.
• Unit test coverage must meet a target number or the build fails. (We use 70% currently)
• Coding conventions must be followed or the build fails if you have more than say 20 violations. We use Checkstyle to enforce this.
• The code passes the CRAP metric.
• The code passes other static analysis checks like Findbugs or PMD.
• Package dependency analysis using thing like JDepend.
• Security static analyzers to prove code meets security standards. (I haven’t tried any of these yet.)

All of these steps help you promote good practices, ensure transparency, and give you governance over day to day coding instead of just a review or two at the beginning and end of a project.

Ran across a wonderful rule when putting together your annual goals.

“A goal that a dead man can meeting is pretty useless.”

– (Comment on Manager Tools)

Some potential dead man’s goals:

• Improve automation on projects.

All I need to meet this goal is a single developer with an ounce of effort to create a single ant file or shell script. I don’t have to be alive to meet this goal.

• Engage more with business customers.

If one of my developers talks to a salesperson in the hallway, check, done.

• Deliver 5 projects.

No one said they had to be big projects, maybe a small production bug fix counts as a project. Again a team could probably do this without any manager.

• Perform maintenance on System X.

Everyone has maintenance, check.

The guys at Manager tools have a really simple model. The goal just has to be measurable and time based. Thus the goals become:

• Automate all projects with maven by November 15.
• Meet a rating of good or better with an annual survey of customer satisfaction for internal customers by September 1st.
• Deliver Project X with less than 10 severe bugs by May 25th.
• Reduce maintenance costs on System X by 50% by December 30th.

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.

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.”