Gatekeeper is a collection of concepts, techniques and stories about managing the software development gates on a wide range of development teams, including: operating systems, network management, system management, graphics, compiler, firmware, e-commerce, big-data systems, embedded systems, and consumer products.
Can you hear me know? What if we setup our flow to look like that classic Verizon commercial? At the end of the commercial the technician is facing you the viewer, with an entire organization behind him, ready to assist. What if in our context, the technician is the developer, and the organization backing the developer is the rest of the engineering organization? What would that look like?
In a typical software development flow, what percentage of activity once a developer checks code into the repository are symptom identifiers? Continuous Integration is a symptom identification process that often is owned by the build and release team. A build fails, that is a symptom of what? A test failed, that is a symptom of what? Resources are not available to perform an integration, that is a symptom of what?
What if we delivered a build process and supporting environment into development that ensures a build rarely fails during the integration process?
What if we delivered a test harness and supporting environment into development that ensures a test rarely fails during the integration process?
Processes that occur once a developer checks in code would no longer be symptom identifiers, instead they are now audit processes. What is the difference? Symptom identification type process are unpredictable, create unplanned context switching, and do not scale. Audits are an assessment of the process that produce the results. In the “Developer Enabled Flow” the success criteria is delivered into the Development Team.
If we did an audit of all the processes that comprise our product life cycle, what percentage of processes are symptom identifiers? Are we measuring and automating bad processes?
Leave a Reply