MavenModuleSetBuild.getResult looks for the worst result of any of the last builds of the component modules. If you are using Maven 2, some of these might have been run after the MavenModuleSetBuild itself completed, either because you build modules in parallel, or because you manually rebuilt one of the modules; in such cases the result of the module set can be retroactively worsened. (Although Run.setResult is only permitted while building, getResult is nonfinal, effectively a backdoor to get around that restriction.)

Besides the logical confusion over whether a given build of a job was successful or not, this logic is very problematic for lazy-loading:

at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:496) 
at hudson.model.AbstractProject.getNearestOldBuild(AbstractProject.java:1067) 
at hudson.maven.MavenModuleSetBuild.getModuleLastBuilds(MavenModuleSetBuild.java:434) 
at hudson.maven.MavenModuleSetBuild.getResult(MavenModuleSetBuild.java:189) 
at hudson.model.PermalinkProjectAction$Permalink$3.apply(PermalinkProjectAction.java:134) 
at jenkins.model.PeepholePermalink.resolve(PeepholePermalink.java:95) 
at hudson.model.Job.getLastSuccessfulBuild(Job.java:802)

For example, every time the Maven job is displayed in a view, getResult is called at least once for the icon color. (Probably also to verify the permalink even when the symlink such as lastSuccessfulBuild exists, which after JENKINS-16023 it should.) But this forces the most recent build of each module to be loaded, too, and if there are a lot of modules that can take significant time, either after startup or after some have been evicted from memory.

Not clear what can be done here. Options:

1. Delete this override and break functional compatibility. Means that jobs using parallel module building will not show meaningful status.
2. Suppress the override in case the job is currently configured to use Maven 3, which does not support the trigger conditions to begin with. But it is not trivial to tell this; a MavenInstallation will resolve to a specific version only during a build (it might not exist at all on the master).
3. Store the current effective result in build.xml and use some listener to update it after relevant module builds.