Data-Driven, Experiential SPI
So much SPI is evangelism, attempting to impose the one true way from outside. That tends to fail, and creates at best compliance.
Process improvement that works treats SPI what it is - a kind of experiential learning, centered on the team doing software development, supported by data about the local practices & results. The team learns how to do things differently, perhaps drawing candidates from an external catalog of techniques.
This talk draws from about a dozen personal experiences with process & practice changes plus industry examples with reference to antecedents like TQM, and Deming and current frameworks like "Lean" and Critical Chain.
Supporting the fact of change
"Your process is what you do"
Process development is knowledge formation.
Relevance: mission and data and mission and data and ...
The talk finishes with a strategy that works for explicit, ongoing SPI.
This material is part of a Jim's future book "Change in Technology Development Organizations: Learning On Purpose".
Bio
James Bullock has been successfully building systems for more than 20 years. In that time he has built high-volume embedded control software, automated plant-floor manufacturing, architected enterprise data warehouse systems, created tools used to manage multi-million SLOC tactical and commercial systems, run technology departments in Internet-based businesses, and shipped multiple releases of innovative SW products for the enterprise.
Through this varied experience, James has remained more interested in how systems are built than in the systems themselves. He has written on subjects such as the development system as a system, the value of testing as a function in a business, software tools and methods in e-commerce, database performance tuning, and how software projects differ from other projects. He is the lead editor of Roundtable on Project Management and coeditor of Roundtable on Technical Leadership, both published by Dorset House.
A Seattle resident, since 2002 James has focused on "conscious software development" guiding clients in purposefully changing how they develop the software they depend on. He is currently developing presentations of general systems thinking in software engineering practice and teaching. James still occasionally builds software or does automated testing because, he says, "I like the toys."