Dogma

Note: This wasn't really what I planned for my first post here. I have this whole "anti-business speak in IT" thing I've been thinking about for months, but I felt the fire last week and went here instead. Boom?

There's a groundswell of support for pragmatism in agile software development. And why not? There's definitely a compelling argument that agile principles necessarily promote pragmatism, and I'm not going to hammer away at my keyboard denying this. The problem is, though, that in every organization I've seen, pragmatic turns into sometimes, sometimes turns into never, and never is amongst the dirtiest words in software.*

My organization was engaged with an agile-leaning software consultancy for about two years, with most of that time coming before I joined this noble band of  nerds. Upon their departure, I made my best effort to appear receptive to feedback and had a chat with an extremely intelligent and extremely proficient software engineer to discuss my job performance and other Things That Are Important Now That I'm An Adult. I was surprised by his comments. Rather than criticizing my sardonic management style or penchant for accidentally scheduling meetings in the wrong time zone, he made a plea.** Excuse the misleading quotations; this is not a direct quote, but I nevertheless wanted to make it appear conversational, because that's apparently how I am:

"Your organization has achieved success. But the success has brought laziness. Your developers are avoiding pairing. The business analysts are writing stories without QA input. Your QAs are rejecting stories without talking to the devs. At least one team hasn't had a retrospective in over a month.

All of the success the department has had over the last two years has been predicated on knowledge, whether it's knowledge shared between pairs or knowledge shared across the business. Do not allow "pragmatism" to infiltrate your teams. Be the person who upholds agile principles with conviction because success will minimize the organization's value of retrospectives, of showcases, and of pair programming. You always talk of how wonderful your mentors have been. What would they do? Be them now."

The aforementioned consultancy is frequently accused of being dogmatic to a fault. And, perhaps, it's true. The PMs who trained me insisted on biweekly iteration planning meetings, showcases, and retrospectives. They demanded dev huddles, daily standups, and thorough acceptance criteria. They added ACs like "Given that I am a developer who cares about quality, when I am working on a story, then I will write JS unit tests."

But they also defended core hours. They impressed product management. Most importantly, they delivered. And delivered. And delivered. Where our department had previously failed our clients, again and again, we started delivering high quality, high value software. We moved engineers between teams without sacrificing velocity or quality, we adapted to scope and requirements changes, and we got along. We sang karaoke. We drank beer. We watched the Kings win the Stanley Cup (well, I did, at least). Because we embraced the ideas behind the dogma, it stopped feeling religious and started feeling right.

"Pragmatic pairing" and "as-needed retrospectives" are a bad solution to an inevitable problem: every software shop is understaffed. Yes, it is absolutely possible to increase velocity by reducing the amount of time developers spend pairing, and yes, reducing meetings like IPMs and retros will increase the amount of time your devs can spend in Visual Studio. But the process has proven to be unreliable and unsustainable. Knowledge will be lost when your senior engineers wander off into the weeds to solve a problem while junior engineers implement the same feature toggle they've implemented 100 times before. Personalities will grind when the retrospective prime directive is not recited and retros, when actually held, will turn into performance reviews rife with ad hominem attacks and, yes, existential angst.

So when your team starts talking about pragmatism, address the underlying cause and move even further towards the dogma. Your clients will thank you and your devs will...well, they'll get it. Eventually.


*The dirtiest phrase, of course, is "scope creep." The horror!

** He also told me to start acting more seriously when people come to me with problems. Apparently, my flippant attitude isn't particularly comforting for the techies, although the business folk seem to enjoy it. I'm still an engineer, I guess, and the years of losing to math exams have created a coping mechanism in cynicism.