A Couple of Thoughts About “Standard Agile”
Lately I’ve been hearing a lot about standardization of Agile methodologies, and while some of the discussion may be well-intended, I feel the trend isn’t a healthy direction for the Agile movement. My concern is that it reveals a reverence for manufacturing which doesn’t help teams and managers when implementing Agile practices. Nick Oostvogel recently wrote,
“Do we dare pretend to be better than the factory folks, which have multiple times the industry experience than we have in software development?”
As a matter of fact, we do (or we ought) to dare to be different from the “factory folks.” The concept of an hypothetical list of standards may be fine, depending on how they are applied within an organization. But a loose set of process guidelines is miles apart from the process management that goes on in manufacturing, which is as it should be.
Manufacturing processes classically emphasize dense, in-depth decision streams before the assembly line is set in motion. In agile software development the building and the designing happen simultaneously: thus the decision stream is constant and concurrent with the process. In fact, in software engineering you might even say that the decision stream is the process. To improve software development is to improve the process in which good decisions are made.
In the classic manufacturing model, decision making is confined to a relatively small number of process engineers —those who will actually carry out the processes have little involvement in making the decisions they execute. In software development there is no factory floor. If there were a way to map that part of the metaphor, it should be the applications and systems being developed, not the process of building those apps and systems. Consequently your rank-in-file developer has more in common with a manufacturing process engineer than he does with the factory worker on the line. To blindly apply the manufacturing model to software engineering is to embrace a solution in search of a problem.
If we point back to manufacturing as a general model for software development we promote heavy, up-front design, rather than encouraging an agile mindset which values lightweight and easily modifiable processes over wasteful standardization across an organization. We in software engineering need to think more about the human decision makers involved. These are considerations which have no particularly helpful ancillaries in the world of historical and mainstream manufacturing. I’m not knocking Lean or Toyota —quite the opposite. The concepts we draw from Lean are helpful precisely because they are revolutionary when compared to the manufacturing industry as a whole.
