forward

What is Agile (not what you think)

There are always canaries in the coal mine. In tech, you won’t find them in well-established companies. You also won’t find them at startups working on tired, utilitarian, already-solved problems. They are the high-performing teams working on the most important problems in dire need of a solution. The more I speak with leaders of these teams in my industry and others, the more I find that Agile is failing to meet their needs.

I am many years into my tech career and I still don’t know what Agile is - and at this stage, I’m too scared to ask. I think I’m probably not the only one in this boat. I know I’ve used some Agile practices like sprints, retros, planning, etc. with my teams but I can’t tell you succinctly what Agile is, it’s like being in a cloud, you know you’re in it but you can’t point to exactly where it starts and ends.

For what it’s worth, even Atlassian, in their extreme irrelevance, can’t tell you what Agile is. If you visit the page for the Agile Manifesto there are 2-3 pages of text debating about what Agile is and why it exists.

Like many other engineering leaders in high-performing teams, I don’t have an inordinate amount of time for such navel-gazing. When it comes to product engineering, I am a simple man (some might even go so far as to call me stupid) with simple needs.

My Simple Product Engineering Needs

Before writing about practices and tools I’ve found helpful, it’s sane to lay out my simple needs. My hunch is that if you are part of a high-performing team you’ll resonate with more than a few of these.

1. I need work to get done pretty efficiently but not too efficiently

This requires finding the right level of efficiency quickly and then continuing to recalibrate that level over time.

Teams that are too efficient lack the creativity necessary to do great work.

Inefficient teams cannot execute on ideas.

2. I need my team to be extremely self-disciplined

I am accustomed to managing remote teams. Remote teams need to have an unnaturally high level of self-discipline.

Juniors can cultivate self-discipline. Mid-to-late career employees are extremely unlikely to learn self-discipline if they don’t already possess it. I’ve never personally seen it happen but assume that it has somewhere at some time maybe.

One teammate lacking self-discipline will drag the whole team’s potential down.

3. I need to know what work is being done at a high level

TMI breeds control freaks. Control freaks bog down the process. It is my natural tendency to be a control freak.

I need to know enough to inform technical direction and to communicate progress to stakeholders.

4. I need my reports to know that they can safely critique our process

Endless engineering leaders have paid empty lip service to this idea but only a couple have embodied the concept. If your employees feel like they can’t (respectfully) critique the team’s process they will shut down. In addition to poisoning morale, shutting down critique is like plucking out one of your eyes - you’ll still be able to function but you’re depriving yourself of a lot of sensory data that can inform action. If you don’t trust your reports to contribute to the overall picture of “how things are going” your hiring process or performance review process is off - why would you willingly put someone on your team when you don’t respect their experience?

5. I need us to have a plan that makes sense for both the business and the team

Business needs always come first, the business provides the space and resources to conduct the work. Where I see a lot of laziness though is when leaders hear the business needs then turn around and immediately tell their employees to “do that”. That’s not leadership, it’s a game of telephone, and no value is added this way.

Instead of barking orders, a leader must employ two of their most valuable skills, creativity and empathy, to shape the business goals into work that intersects with the skills of the team. Ideally, they can also link some of the team’s interests to the work, although this isn’t always possible.

This plan should be made at regular intervals. It is the leader’s responsibility to understand the business goals and to build a plan that fits that need while being viable and interesting to the team. There should be a formal presentation of the plan followed by a team-building activity.

Forward

Check back here or connect with me on LinkedIn to be notified when future essays in this series are released. The next installment will cover a roadmap creation practice I call SYNERGYMAXXING.