The Machine Doesn’t Run on Theory

I recently sat down to chat with a company looking for help with a Scrummy / traditional / Agile-to-us / status quo / project manager / ScrumMaster type position. One of those common positions that companies open up to see what Agile looks like without actually changing anything at all.

As I sat down to interview with the two directors, given the obvious inconsistencies with Agile principles in the job description, I was there to vet them just as much as they likely wanted to interrogate me.

I wanted to hear about culture and team-centric work systems. They wanted to hear about control and tactics. You can imagine how the conversation went and a quote from one of the directors stuck with me:

“In the absence of specific tactics that you will use here, all you have is theory. And our business doesn’t run on theory.”

Clearly I wasn’t winning hearts and minds, right? How did I find myself up against a passive-aggressive slight?

Early in the interview, I was pointedly asked to describe the specific tactics that I would implement upon hire. In the absence of knowledge about the people, their feelings and needs, the culture, and existing practices, the only answer I felt appropriate was: “I don’t know.”

But, “as a skilled Agile practitioner” (yuck), I described three outcomes that I would be rigorous in pursuit of: teams, clarity of work, and working software. I shared multiple examples from different work experiences where we let Agile emerge and discovered a variety of practices that fit the people doing the work. In each case, while the “tactics” were different, the outcomes were similar: collaboration among teams, clarity and understanding of value, growth and discovery of knowledge, and sweet working software.

Them, with a waive of a hand: “Yes yes yes, we know all that. But how will you achieve that here? What specifically will you implement?”

I had to pause and enjoy a moment reflecting on a quote from Harrington Emerson:

As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble. — Harrington Emerson

I felt a bit like Charles Babbage and wondered what could provoke such a question.

It was clear that my friends on the other end of the long, imposing conference room table were going to make their decision based on which tactics best fit their narrative. I had a suspicion they knew what they wanted to hear; perhaps some combination of “increasing velocity”, “managing a team to deliver sprint commitments”, and other bits of abusive nonsense.

It was also quite clear that a commitment to transparency, meaningful principles of working together, and the resolve to build trust through working software was less than second-fiddle.

In the end, I didn’t get walked out of the office and engage in polite chit-chat to wrap things up. I didn’t get a moment of human interaction to shake hands. Rather, it was announced that the time allocated for the interview was expired, a brief thanks expressed for my time, and both parties casually left the room to go about their business.

As I walked myself out of the fancy office complex, I thought about four simple values and twelve principles that inform our behavior. As a strategy for thought, how many tactics and practices might emerge from collaborating together with Agile? Have we discovered them all?

Further, should we be weary of people who barge in with tactics and practices – even if they worked elsewhere? If one is uncomfortable suggesting tactics without deeper understanding of people and their involvement, is it just theory?

But, without question, if your organization is a machine, theory will not sustain it.