I am trying to resolve how to structure the parts of the CI process and keep coming back to some build process polling the scm system..

developer works on his workstation.. local eclipse/intellij/Visual Studio builds.  all private, on demand, no waiting.
time to get ready to share.
    accept changes to private workspace, and check-in local changes.. 
or the reverse
    check-in local changes then accept others changes,
resolve conflicts.

then use an external builder.. developer manually starts 'build' and repeats until clean (similar to local workstation) against private workspace, aka, personal build.

then delivers to an integration type stream (not the master stream), and repeats any conflict resolution and build process. still all manually scheduled jobs. (shouldn't have many of these failures, but it will happen)

some other scheduled job does a compile against the same integration stream (daily, whatever)

then from here it can get automated.. function/perf/deployment/scaling tests as needed. (end of sprint do more than dailys)

then by policy you choose to deliver (and automatically trust the test results, or wait for manual approval)

net, each developer has a private system (sandbox) and a server side copy (workspace, branch)
builds (JBE, Jenkins, ...) run against the server side, manually (ui, commandline, script) started jobs..
no instantly triggered jobs injected into the build q (jbe only supports polling)

then the upstream builds are polling/schedule based., integration, daily, end of sprint, ...

and eventually there is a process to re-integrate this release change stream back into the release book of record (stream, trunk, repo..)