SeaSpin

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."

The slides are up at: http://seaspin.org/files/folders/2009presents/default.aspx

I'm happy to hang out here and continue the discussion if anyone's interested. Three things on my mind to start:

- We never did get to the second example. I think the talk is naturally about 90 minutes, really, allowing for the questinons & discussion that happen. (2x in a row, so it must be true.)

- I have notes for a Rev. 2.0 based on what I learned in giving the talk. If anybody knows of somewhere to present it, that'll ensure that it gets done.

- Yes, there's a follow-on talk, breaking down the "change Kanban" and expanding on why it seems to be that way.

Net: Hard to learn more than one thing at a time. Multiple changes create questionable data. Takes a while to learn something - several trials. Last, establishing a common understanding of how things work, or convention of how you'll work together really takes the whole team.