Virtues of the Oath of Non-Allegiance


Posted by Dana Craig November 02, 2010

It’s not often that we’re encouraged to pledge non-allegiance to something. After all those years of standing in front of the flag each morning at school, hand over heart, reciting along with everyone else, it may take some getting used to. 

Scratch that – I’m over it already. Let my inner-rebel flourish. 

Several months ago, Alistair Cockburn, a key contributor to The Agile Manifesto, started promoting his Oath of Non-Allegiance:

“I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.”

I can’t say precisely what prompted Cockburn to put the oath to paper, but the minute I read it, I knew exactly what it meant to me. While it strikes me that the Oath of Non-Allegiance could be applied to almost all aspects of life, I’ll leave that discussion to the arm-chair philosophers amongst us. For me, I was looking at it from the standpoint of technology and IT projects.

My partner and I talk considerably about how to approach IT projects, what makes them successful, and how to make sure we aren’t getting stale. The Twinkie might be just as tasty after sitting on a windowsill for decades (or so urban legend has it), but innovation and technology weren’t dosed with as many preservatives. We have to stay fresh in other ways. 

“The Twinkie might be just as tasty after sitting on a windowsill for decades…but innovation and technology weren’t dosed with as many preservatives. ”

When approaching a project, make sure you understand the business problem. While that may sound like an unnecessary statement, clients are often so submerged in the problem that they come to you with a solution in hand, ask you to develop it, and work begins right away. You take comfort in the fact that you’re doing exactly what they asked for, and assume that as long as you continue in that vein, you’ll succeed. Seems reasonable enough. But that’s where the disconnect is – the client is a collective. While you might be able to convince the people you interfaced with that the solution succeeded, the direct consumers will only be convinced if the technology resolves the business problem.  

Take the time required to really understand the problem, challenge the client’s assumptions, and make independent determinations about the nature of the problem. Will the proposed solution really solve it? If not, why not, and how can you engage the client in a synergistic discussion that will achieve the best result?

The Oath of Non-Allegiance assists in the phase of understanding the problem because it suggests giving equal weight to the explanations and the possible solutions. The Oath’s virtues really kick in, though, when you move to the next steps.

Picking the Right Tool

There are so many different development languages available, not to mention the tools that assist developers in using them (ie., you can develop without gaining fluency first). What tends to happen is that developers hunker down in a few different languages, convincing themselves that all problems can be solved with the tools in their toolbox. 

When I was in college, my toolbox consisted of one lone hammer. What couldn’t be done with a hammer, didn’t need to be done – or so was the contention of my erstwhile thinking. Then came the day when I wanted to hang new curtains and needed to install the curtain rods. A friend told me I needed an electric drill, but not only did that not fit my budget, it also didn’t fit my timeframe. I needed instant gratification! Plus she had never done this before either, so why would I listen to the electric drill idea?

So, out came the hammer and I began to pound away. I’ll spare you the details. I can confirm, however, that a hammer will indeed work to install a curtain rod. But was it the best tool for the job? Did the results show a level of knowledge and expertise? Would someone pay me to do it again?

The challenge here is to take the time to consider what the best tool is for the job. It doesn’t matter if you own the tool, know how to use it, think it’s expensive, or don’t like it for some esoteric reason. Those are considerations to be weighed later. For now, open your mind and focus on the discussion of the best tool.

Picking the Right People

Ever worked somewhere where the ‘right’ people were the people who were available? Sure, we all have. The person who does the scheduling has a blank calendar, X resources, Y projects, and away they go filling in the blanks. In some settings, this approach is effective, convenient, and reasonable. With a technology project, it may help you get things done, but probably not with high quality.

Picking the right people takes adherence to the Oath of Non-Allegiance in the same way that picking the right technology does. There are usually one or two superstars in most organizations, but that doesn’t mean they’re always the right people for the job. The challenge is to match task to talent, rather than just pigeon-holing people in one spot.

It’s that type of thinking that means we’ll always see Kim Fields as Tootie and Maureen McCormick as Marcia. Stereotyping in TV and movies comes from the thought that, “We were successful with this before. The same formula will work again.” 

If the audience is the same, you might be able to get away with that; otherwise, you need to rethink your assumptions. Really look at what skills and traits are required for the project in front of you; talk to staff about how they view the project and what role they could play. Be open to trying a different ‘formula’ when the situation warrants it and then provide people with the support to achieve.

Being Willing to Reconsider

A guy went to see the doctor. Once he was in the exam room, he said, “Hey, Doc, it hurts when I do this.” The doctor said, “Well, then stop doing that,” and walked out. An oldie, but a goodie.

The lesson is, if you aren’t getting the results you want, be willing to stop doing what you’re doing. If you’re into the project and decide you made a mistake, or could do a better job by changing a few things, be confident enough to acknowledge that. Discuss it with the client when appropriate and be prepared to adjust quickly.

If the problem doesn’t marginalize the outcome of what you need to achieve for the client, then make note of it to discuss with your team during the project debriefing. When you meet as a group, be hard on yourselves. Even if the project was a success, challenge yourselves to discuss what could’ve gone better. Be vigilant about determining why you succeeded. The reasons for failure are typically more obvious, and certainly must be discussed. It’s equally as important, though, to explore why you succeeded and recognize how future landscapes may not support success in the same way.

Using the Oath of Non-Allegiance as your guide, you can continue to forge new paths and disabuse yourself of the notion that there is a formulaic approach to solving business problems with technology.

Comments

  1. Sat Anlage about 1 month later:
    awesome blog, do you have twitter or facebook? i will bookmark this page thanks. jasmin holzbauer