Revisiting Systems Thinking
By Nicole Radziwill

On Monday, April 16th, Clare Crawford-Mason visited ASQ Section 1131 in Winchester, VA as the guest speaker. Clare is the journalist who originally produced the 1980 documentary, If Japan Can, Why Can't We? That introduced America to Deming's philosophies of management as they had been applied to reinvigorating Japanese industry after the Second World War. After producing this documentary, her next project was the Deming tape series, which is now a focal point of many college management courses. Today, Clare works with her company Management Wisdom (http://www.managementwisdom.com) evangelizing the messages of lean production and systems thinking, and helping companies apply the approaches of both Deming and Ackoff to yield benefits in operational effectiveness.

Although the session was not about software, I couldn't help but think about how the concepts and examples Clare provided apply to our area, even though many of those examples were derived from social sciences. For example, she described one documentary that she was involved with in the 1970's, which examined spousal abuse. Instead of treating each occurrence as a single isolated event, which had been the approach by social workers in the past, Clare took a look instead at the personal history of each abuser. Many of these individuals had come from families where there was domestic abuse, and so had been influenced by that history. She also noted that the children of abusers tended to be abusive as well. By examining the root causes for the abuse by applying systems thinking, she was the first person able to both determine and convince America that interventions should be applied to the whole system of the extended family to "stop the cycle" of abuse.

What we can learn from this example in software development is that finding the solution to a problem we encounter may require understanding the system in which the software is being developed. In additional to functional requirements and quality attributes, there are interpersonal, team, organizational, financial and political factors to consider when a group of people comes together to develop software. In my work right now, we're developing a desktop application that needs to be ready in five years, and we're having a difficult time handling terabyte-sized files unless we run the software on a cluster. Of course, people do not have clusters on their desktop right now. However, thinking of the system in which this development takes place, we can see that all we really need to do right now is demonstrate functionality, and this can be done by offering our test software as a service on a high-powered machine. We are relaxing one requirement now in order to focus on what really needs to be delivered now, rather than slipping our schedule by trying to solve both problems at once. There is another example where our organization has been trying to co-develop a software application with a team in Europe, whose political environment makes it very difficult for them to collaborate with other groups. In the past, we've tried convincing them that some of the components we offer would really help them in development, but these efforts have been marginal at best. But by offering them several tens of thousands of dollars of services, however, their political environment magically opened up and invited our participation as collaborators. When we looked at the system in either of these cases, non-technical solutions became apparent.

Clare spent a great deal of time discussing the Toyota Production System, a tightly integrated value chain that helps Toyota achieve the greatest productivity (in labor hours per vehicle assembly) in the auto industry. In addition to this tight integration, and very close relationships with suppliers, Toyota assumes that imperfection is the norm and there is always room for improvement. She noted that this culture is vastly different than most companies in the U.S., even those who espouse quality initiatives and quality programs, because we are too often looking for someone to blame when problems arise, rather than attacking the problem itself as a part of the system in which it lives. Software development can also be viewed as a value chain, whether structured or agile methods are used. Requirements are produced and gradually become part of the final product, which then may be deployed once at a company, or packaged and distributed to users. A "tight" value chain is the equivalent of close customer collaboration in the development process, coupled with effective, complete training that helps ease the transition from the release to having the software in active use.

The moral of Clare's story was to invest more in systems thinking as part of your daily routine, and you, your team and your users will reap the benefits!