Greg Jorgensen writes at Typical Programmer about a vexing question: “Why don’t software development methodologies work?”

Whether a methodology works or not depends on the criteria: team productivity, happiness, retention, conformity, predictability, accountability, communication, lines per day, man-months, code quality, artifacts produced, etc… I haven’t seen any methodology deliver consistent results…

Imagine two teams of programmers, working with identical requirements, schedules, and budgets, in the same environment, with the same language and development tools. One team uses waterfall/BDUF, the other uses agile techniques. It’s obvious this isn’t a good experiment: The individual skills and personalities of the team members, and how they communicate with each other, will have a much bigger effect than the methodology.

Jorgensen’s point reflects a rigor in thinking that’s often missing from the essentially religious arguments about development methodologies. Represented another way: if the methodology you use in development is 20% of “whether it works,” the rest of the variables are 80%. You may be optimizing the wrong part of your process; the impact could be much greater from changes to other aspects of your organization (imagine how many flailing managers ignore the happiness of their people while agonizing over whether their “scrum master” is certified!).

Jorgensen goes on to discuss some of the consequences of what we might call political rather than product thinking. Clear ownership and control is

…reduced to “stakeholders” and “users,” and then abstracted away into “user stories.” It’s common now for me to get involved in a project that seems to have no adult supervision…

Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion. The resulting passive-aggression kills productivity faster than any methodology or technology decision.

It’s a simple and indeed inevitable substitution: once adherence to a system becomes a value, clericalism reigns while the values originally sought by the system are masked. Power and control concentrate around process; disembodied projects labored on by disaffected engineers slotted into some new system’s rules are the result, and they tend to be bad.

At Mokriya we’re especially interested in process, and in how an “ecumenical” approach to process can function as a flexible meta-process, so to speak, that we can use to meet every client’s needs. For us, then, the most arresting part of Jorgensen’s article was this observation about what does work:

My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process…

I think programmers should pay much more attention to listening to and working with their peers than to rituals and tools…

While Mokriya’s meta-methodology remains something we tinker with —and while we still prefer Agile to BDUF— Jorgensen’s advisory seems to support our belief that nothing is more important than hiring well. Unfortunately, nothing’s harder, less predictable, or more inscrutable.

As yet there’s no real shortcut for the sort of hiring process that yields a group of collaborative and yet autonomous developers, self-directing but also interested in organizational holism, communicative and possessed of “conceptual integrity.” That’s why our founders still interview every hire, and likely will even as we continue to grow.

For us, methodologies are useful systems, not faiths; and the optimization of our process involves more than adopting this or that dogma. The natural conceptual integrity that results from a really well-selected group of colleagues who “just click” with each other cannot be over-valued; it obviates the need for lots of organizational labor and management, and it makes methodology a lot less important. So while we’re Agile, we try to be much more than that; merely being Agile is no guarantee of success, especially if you neglect other variables in your culture.

Mills Baker