Local Build... how big and how long?

Peter Morlion raised an interesting topic on the Agile Alliance LinkedIn group about how long a developer build should be allowed to run. It seems his team is split down the lines of "its important, so suck it up" and "this delays me too much, make it better".

His full question was:

Local build takes a while - run a stripped-down version?
Like in a lot of teams, we update from the source repository, change code, run the build locally, and commit if it builds. So far, so good. But the build takes a while of course. Personally, I think that's just something to live with, but my teammembers want to use a stripped down version of the build (mainly not building the sandbox, because it doesn't change much).
What is your opinion on using a non-complete build before committing, while the build server still runs the full build?

As one of the first to answer I said:

I would agree with your team members... unless I already need to take a smoke break every hour or so, that does not enable higher productivity. ; )

In my last team, the local build included the tests... If your developers have to wait more than 2 minutes for the process to complete, they start seeing this time investment as an impediment and may try to work around it by coding larger chunks before committing and integrating. This is the reverse direction agile maturity typically should take a team (especially a team leveraging TDD).

The sooner someone can verify something in the integrated build server, the better off the team will be. The purpose of the local build is to smoke test the local and obviously connected things they are focused on.

A balance has to be created between the two. If you swing too far in the other direction, then the team is hurt because the integrated build is broken more often.

Good luck finding the happy medium.

Tests after story closure?

As a customer I tend hang out in the VersionOne google-group user forums. Sometimes I find myself providing agile coaching feedback unrelated to the tool. Today was one of those days.

A peer was asking questions about the tool when running tests. But their team regularly closed stories in one sprint and had the testing team test that work in the next sprint. I had to share the following feedback:

"Flags are raised in my head whenever someone says that their testing team works on the prior iteration's work.

This is problematic for the following reasons:
- the development team has moved on to new work
- if the testing team finds something, they must "interupt" the development team to go back and fix the bug
- this throws off velocity (or it is gamed and false)
...and this whole concept feels like a mini-waterfall since it ignores that the product should be "potentially" shippable at the end of an iteration.

What we did on my last team was have a CI (continuous integration) build that ran every night separate from the check-in test/build process. If everything passed, then the test environment was automatically updated in the middle of the night. Thus, our test team was part of the sprint team and they tested stories as they were built. Stories were not closed unless Dev, Test agreed AND the customer accepted them. This removes the pitch-over and splash-back feeling.

It can also remove a lot of interruptions and debates that pit QA against Dev.

Having said all of that- you may not technically be able to do this today. Or, your culture may not be ready to truly be agile. As a pragmatist, I say whatever you are doing is better than not. I just wanted to throw this out there as a potential goal to strive for. "

I'm glad I said the last part... my peer responded with appreciation but noted that they were working through the technical hurdles to creating an automated build.

No build... No Agile?

gatorxero wrote that not having a CI (continuous integration) build means not being agile. He actually says it is an "absolute requirement".

Sounds like a purist viewpoint.

My response was down the lines that engineering practices do not define being agile. I agree that CI is very important, but a scrum shop can be agile without adopting XP.