Warning to IT – the Japanese industry that gave us the seeds of modern software development methodologies (Lean, Agile) are seeing their models fail. Why? In part, they reduced testing, cut skilled, experienced personnel in favor of less expensive labor, and essentially rubber-stamped inspections (or worse). Lesson: modern methods don’t change human nature. Quality assurance and independent testing remain as important as ever.
This WSJ article (subscription required) caught my attention because it reminds me of the Japanese heritage of our modern software development approaches. Kaizen – continuous improvement – is at the heart of Agile, Lean, Six Sigma, and IT shops’ ISO-9001-based Quality Management Systems.
Something that has bothered me for a long time when Agile is held up as the end-all, be-all of software development is that the results of Agile work when compared against that of other, older, traditional development methods is often not a level playing field. Those results often contrast a team of rock star developers using Agile with let’s just say a more diverse group from a skills and experience standpoint using a traditional SDLC. What AEGIS sees in our testing of Agile programs that have transitioned from traditional ones using the same team of developers is that the overall number of defects isn’t remarkably different from what it was under previous models. There are other benefits to Agile, of course, but lower defects isn’t necessarily one of them. On the other hand, where a client has brought in a whole new team of “senior” Agile developers – their results tend to beat out more average teams of developers under older models. My theory is that the difference in defects has less to do with the development methodology and more to do with the make up of the teams. I believe a team of rock stars will outperform an average team regardless of which model either team uses (I’d love to be directed to any studies out there that address this topic).
The WSJ article points to a potential reason: companies tend not to continue to invest in rock star teams but shift to what might be called commoditization of developers and development teams as if they were procuring the least expensive paper clips. Why would this matter? The methods introduced and refined by the Japanese manufacturing industry shifted a fair degree of power and control over the manufacturing process from management to the front line workers on the shop floor. In IT, that would be the developers, testers, and operations staff. This worked well when those organizations staffed the positions with what the article refers to as craftsmen with long experience at the company. But as the article points out:
“The problem today is that many Japanese companies can no longer afford the luxury of guaranteed lifetime employment for craftsmen on factory floors. And delegating so much authority to line workers has left companies exposed to fraud and corner-cutting, while giving executives room to shirk responsibility, according to management consultants and corporate lawyers knowledgeable about the problems.”
I would challenge the notion of not being able to afford craftsmen. I wonder if in retrospect some of the companies named in the article would like to go back and handle their staffing decisions differently.
When cost-cutting happens in any business, there are trade-offs. The article describes that the Japanese manufacturers replaced craftsmen with less skilled labor and shifted policies away from true quality assurance to what amounted in some case to little more than rubber stamping of quality assertions. The results have included massive product recalls, scandals, and even bankruptcies. I wonder how many of us in IT recognize that pattern? IT needs to take this latest lesson from Japan to heart no less than it did the revolutionary Kaizen message and rethink the importance of skilled, experienced staff and a culture of true QA through independent testing.