DaedTech

Stories about Software

By

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!” 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.

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).

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.

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.

SwankyToolBelt

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. 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.

newest oldest most voted
Notify of
Runar Ovesen Hjerpbakk
Guest

Excellent post!

If you don’t trust your developers, all is lost.

Erik Dietrich
Guest

Glad you liked, and completely agreed. I can’t imagine why you’d want to put important initiatives, much less the lifeblood of your business, into the hands of folks you don’t trust.

Amitai Schlair
Guest

I can’t imagine doing that either, but given that many people seem to, my best guess about why: their expertise is in something besides software development, they’ve never worked with software developers who’ve earned their trust, and they have neither a model for what trustworthy developers would look like nor an expectation that such people exist. Given these assumptions, I’d take my best guess at what we could do to quickly start earning trust. And of course that’s to organize the work so that we can start delivering something early and often. Which I almost always want to be doing… Read more »

Erik Dietrich
Guest

Yep. I think that’s exactly right. I have conversations with clients of mine here and there that amount to them fretting over what a leap of faith it is to commission software. And I windup saying something along the lines of, “let’s make it not a leap of faith. I don’t know how long it will take me to deliver what you’re asking, but what I can tell you is what I can deliver you in the next couple of weeks, and you can size it up from there and see if you like where it’s going. If you do,… Read more »

David S
Guest
David S

Very Nice! The team I’m on now has a development process which could never be formalized as Kanban, Scrum, or XP, but still manages to hit all the points of the agile manifesto. I doubt its the BEST possible solution, but its a darned good one. I guess I’m deeply sceptical of formal Scrum training in particular, just because I’ve worked for a couple organizations where “switching to scrum” was imposed from above by management….. which in the end, just meant taking their in-place waterfall process (or perpetual emergency process), and renaming the elements of it with scrum buzzwords. In… Read more »

Erik Dietrich
Guest

I think your last sentence really nails it. I’ve seen shops that do what you’re describing (mapping agile buzzwords onto waterfall processes) and the lack of trust always seems to be at the center of it alongside the fundamental assumption that the biggest barrier to success is non-technical managers not having enough fine-grained control. I think there’s something to be said for picking a methodology like Scrum and trying to adopt it wholesale (rather than, say, just picking a handful of things from it). But that’s only if the team buys in and drives the change and it’s only if… Read more »

Amitai Schlair
Guest

That ties into the idea that everyone who’s developing and delivering is always developing and delivering incrementally. It’s true whether or not we intend to be, whether or not we’re even aware that we are. Given that it’s true, maximizing our effectiveness depends on our being aware of it, so that we can observe how increment size affects our outcomes, so that we can choose increments with intent to maximize our outcomes, so that we can maximize our outcomes. I find the concept a beautifully clarifying one. I wonder how well it works for folks who haven’t already learned all… Read more »