The Master Builder Agile Engineer

President Business’s Engineer Instructions:

Step 1: Do not leave your desk.

Step 2: Do not have an opinion.

Step 3: Code only what you’re told. Nothing more. Nothing less.

Parts Needed: 1 computer, 1 desk, 1 chair, 1 mindless drone (that’s you!)

The above instructions aren’t too far off from a day in the life of a breed of developers known as “Code Monkeys”. These are developers who clock in, do what they’re told, clock out, and collect a paycheck. They may care about the quality of their code, but they don’t care about the customer. They don’t care about the user experience. They don’t care about the value. They’re just following the instructions that someone is telling them to follow. By the way, that “someone” is probably a micromanager.

If “someone” told you to jump off a bridge, would you do it?

You’d at least question how high the bridge is and what’s under it, amiright?

Why should software development be any different? Being handed a set of instructions and being able to follow them without questions does not make you a good agile engineer. It makes you good at putting IKEA furniture together.

agile fu tip # 1

Make smart decisions. Don’t go to IKEA on a weekend. Just don’t. It’s like a zoo that let all the animals out and then the animals started their own zoo to try to trap the humans inside.

So what’s wrong with being a Code Monkey in an agile environment? Well, let’s take a look at just a few of the qualities that every member of an agile team should have, shall we?

  • Individuals and Interactions – The first agile value! Even engineers should be willing to get out of their chairs and have a discussion about a feature or an item in the acceptance criteria.
  • Self-organized – Every member of the team should be able to self organize to solve a problem. This often includes the team solving for a problem without anyone telling them to. For example, would a Code Monkey step up to facilitate a daily standup if the Scrum Master isn’t there?
  • Customer Collaboration – Another value! What’s important here is to point out that the values apply to every member of the team, not just the team as a whole. That said, even your engineers should have the chance to collaborate with the customers. Even your engineers should care about the user experience they’re providing.
agile fu tip # 2

The agile values apply to every member of the team, not just the team as a whole.

Gone are the days of these so-called Code Monkeys. Who wants to be a monkey, anyway? Do you really want to be flingin’ feces at walls, anyway? No. You want to be engineering innovative, efficient, game-changing products for your clients.

Every single member of an agile team should have a passion and investment into the product. You should care about the quality of the software. You should care about what the customer wants and how the customer thinks. You should go sit with the client and see the product from their point of view. Yes, even you, the low-level engineer!

Admittedly, most engineers are introverts. I’m not going to give you any numbers or fancy charts on that. It’s just something we all know is a fact, like gravity. But, and this is a BIG but, that’s changing. More and more companies are adopting agile methodologies every day. Agile means more interactions with individuals, more collaboration, more self-organization, and more empowerment for engineers. You can’t just sit hunched over at your desk all day, letting the empty Mountain Dew cans pile up while you write line after line of code.

agile fu tip # 3

Your workspace is a collaboration space. Go throw away your empty Mt Dew cans right now. You’ll thank me when people stop giving you weird looks.

Get out of your chair. Go drink your Mountain Dew with your team while you have a discussion about how to improve the product or how to improve your team, or how to make the customer happier.

Think you’re Product Owner might not have the correct priority? Think there is some wrong Acceptance Criteria on your story? Think your team needs to prioritize a technical story to eliminate some technical debt? Think you have a better idea for a design than the one you got from UX? Think items you’re working on shouldn’t really be part of your MVP? Speak up! Use your outdoor voice. Maybe you’re wrong. Maybe you’re right. If you’re wrong, you probably learned something from the discussion about your product, your customer, or your team. If you’re right, you’re a hero.

The point is: Collaborate with your team to make sure you give your clients the best possible solution. Be a master builder!

Think I’m right?
Think I’m wrong?
Let’s make this a discussion in the comments below!

Leave a Reply

Your email address will not be published. Required fields are marked *