Adam Gonnerman

 There is a pattern I have seen repeat across organizations of different sizes and industries. Teams adopt an Agile framework, populate their calendars with the right ceremonies, use the right vocabulary in standups, and then wonder why delivery feels just as slow and friction-filled as before. This is Agile Theatre: the performance of methodology without the substance of it. SAFe is perhaps the most visible example, a framework so dense with alignment meetings and coordination layers that the overhead of running it can quietly consume the productivity gains it was supposed to create. I have been thinking about this problem lately, and two frameworks have helped me sharpen my thinking: Agile² and DORA. The piece "Agile²" makes an argument worth sitting with. Agile, in its original form, was a correction to a specific failure mode: process worship. The Agile Manifesto pushed back against the idea that following a detailed plan was the same as delivering value. The uncomfortab...

Once I was pulled into an emergency meeting about a project that had stalled six months earlier. The client was asking pointed questions about decisions made during the initial planning phase, and the original project manager had moved to another company. As I sat there watching my colleague scramble through scattered email threads and half-remembered conversations, I was reminded of a practice that has saved me countless times: keeping a daily work blog. I know it sounds excessive, but hear me out. For most of my career, I've maintained what I call my daily project log using Confluence's blog widget. I set it up right in the center of my personal workspace, surrounded by my other project notes and references. Every day, without fail, I spend five minutes documenting anything relatively significant that happened with my projects. This isn't about writing novels or crafting perfect prose. It's about capturing the small but crucial details that slip away: why we chose ven...

Back when I was working at a startup, we brought on two engineering interns for the summer. Steve was personable and well-liked around the office. He had good technical skills and could handle the tasks we assigned him. When things got slow, you'd find him chatting with the team about weekend plans or the latest tech news. Sometimes he'd even catch a quick nap at his desk during those inevitable startup lulls. Isabelle took a completely different approach. She was equally capable with her assigned work, but when the inevitable downtime hit, she had her laptop open learning Ruby on Rails. This was the web application framework our entire product was built on, but it wasn't something we expected interns to master. While Steve socialized or rested, Isabelle was diving deep into documentation, working through tutorials, and even building small practice applications on her own time. I watched this play out over the course of their ten-week internship. Both interns completed thei...

Six weeks before our product launch, the VP of Marketing walked into my office with what she called "a small request." She wanted to add a complete user onboarding flow to our mobile app. Small request. Right. I'd seen this movie before. In my early days as a project manager, I would have smiled, nodded, and quietly absorbed the extra work into our timeline. The team would have worked nights and weekends, quality would have suffered, and I would have spent the launch week putting out fires instead of celebrating a successful delivery. But I'd learned the hard way that scope changes, no matter how they're dressed up, follow the laws of physics. You can't create time and resources out of thin air. The first thing I did was assess the real impact. This wasn't just adding a few screens. The onboarding flow required new API endpoints, database changes, additional testing scenarios, and integration with our analytics platform. My rough estimate put it at three w...

Three weeks before our mobile app launch, I watched our carefully planned timeline crumble in real time during what should have been a routine status meeting. The API team mentioned, almost casually, that they'd hit a snag with the authentication service. "Nothing major," they said. "Maybe a few extra days." That few extra days turned into two weeks, and suddenly our QA cycle compressed from three weeks to one. The marketing team had already locked in their campaign dates. Customer support hadn't finished their training materials. What started as a minor backend hiccup cascaded through every workstream like dominoes falling. I learned something crucial that day about dependency management: it's not just about tracking relationships between tasks. It's about understanding that every delay ripples outward, often in ways you don't anticipate. After that near-disaster, I completely changed how I approach dependencies in project planning. Now I map th...

I still cringe thinking about that executive briefing years ago. Our team was six months into rebuilding the customer portal, and I had prepared what I thought was a thorough status update. I walked into the conference room armed with architecture diagrams, database schemas, and a detailed explanation of our microservices approach. Twenty minutes in, our CTO held up his hand. "Adam, I need to stop you there. Are we on track to launch in Q3 or not?" The room went silent. I had spent the entire presentation talking about technical elegance while completely missing what he actually needed to know: timeline, budget, and business impact. That uncomfortable moment taught me everything about communicating tech status upward. I had fallen into the engineer's trap of leading with mechanics instead of impact. The CTO didn't care about our service mesh implementation. He cared about whether customers would have the new features before the holiday shopping season. Since then, I...

Three months into my first project management role at a software company, I watched a colleague destroy his credibility in thirty seconds. The engineering team was discussing a legacy system bug, and someone cracked a joke about Visual Basic. My fellow PM laughed loudly and nodded knowingly, clearly trying to signal that he was technically savvy enough to get it. The problem was obvious to everyone in the room: he had no idea what they were talking about. The engineers exchanged glances, and I could practically see his authority evaporate. That moment crystallized something I'd been sensing for weeks. Walking into a team of skeptical engineers as a new project manager feels like entering a room where everyone speaks a different language and you're holding a phrase book upside down. These developers had been burned before by PMs who talked a big game but delivered bureaucracy instead of value. Some had been working without any project management oversight and genuinely questione...