Neil Thompson is a UK-based independent testing consultant and manager, serving blue-chip clients through www.TiSCL.com, either directly or with other consultancies. Co-author with Paul Gerrard of 2002 book "Risk-based e-business testing".

Neil has worked for 30 years in information systems, first with a computer manufacturer, then two leading software houses, an international user organisation, followed by ten years as a management consultant with global firms and nine years with his own company.

Has a wide and international perspective on the IS business, through diverse roles including programmer, systems analyst, team leader for enhancements and maintenance, database administrator, and project manager.

Member of British Computer Society (and its specialist interest groups in Software Testing and Configuration Management), also a Certified Management Consultant and IEEE member. Neil spoke at the first EuroSTAR in 1993, then again in 1994, 1999, 2002 (with Paul Gerrard), 2004 (best paper award) and 2006. Also spoke at STAREast in 2003, attempting to build a bridge between “best practice(s)” and the Context-Driven School.

Neil is still old enough to appreciate The Bothy Band and Horslips.

Thinking tools: from top motors, through software process improvement, to context-driven

Toyota has risen from being merely a reliable motor company to an innovative world-leader. Just In Time has come to dominate supply chains. Can software development learn anything from these successes?

Neil Thompson argues that it can – and he goes further, drawing together elements of three different presentations given previously at EuroSTAR, EuroSP3 and STAREast. Although there are obvious differences between manufacturing and software development, there are powerful analogies between inventory and flow of value. Goldratt’s Theory of Constraints is similar to Toyota’s “lean” principles, but Neil believes it has the advantage of superior thinking tools, developed by Dettmer to complement Goldratt’s principles. For software development and testing, “lean” equals agile to most people, but can even traditional methods learn and apply some improvement principles?

The constraint in a system is its weakest link; the thinking tools help improve that, at which point another link becomes weakest, and is improved in turn, and so on. Applying this to software process improvement may be better than fixed, prescriptive maturity models.

And finally – the principles of process improvement may be extended to define “appropriate” processes for any context.