We are not fucking competent

We are not fucking agile. Stop talking to me about Agile.

—Boss of one of my mentees, in a 1:1 career advice session.

Though I wasn’t in the room at the time, here is my response. Feel free to use it.

I’m not talking about Agile. I’m talking about outcomes:

  • writing software at low cost,
  • without bugs,
  • and with easily-changed design.
  • Shipping many times per day such that we can hit any market cadence.

Ways that provably, repeatably, and sustainably simultaneously:

  • increase intrinsic and extrinsic quality,
  • decrease cost,
  • increase scope accomplished per time,
  • and keep resources constant.

I’m not talking about Agile. I’m talking about competence.

So when someone says the above I hear: “we are not fucking competent. Stop talking to me about competence.” And you know what? They’re right.

Agile isn’t about how you plan or how you report progress to managers. Agile is about becoming competent at shipping software and how that fundamentally shifts the power in an organization from managers to doers.

That’s why Agile was scary to this boss. His entire job was to correct for incompetence (in his team and in his bosses). If his co-workers started being competent, he’d be out of a job. He has a vested interest in incompetence.

But then I recently tweeted “Career-gambling moves: bet you can’t do just one.”

5 thoughts on “We are not fucking competent”

  1. I agree with this, but I tend not to talk about those outcomes because, in some places, you can't make progress because people just flat-out won't believe you.

    I want to talk about the second list, about improvement and progress.

    1. This is where I find micro-habits to be helpful. Kick off with a few little things that have big changes (the first several are technical), and only get to the big changes with small or leveraging impacts (such as changing the planning process) later. I start with refactoring to introduce names, extend that to show the insight having / recording loop, then go from that to test as spec (extract legible spec from legacy code), and finally to spec first. I do all that in mobs and pairs, slipping the ability to learn and change in the sides. Then is the first time that I need to get buy-in or belief (the next thing to do is 2-day process improvement cycle, and that requires budgeting that values improving productivity as well as improving product). But at least I can show the improvements we've already made and how they could do so much more…if only we chose to invest.

  2. Thanks Arlo, needed this. I'm going to search your blog for guidance on creating a sense of collective ownership on a team (so we can actually make progress on the things listed here). -briapu

Leave a Reply to Eric Gunnerson Cancel reply

Your email address will not be published.