I remember touring preschools when my daughter was young, with one preschool after another professing their strict adherence to Montessori, Reggio Emilia, or Waldorf education methodology. When a director told us “we don’t stick to one methodology, we try to merge the best out of all of them for the kids we have in the classroom,” I knew I had found the preschool for us. With all due respect to Maria Montessori, I just don’t believe that set guiding principles invented by a person in Italy in 1912 is going to be successful when applied to a T to a group of California babies born in the 2010s. Too many factors have changed.
I think about this when I hear about agile methodology being revered like a holy grail. I can’t help but wonder: what do we gain by strictly following agile methodology? What do we lose? And what if we approached agile methodology, well, agilely?
In his paper "Characterizing people as non-linear, first-order components in software development" (4th International Multi-Symposium on Systemics, Cybernetics, and Informatics) and further explored in his book People and Methodologies in Software Development, Cockburn formulated the idea that “people are devices with non-trivial operating characteristics, and so the design of methodologies — systems whose components are people — cannot be trivially performed using classical systems design techniques.”
“The original reason for writing the paper was that I kept hearing from people trained in systems design words to the effect of: ‘Systems design has been an area of study for decades, and we know how to design systems with recursive structures and feedback loops. There is nothing new about designing software development processes: Merely apply systems design thinking, and it will all fall into place.’
That line of reasoning has a flaw. People in the systems design field characterize the components they use in the system: resistors, capacitors, transistors, electromagnetic devices of all types. Knowing the characteristics of these devices, they can combine them with some assurance that the resulting design will behave within some specified tolerances. However, the active devices in software development are people, devices with no well-understood operating characteristics. Worse, people have tremendously non-linear operating characteristics, which vary widely across individuals. Systems designers constructing a system design using these complex designers cannot be assured that the system will respond within specifications.”
Unlike components with predictable behaviors, people can vary dramatically across individuals and further still across groups of individuals. Cockburn reflects on the 23 projects he studied for his research:
“What I find striking about these projects is that they show:
- Almost any methodology can be made to work on some project.
- Any methodology can manage to fail on some project.”
Just as every kid has a unique learning style and background, every software team has unique dynamics, expertise levels, and communication styles. The idea that one rigid methodology could optimally serve all these variations seems, when you think about it, rather absurd.
This doesn't mean that methodologies like Agile are worthless. Agile principles like iterative development and regular feedback loops are fundamentally sound. The trouble starts when we treat these methodologies like gospel rather than seeing them as tools in our toolkit.
It's the people that make or break a project, not the process. The methodology stuff is secondary. So next time someone insists there's only one "right" way to do Agile (or anything else), remember that success isn’t measured by how perfectly you followed a methodology but by whether you built something of value with a team that’s still excited to come to work the next day.