A wonderful case study I like to cite comes from the auto industry, specifically the New Unified Motor Manufacturing Incorporate (NUMMI). This facility in Fremont California where Tesla now manufactures its cars was once 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. I’m not talking about heavy documentation driven processes and stage gates as seen in traditional methodologies. And I am certainly not talking about the puritanical enforcement of practices and narrow focus as 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 get the job done. Most importantly I am talking about people taking ownership of their methodology and not forced to abdicate that responsibility to some obscure “center of excellence”.
Of course most sane practitioners are generally not interested in methodology because they just do not see how methodology is useful in helping them get the job done. They just want to get down to what they do best, working on cool projects with cool tools, languages and systems. Working on cool projects with cool tools, languages and systems is exactly why I got into this field almost 35 years ago. Some of my best work experiences are from mastering the technology to create digital switches and railway signalling systems. It’s what got my blood pumping, it’s what got me up in the morning…working with great colleagues, learning new things, and creating cool stuff. Yet for the last 15 years I have built my career around understanding, developing, deploying, and evolving software methodologies. So why did I start devoting so much energy to a topic that makes me less popular than a project manager at nerd social gatherings?
Simple, I began to see how important methodology is to project success. When I compare 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 trained together. Then in a mass “release planning” event, work was prioritized and 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 changing how people worked together – their methodology – enabled people to go from flailing to delivering.
This is why methodology matters, why we need to think about it, and this is why I write about it.