Welcome to my stream of conscience series about topics that are popping up on a new team that's largely comprised of folks new to Agile practices.

The "Build" Should Remove Project Friction

Part of a full fledged Continuous Integration effort is an automated build script that can lay down all of the environmental dependencies of a system.  In other words, running the build file on a local workstation should make your workstation able to run that code.  When you're updating your version of the code, especially for the first time or with stale code, you might make a habit of running the build file before you begin coding to guarantee that your box is ready to execute the code.

On the other side, be a responsible member of the team and add any new environmental setup from your work into the automated build script.  By putting that setup into the build file you've accomplished two things:

1. You've effectively documented the environmental setup dependency
2. You're propagating the environmental change to the other developers, the build server, and the test environments

Here's a story about an irresponsible developer that routinely made environmental changes to the code without adequately warning the other developers on the team.  I'll call him "Jeremy."  One day Jeremy came in early and created a new web service project for some of the new backend functionality.  Jeremy let Visual Studio.Net make the IIS virtual directory for him.  He then proceeded to write integration tests against the new web service and tied the user interface to the backend.  He then checked in and went to lunch.  The other hapless developers updated their code and quickly discovered that the application no longer functioned on their workstations.  Because they didn't know about the new virtual directory dependency that Jeremy had introduced, they spent a fair amount of time trying to troubleshoot the application failure.  At the some time the testers pulled down the new build and discovered that the application no longer worked.  They were unable to work at all.  If Jeremy had simply added a task to the build script to setup the proper virtual directory (and used CruiseControl.Net), he could have saved the other developers' and the testers' time.

When Estimating, Remember the Whole

Story estimation is an important activity that feeds the project management types with increasingly accurate information they need to plan the project timeline.  It's not fun, and it's definitely an "eat your broccoli" type of activity, but it's your best tool to maintain a sustainable pace.

In a typical Agile process you spend a fair amount of time estimating stories.  Contrary to some popular belief, Agile isn't (not supposed to be) pure cowboy coding and unplanned chaos.  The core of Agile project management is adaptive planning.  The plan is constantly updated to reflect the latest estimates from the developers.  The crucial assumption is that developer estimates basically suck on day one and get progressively more accurate as the project proceeds. 

A crucial part to better estimates is to take a broader view of the development work rather than focusing on the code only.  Making a story cross the line into the "done, done, done" category involves more than just the code.  Many, if not most, developers are consistently overly optimistic in their estimates.  I'm betting part of the culprit (beyond developer hubris) is failing to pay attention to the ancillary tasks that take place as part of development.  When you're estimating a story, you need to also account for the time it's going to take to make extensions to the build automation, test automation support, and other sorts of overhead.  For example, a user story might only require a couple hours of coding, but spawn so many possible permutations of input that writing automated tests takes several times longer than just the code.  You might even make a point of calling out these extra "hidden" tasks out explicitly when you're estimating stories.

Sustainable Pacing requires some Trail Blazing

One of the attractive tenets of Agile Development is Sustainable Pace.  I think everybody agrees that eliminating overtime is a good thing, but achieving that goal is a different animal altogether.  There's also a flip side to Sustainable Pace, the development team cannot afford to be idle or working ineffectively at any point because they're waiting on some other input like requirements or infrastructure.  To maintain a level of efficiency you need somebody to be out a little bit ahead of the developers making sure that the next batch of stories and environment needs are taken care of.  That developer abstraction layer is essential. 

I don't have any particular recipes for solving this problem.  My previous team never entirely solved the problem.  Ideally I'd like to have dedicated business analysts or even testers that stay just ahead of the developers to insure that the developers are always fed with detailed requirements for the next iteration's stories.  Since we don't have dedicated BA's, I'm suggesting that my new team follow a practice of identifying analysis holes for iteration n+1 during planning for iteration n and work analysis stories an iteration ahead to maintain a steady path.  I'd like to prevent cases where the development team is completely idle waiting for requirements decisions to be made.  When I was very new to Agile developement I sat in and listened to two different teams have an impassioned argument about whether or not the analysis stories were a good thing.  I can't say that I understood the arguments on either side then, so we'll try it anyway and fix it later.

Long iteration kickoffs can hamstring a team.  If iteration planning becomes overly long, some pre-tasking meetings near the end of iteration n-1 might make planning for iteration n go smoother.  Getting to day 1 of an iteration and realizing the analysis work isn't baked or understood isn't a good feeling.

In the end, my goal is to develop a team and ecosystem that can continuously pull down stories for an iteration, finish off those stories within an iteration, and repeat without pause for the duration of active coding.  Meeting that goal means having half an eye cocked looking ahead and removing obstacles to the developers (and testers).