Building Trust with Trustworthy Builds

More on "trusting the organization" ... Roger Session’s “Enterprise Rings” bear a striking resemblance to the different kinds of builds and promotion levels I describe in “Agile Build Promotion: Navigating the Ocean of Promotion Notions” where each kind of build corresponds to a different level of visibility within the organization:

• Private Build: Individual / Task
• Integration Build: Team / Project
• QA/CM Release Build: Organizational / Program
• Customer Release Build: Everybody else (business customer, portfolio investor, etc.)

As I wrote in my previous blog-entry on building organizational trust, each one of these levels of scope corresponds to a boundary between stakeholders that must be bridged with communication and trust

One way for development to build trust with the CM organization is to engage CM up front and elicit "stories" about what "trust" means to them for handoffs from development to CM. What are their biggest complaints/concerns about "trusting" development? Do they fear development will:

• Break the build if they do their own integration/merging and "commits"
• Hand off a build that is not reproducible and reliable?
• Use/create unstable developmental builds that are inconsistent, incorrect, incomplete, or incoherent?
• Neglect to create named stable baselevels at appropriate times
• Monopolize the build servers/resources and software licenses that CM needs to use
  

If CM doesnt trust development about these things (and others), find out why, and partner together to create "shared stories" that will evolve into the acceptance criteria for development to hand off builds to CM. For example:

• If developers use the SCM Patterns of Private Build, Task-Level Commit, and passing all the automated tests, will that eliminate the fear of development breaking the build? If not, what else? Do they need a way to be sure that these are actually followed?
  
• If there is an automated build that development systematically uses to reliably ensure that a sandbox environment and build-time options/flags are "sufficiently comparable" to what CM uses, will that eliminate fears of inconsistency and unreliability of the build and its reproducibility?
  
• If there are business requirements to be able to support multiple releases or (customer special" variations), many agilists/extremists may not want to hear this, but they must learn to respect it as both a business requirement and a CM concern. Then they must learn the requirements to be met so that a solution can be proposed (which might be different from the solution CM had been assuming should be used)

What other things must CM do with the build that they are afraid they wont be able to do if development does their own merging/building? How can they be incorporated into the automated build+commit protocol that development will use?

Once these stories are gathered, fears have been expressed, and needs have been elaborated, then development (with CM's assistance) should develop a systematic mechanism for automating and reliably reproducing such "trustworthy builds" and codelines.

What might be some comparable sorts of concerns and solutions for building trust with V&V, or Systems Engineering?