I was training a fairly successful multi-national software company on agile estimation and planning several days ago and a question popped up at the start asking why is agile better than methodologies used in the manufacturing industry? Why is it better than mil-std-498, a standard that promoted iterative development and focuses on quality? Isn’t that what agile claims to do? In essence, why are we reinventing the wheel instead of taking what’s already establish for centuries in the manufacturing world through countless trial & error and proven to be effective? Those are really good questions and ones that I, myself, have asked before, and a lot of people are still asking.
Software is a relatively young industry compared to manufacturing. So, it is logical for software professionals to learn from the experiences and processes in manufacturing. In fact, many software PMLC and SDLC processes were adopted from manufacturing. When it came to agile, it is no different. Methodologies such as Kanban have deep ties to manufacturing world. However, there are many different processes in manufacturing and not all of them apply to software development. Some manufacturing processes focus on streamline the assembly and improve repeatability of producing the same widget over and over again. That doesn’t map well to software development as every application is different from the one before. Software development is an innovation and research process, so software development is more similar to scientific research or design in the manufacturing world. In addition, agile is more than developing software iteratively. Iterative Waterfall is also iterative development, and the one encouraged by standards like Mil-Std-498, that addresses one important aspect of agile which is doing things in smaller pieces. But it still emphasizes on documentation over working software; contract over collaboration; fights against instead of embraces change; and most importantly, processes and tools over people. So, YES, we should learn from other industries like manufacturing so not to reinvent-the-wheel AND adopt them to software development’s unique characteristics to make the wheel better for our needs.