In Devs We Trust

The idea of getting certified in “Scrum” or “Agile” is philosophically unsettling to me.

It’s not so much that I think learning how experienced people execute these processes is a bad thing (I’ve even signed off on such a course for an employee’s career development aspirations), but rather the overtones of such a certification. Certifications are formalized recognition of program completion and endorsements of those that have done the completing. It’s like saying, “congratulations — you have rigorously followed the formalized, rigid process necessary to be agile!”

Why Certs Unsettle Me

Against the backdrop of the original agilistas rejecting button-up formalism for pragmatism and efficiency, this is sort of like a high school principal commissioning a “Responsible Pot Smoking and 3rd Period Ditching” course as part of the core curriculum.

The reason this is unsettling to me rather than comically ironic is that it supplies surprisingly fertile ground for re-growing all of the mistakes of the waterfall era by masking the true nature of those mistakes. The idea that it’s possible to nail down every last detail of a complex software system prior to writing it is cringe-worthy in its naivete (at least this side of a space shuttle), but it’s not really the core problem.

The core problem is the idea that a software project can’t succeed without planning every detail prior to implementation.

A Lack of Trust

This attitude belies a fundamental lack of trust in the people doing the implementation and, further, a suspicion that these people are incompetent malingerers. As an industry, we need to set aside a few high-wage “architects” to create a specification that will allow the drooling imbeciles, or “programmers,” to perform the mindless, labor-intensive task of writing software.

It evokes classic imagery of pyramid construction. Pharaoh and his great builders have the vision, and they just need whips, the wheel, and the backs of a few tens of thousands of fungible, expendable drones to make it a reality.

The fundamental problem with the waterfall approach isn’t that we want to plan out the pyramid but that we want to treat software developers like stone-haulers, as if implementing an efficient self-balancing tree were akin to pushing rocks.

Everything about this “classic” approach to software smacks of this fundamental lack of trust.

• Why plan everything out ahead of time in excruciating detail?
• Why come up with elaborate, painfully detailed processes and mind-numbingly detailed “design documents?”
• Why lay everything out in such a way that there is absolutely no room for creative license or spontaneous thinking?
• Why come up with CMMI level 5?

You do this to prevent people from “getting any ideas” and thinking for themselves — you do it because you don’t trust them (and you probably don’t trust them because you approached hiring them the way you’d approach finding cut-rate car insurance).

The Agile Manifesto, Revisited

If you go read the Agile Manifesto, you’ll see something that’s relatively vague, but underpinned by a consistent theme: “we work best when you trust us, collaborate with us and talk to us.”

It begs producers and consumers to back away from heavy documentation, plan, and process in favor of adaptability, collaboration and thinking on the fly. It implicitly asks that consumers of software trust producers of software and rely on their discretion.

Certs Miss the Point

So fast forward to present time and a world where you can depend on a thriving cottage industry to come in and bless your organization by making you “Agile Certified.” Why would you do this?

Why bring people in and have them tell your developers in specific, painful detail exactly how to conduct meetings and follow the processes that will allow them to be certified agile practitioners? Why spell out exactly how they can go about being agile? You do it because you still don’t trust them.

Scrum and XP are approaches that have merit because they generally consist of individual, specific practices and ideas that may help a team.

Pair programming/peer review, test driven development, making problems visible, etc are potential tools in the tool belt of a solid software developer. Agile practices/processes have value not because they’re the secret sauce that’s going to allow you to deliver version 6 on time where versions 1 through 5 have been lawsuit-inviting nightmares, but rather they have value when and because they force you to trust the software developers to get things done, to try hard, to provide honest answers and, generally, to be professionals.

There is No Secret Sauce

There is no up-up-down-down-left-right-left-right-b-a-b-a-start (I honestly did that without looking it up). There is no achievement to unlock, no box to check, and no certification to buy.

Organizations don’t get off that easily because what they need to do is much harder to quantify as a line item, objective, or KPI. Fortunately, hard as it is to package up and roll into an annual report, it’s really easy to explain.

Organizations have to hire software developers that they trust, clear nonsense and obstacles out of their way, keep them happy, and then trust them to develop software. That’s it.

I’m not saying this is actually easy to execute. Refining a candidate selection process to the point where you bring in competent, hard-working candidates with a high degree of certainty is quite a difficult problem.

Keeping them happy is no simpler. Setting them up for success just keeps increasing the difficulty level. And paying for all of this is really going to make you wince since it’s not possible to short-cut the system by bringing folks in cheap and then, real-quick, getting them certified in “you can trust this person to make good decisions about writing software.” Perhaps hardest of all, though, given our historical culture of micro-management and death-by-process, is actually doing the trusting.

Trusting the Dev Team is the Way Forward

But it has to be done. It’s the only sane way forward.

If you want to get a piece of software written, find some software developers you respect and trust and task them with developing software for you. If they know what they’re doing, they’ll figure out how to validate and verify their work, how to evaluate and improve their process as they go, how to limit distractions and work in progress, how to know when they’ve delivered on what they promised, etc.

They might do this by Scrum or by XP or by something that they invent on the fly, mixing and matching and innovating, but they’ll do it. They don’t need elaborate process or ceremony instruction and they certainly don’t need to be ‘certified’; they need you to trust them and let them work as they see fit.