Why Methodology Matters

Software methodology is easily most practitioners least favourite topic and yet I have devoted a better part of my career to studying and deploying software methodologies. I often like to explain why I have followed this path by citing a wonderful case study that comes from the auto industry, specifically the New Unified Motor Manufacturing Incorporate (NUMMI). This facility in Fremont California is now where Tesla manufactures its cars but it once was a General Motors facility. It was also reputed to have the worst workforces in the auto industry and the plant was closed in 1982. By 1984 it was re-opened as a joint venture between Toyota and GM, and had one of the highest quality ratings and productivity in the industry – with the same workforce. What changed was how people worked together to get the job done – their methodology.

When I use the term “methodology” I’m not talking about bureaucratic prescription of practices, roles and artifacts and then forcing everyone adapt their work practices to the methodology. Neither am  I talking about the puritanical enforcement of practices and narrow focus  often seen in so called agile methodologies. Rather I am talking about creating the shared clear understanding necessary for people to effectively work together and create value. I am talking about people knowing what they need to work on, who they need to work with, and how to effectively get the job done. Most importantly I am talking about people taking ownership of their methodology and not being forced to abdicate that responsibility to some obscure “center of excellence”.

When I reflect on my career and compare the more successful and more enjoyable projects to the ones we slogged through, and the projects that were outright disasters, the differentiator was not technical engineering talent, rather it was how well we worked together and how quickly we could learn and adapt. It didn’t matter if we assembled a team of superstars, if they could not work together to get the job done, then the job didn’t get done.

An interesting case study from my own personal experience, helps illustrate this point. I was part of a team parachuted in to a major industrial manufacturer to help recover a failing project. They were at the tail end of a long waterfall project and for a lack of better words, flailing badly. Defect opening rates were way higher than defect closing rates. People would work long hours on a critical defect, only to be interrupted and dragged off to a new higher priority crisis. The project deadline was looming and this was no mere presumed date on the calendar, failure to deliver by the deadline date, would mean total failure.

The project was shut down for two weeks to introduce a different methodology. During those two weeks the teams were re-organized and most importantly, trained together. Then in a mass “release planning” event, work was prioritized and collaboratively re-planned.  With the restart of the project, people’s attitude changed from “we are all doomed” to “we may have a fighting chance”. The project was delivered.  I will not claim any magic methodological silver bullet or personal brilliance for this. A lot of people worked massively hard and long hours to deliver. However, what I will claim is just like NUMMI, changing how people worked together, and how they think about their work – their methodology – created the opportunity for people to go from failing to delivering.

This is why methodology matters, why we need to think about it, and this is why I write about it.