The other essential Agile ingredient

I must not fear.
Fear is the mind-killer.
Fear is the little-death that brings total obliteration.

–the “litany against fear” from the science fiction novel Dune

Yesterday I got a call from a prospective client whose Project Does Not Yet Suck, but it’s starting to make little slurping noises.

The situation calls for someone who is “aggressive without being arrogant” and “can handle pressure” while “getting stuff done.” And I thought hey, maybe this project isn’t necessarily right for me for some other reasons… but she did catch the spirit of what I talked about a couple weeks ago.

See here. Humility is not contradicted by effectiveness. It just isn’t. They’re different things. Surely you’ve seen people who are just too nicey-nicey for their own good. They never get anything done because they pull their punches and don’t do anything that might upset someone. These people don’t do well in life. Strangely to them, it often seems nobody even likes them.

When I talk about “humility,” this is not what I mean. Being a doormat is not the same thing as humility.

You totally want to read more about this, and you will, if you get onto my eZine mailing list. You get a complete mailing about once a month, with articles and links and special offers that help you do your job, as well a quick note every week or so with something funny or interesting. Do you need more stress? No? Then this is for you.

But you probably also know (or have had as your President) someone who picks a course of action, commits to it fully, never admits error, and doesn’t care who gets hurt. That person might impress some as “effective,” but… no. Being a jackass is not the same thing as effectiveness.

So where do you draw the boundary on this? How assertive is too assertive? When is kindness destructive? It sounds really hard but it’s not.

You can’t use fear!

Specifically with regard to the software projects we work with every day, where the work is almost all mental and–hang with me here–it requires some courage. Fear is the Mind Killer. It makes you stupid. (Hey, keep following that President example if you like.)

People who are fearful, extremely vulnerable, and scared can’t be humble. Humility isn’t when you’ve been beaten down and can’t function–that’s humiliation, definitely not the same thing.

Humility is, at its root, something like what Ralph Johnson said when responding to me; it’s an expression of mastery.

You do too know what I mean

Think of the most constructive, vital, interesting, together kind of person you personally know. Imagine hanging out with that person right now. Take a minute to pretend you can feel that personality, that vibe. Okay?

Now breathe in and hold it… or if that’s too weird for you, just lie and say you did… but consider how you feel when thinking about that friend or associate or crush. Are you feeling intimidated? Overpowered? Probably not. I guess you feel more safe than usual and maybe even taken care of.

Is the other person arrogant or demanding? Unlikely. Probably he or she is gentle, and far from intrusive. Mastery means you’re able to go through life without poking other people’s boundaries all the time.

Before I go on too long, first of all it’s okay to exhale now. Second of all, know that you’re experiencing the humility of someone who doesn’t have anything to prove. And lastly, try to imagine what that person might be afraid of.

Everyone has something to fear

If you’re working on software projects, what are you likely to be afraid of from time to time? Here are some obvious ones.

  • Project failing.
  • Project messing with your family or personal life.
  • Family or personal life messing with the project.
  • Looking bad.
  • Making a mistake that throws the project off course.
  • Getting fired for performance reasons.
  • Getting laid off for reasons other than performance.
  • Losing geek cred within your team.
  • Getting so sucked into the current technology that you can’t qualify for your next job.
  • Messing something up in a way that causes damage.

Certainly you can think of some others, and have probably experienced more of them than you would have liked.

Ordinarily, and if you’re fairly healthy, these are manageable fears. When those fears get out of control, though, where do you go? In the exact opposite direction of the right thing for the project, that’s where.

Is that crazy?

It’s not crazy, when you’re afraid of getting canned or being pegged as the Chump, to shore up your position as well as you possibly can. You play up successes, play down failures, dismiss mistakes or others’ opinions as irrelevant, and hide the attempts that don’t go well. When asked for status reports, you reply with whatever sounds good. When prompted for a task estimate, you figure out how to play it for political advantage–maybe padding it to start so you finish early, or quoting it low and sandbagging the PM later with “unanticipated” problems that maybe someone else caused.

This doesn’t work anyway, but it especially doesn’t work in a Scrum. (Realizing here that Scrum isn’t all of Agile, it’s still relevant here.) You can’t hide behind the Gantt dependencies; the Three Questions see to that. Your task estimates are constantly revised so you never exactly come out “ahead” per se. When you keep delivering working code every two or four weeks, you don’t get to wave your hands and claim “it’s not really done yet” for an extended period.

It’s all right there. Transparency.

The only way out

So here you are, developing software in a Scrum environment. You have fear and you have transparency. I.e., you’re scared and everyone can see what you’re doing. What’s the way out? Courage!

That means courage to give accurate task estimates, courage to report back when you hit an obstacle, courage to admit when the obstacle is you. Courage to give up a task when it’s apparent that someone else can do it better or faster.

Shifting second-person perspective now to the manager or owner of the project, I’m saying that bullying or rattling your development team is not going to get the desired results. If you think that’s “effective,” you’re missing the point.

But a policy of niceness isn’t going to do it either. That’s not you being humble, that’s you being taken advantage of.

Those aren’t polar opposites, so you don’t have to choose either one or anything in between. The proper attitude is one of humility that fosters safety, one that meets the developers’ courage at least halfway. They’re risking their credibility and their careers every day; give them a setting that cultivates their best work, not their worst fears.