Will We Ever Learn? Or, Old Habits Are Hard to Break

Spoke with my friend, Levi, recently. He works at a large company where the IT department develops internal products to support its operations and sales force. It also buys COTS products at times and modifies them as needed before installing them or having them installed.
His company has a large testing organization that is responsible for supplying and maintaining various test environments (and it also develops testing procedures and processes and supplies test people - know by the despicable term "resources” – a very poor euphemism for people.) Levi received a note recently from the senior leadership in the testing area wherein it was written that there were various insidious issues impacting the stability of various production and test environments. People impacted by these environment outages included internal and external customers, external sales people, and various IT department areas. The frustration level was (and still is) critical.

In my ScrumMaster classes, we watch Ken Schwaber's September 1985 Google talk video. From about minute 25 to about minute 40 in that video, Ken describes the historical process used to create what he termed "design dead software" - software and technical infrastructure that has become so fragile and lacking in quality over time that it eventually effectively collapses into a smoking heap of crap. The result is a company that fails and is either consumed in a takeover or simply vanishes.

The process of creating this type of brittle technical environment is fairly simple. First, people in the company (usually management with the proverbial sticks) demand that product be delivered by some usually arbitrarily selected date and that date typically does not allow for sufficient time to bake the technical pie to a qualitative state of “done.” Project management typically refrains from objecting to the inanity of the date for fear of being beaten with the sticks and it reaches into its “bag of tricks” to make magic happen and meet the date. I first learned of this infamous bag of tricks years ago from a project manager. The tricks include putting people on the death march (working overtime including holidays and weekends, etc.), insisting that people put other work aside to focus on the project work, putting more people to work on the project (in defiance of Brooks’ Law), and cutting short later phases of the work (most often in the case of waterfall, testing and Jerry Weinberg appropriately describes the test trimming problem in this fable from his AYE conference.)

That such insanity has endured for so long is a testament to the belief in magic. And to the technical community’s inability or lack of desire to stand up to this contemptibility. Schwaber and others have long insisted that agile approaches and the agile cultural phenomenon emerged as a counter to the enduring legacy of this hideous problem. He has insisted (and there is no reason to doubt him) that Scrum was created to bring professionalism, honor and respect back to IT workers. The problem has been that no one has addressed the big elephant in the room: traditional scientific management and its desire for absolute predictability. Discussion of this problem can extend to a myriad of paths, but the bottom line is that as long as traditional management exists in academia and in practice, efforts to change long-standing organizational cultures will largely fail. The market place will eventually do what we cannot. Stephen Denning describes this need for transformation in his excellent work The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century.

Levi has spent 7 years trying to influence, change, cajole, impact, and manipulate an existing traditional corporate culture in an effort to adopt (or at least contemplate adoption) of an agile-based culture. Alas, he reports that the results have been marginal at best, highly repercussive to him personally, and futile for many people in his company who were optimistic (perhaps as seemingly naively as him.) Levi still holds out hope, but it has seemingly diminished much lately.

So, his people are left to their usual devices in tackling these environment problems and others in the usual manner by the usual application of reductionism and fix by patching, along with date bets and velocity bets that increase the likelihood of eventual design dead software. Then, someone might be able to swallow up this currently proud company or it might just go extinct. Time will tell.