Your Dev Team isn't Agile
By definition, engineering can't be Agile on its own. It's a conscious, active choice that involves every part of the business asking hard questions.
“This is pointless. We’re already Agile.”
The engineering manager I was talking to was visibly annoyed. He’d spent the last two hours walking me through his team’s processes.
I was brought in to figure out why his team was struggling. Timelines were being missed. Frustration had built to the point that the COO and CTO were getting into weekly shouting matches.
“If you actually want to help,” he continued, “talk to design and ops. They’re waterfall.”
Ah, there it was.
In software development, “Waterfall” practices follow delineated, sequential steps where different teams hand things off to one another. Just like the name implies, the steps must happen in order, and you can’t go backwards. The practical artifacts (detailed documentation, strict hand-offs) are largely borrowed from traditional manufacturing.
Agile was a response to that. It focuses on iterative development, where requirements and solutions constantly evolve through collaboration between cross-functional teams and customers. While there are exceptions, Agile is generally accepted as best practice for modern software engineering because it changes so quickly by nature.
But by this definition, an engineering team cannot be Agile on its own, because the whole point is to bring users and stakeholders into the engineering process. If essential stakeholders “aren’t Agile”, no one is.
This company fell into a classic trap. They adopted Agile rituals at face value but largely missed the point. They were Agile the way the Easter Bunny is Catholic.
Agile is not a static state.
Agile is not a state of being you achieve when your team implements planning, sprints, and retros. It’s an active set of choices you make daily - and it’s a constant work in progress.
Today, it’s the default way of working. So much so that people get very up in arms when you imply they’re not. But while everyone is fiercely gritting their teeth about how Agile they are, a fundamental truth gets lost:
Agile is not the default, and it’s excruciatingly hard.
To be Agile - to collaborate openly while embracing mistakes and change - is to fight your instincts as a human. Waterfall practices make us feel safe. They let you believe that:
You’re in control. You can plan for everything, and things will follow the plan.
There are clear, sharp lines between different roles. There is no shared accountability. Ex: “If I just do my job, it’s not my fault if we fail.”
There is a clear finish line.
Compare that with Agile:
You are not in control of anything. Even the best-laid plans can and will fail.
You can do your job perfectly and still fail. You are just a part of a team and responsible for your shared success.
You will never be done because goalposts constantly shift and move. AKA: The struggle is eternal.
No matter how enthusiastically you adopt Agile, Waterfall behaviors always creep in because they are so much more appealing. We love black-and-white lines, closure, and a sense of control.
Embracing inevitable failure, shared responsibility, and literal eternal struggle? Yikes.
No one wants to buy what Agile sells, so you will always default to Waterfall behaviors and beliefs. There is no shame in this. Again - to be Waterfall is to be human.
So, how do you stay Agile?
1. Stop expecting Agile as a default
Most leaders become immediately defensive when someone implies they are using Waterfall practices. Who wants to be the guy who doesn’t value collaboration, working software, customer feedback, and adaptability?
However, treating Agile as the default ignores the extraordinary vulnerability required to maintain it. Vulnerability—stepping out of your comfort zone and exposing yourself to potential harm—is not something humans are wired to do naturally.
We also don’t celebrate defaults. When you treat the tremendous task of Agile as a given, you devalue it. When you stigmatize natural human instinct - AKA: Waterfall - you build a culture of shame and grandstanding. It all makes it even harder to stay Agile. How can you be vulnerable if you can’t even acknowledge how hard things are?
To be Waterfall is human. We must expect accordingly and aggressively build cultures around Agile behaviors. If and when we succeed, we deserve to celebrate enthusiastically.
2. Process ≠ Collaboration
Here’s a common scenario: design has spent weeks on a new UI, but what was produced wasn’t feasible—it didn’t take into account development constraints and a variety of edge cases. The engineering team did what they could with the designs they were given, but the end result was clunky and late. No one is happy. A postmortem is scheduled. Everyone agrees: we need a better process for hand-offs between teams.
I have seen this scenario play out countless times. Every time, without fail, these processes make things worse.
Instead of iterating with engineering, designers go through a checklist alone to hand things off “correctly.” The “finished” design checks all the boxes but still isn’t feasible because - lo and behold - they still haven’t talked to the engineer.
It was never a process problem to begin with. It was a collaboration problem, and no amount of procedure could substitute a simple, vulnerable conversation between team members.
3. Solve collaboration problems at the root
To solve collaboration problems, you need to go deeper.
Why didn’t design check in with engineering early? Why didn’t engineering loop back to design when things were going south? Why did the CXO wait until the last minute to give their directional input? Why weren’t we vulnerable and collaborative?
The answer is never a missing checklist but a hard truth:
I needed help but didn’t want to admit I was struggling
I was afraid to speak up and go against the norm
I didn’t want to look dumb, so I didn’t ask
I messed up but was afraid to own it
I prioritized my ego over the team’s success
I’m afraid of failure, so I’d rather make sure it’s perfect before we launch
I didn’t feel important, so I’m lashing out
These answers reflect some of our basest human instincts. They also point at failures of culture - squarely a leadership responsibility. They’re unflattering all around, so we often look away. It feels much nicer to draw up a new checklist in the name of self-improvement and pat yourself on the back for another retrospective in the bag.
But this is precisely why Agile is so hard. To keep it going is to fight against human instinct. You need to acknowledge that you’re more likely to fail than succeed. Ironically, it’s this precise acknowledgment - the very spirit of Agile - that gives you any chance to succeed at all.
The Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Modern software engineering requires an Agile mindset because it is inherently complex. Retros, sprints, or story points aren’t prerequisites, but vulnerable collaboration is.
Godfrey helps software development teams foster cultures of collaboration. It maps maintenance, resourcing, and architecture so everyone can understand and participate in engineering.