I was on an Agile New England panel with some sharp practitioners talking about the good, the bad, and the ugly of agile.
My first real experience with agile wasn’t called agile. I was a developer on a three-person team with no priorities and no visibility into what anyone else was doing. I started organizing the work mostly because someone had to. Turned out I liked it. I read the Extreme Programming books, we started doing scrums, and as that company grew from three people to thirty, the process grew with it. We built a product from scratch and iterated fast. The thing that kept working, even then, was the retrospective. Not because it felt good, but because it gave the team a real mechanism to improve the process as they went — and that meant they actually owned it.
At GitLab, I led an engineering org spanning many time zones. They didn’t have scrum masters. We ran agile almost entirely in writing — async standups in Slack channels, people sharing what they did, what they’re working on, and where they’re stuck. It works well most of the time and breaks down occasionally. Certifications aren’t something we actively push, but they’re not a negative either. It’s just not what we anchor on.
On the bad side of agile: setting priorities is still hard. That’s a people problem, not a process problem. For example, I was in the middle of a disagreement about a change that some people loved, and some hated — and the question of who gets to decide, and what we do when people don’t agree, is as hard as it’s ever been. The disagree and commit concept that Amazon popularized is genuinely useful, but people often treat it as “disagree and keep disagreeing quietly,” which doesn’t move anything forward.
On metrics, we tracked a say/do ratio rather than raw velocity — how much the team said they’d finish versus how much they actually did. We targeted 70%-80%. If a team is consistently hitting 100%, they’re sandbagging. If they’re at 10%, something’s wrong. We also look at merge/pull request rates at the team level, not per person. The goal there is to push people toward smaller chunks of work, which gets you to more real iteration. It’s not perfect, and it is sometimes controversial, but it’s a more honest signal than comparing story point velocity across teams, which tells you almost nothing.
On security specifically, it has to be part of the normal prioritization process, not something bolted on from outside. When a security scan runs on every build, and the developer sees the results immediately, it stops feeling like a separate discipline and becomes part of the job. The same goes for escalation of serious customer-facing issues: handle it like a high-priority outage. You don’t want to over-index on security issues, but you absolutely cannot under-index on them either.
The through-line for me, across every team I’ve been on or led, is that the process only works if the people in it can actually improve it. That’s what retrospectives are for. That’s what “disagree and commit” is for when it’s working right. When the team owns the process, the process stays alive and relevant.
Leave a Reply