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...

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...

Ask someone outside the profession what a project manager does and you'll hear some version of the same answer: they run meetings, update Jira boards, track tasks, and produce status reports. Maybe they build a Gantt chart or two. It's not wrong, exactly. Those things happen. But describing project management that way is like describing an iceberg by what you can see from the deck of a ship. The visible tip is real. The work below the surface is where the job actually lives. Beneath every clean status update is someone who spent the previous 48 hours balancing three competing priorities against a resource pool that couldn't support all of them. Beneath every smooth stakeholder meeting is a PM who quietly diffused a conflict before it ever reached the conference room. The Gantt chart your executives see on Friday reflects decisions, trade-offs, and conversations that never make it into any report. That's not an accident. That's the job. What the profession actuall...

"Innovation is saying no to a thousand things."  -  Steve Jobs There is a meeting to align on a proposal. Turnout is good, including some fairly senior people. Opinions differ. Time runs out. A follow-up is scheduled, a revised deck will be produced, a pre-read will be distributed before the next alignment meeting. Nothing is blocked. No one has said no. Yet nothing moves. This is what organizational stall actually looks like. Not conflict. Not resistance. Diligence. Leaders often equate consensus with alignment, but they are not the same thing. Consensus means everyone agrees. Alignment means everyone understands the direction and their role in it, even if they would have chosen differently. One is a state of unanimous opinion. The other is a condition for coordinated action. When consensus becomes the goal, progress slows while risk quietly compounds. Consensus optimizes for harmony. It is a room full of nodding heads, objections softened or withdrawn, everyone heard and id...

Not every career advancement is the result of a deliberate plan. Sometimes the right environment finds you at the right moment, and what you do with that opportunity determines everything that follows. After working at Zepinvest, a small New York City startup, I had developed a working foundation in content curation, content management, basic HTML, and the practical realities of keeping a web presence running. It was hands-on, scrappy work, and it prepared me well for what came next. My following role was as a web producer at Condé Nast, a considerably larger stage with considerably higher expectations. I did not know it at the time, but that position would become one of the most formative experiences of my professional life. In my early days as a web producer I sat in conference rooms where conversations about projects, products, and timelines felt like a foreign language. People moved through discussions with a fluency I did not yet have, and I spent more than a few meetings simply...

There are moments in a program manager's career when following the established process is exactly the right call, and moments when following it blindly leads to serious problems. Knowing the difference is not something any methodology teaches you. It comes from experience, and sometimes from a project that goes sideways before it gets right. I was once tasked with leading an ADA compliance initiative for a company's primary application, covering web, mobile, and Smart TV platforms. Accessibility work is not optional. It is a legal and ethical obligation, and the stakes of getting it wrong extend well beyond a missed deadline. When I assumed the project it had already passed through the hands of two product managers, both of whom had moved on to other opportunities. I was inheriting something that had already lost momentum and institutional memory. I did what any program manager would do in that situation: gathered what information I could, held a structured kickoff meeting, al...

Nobody puts missionary experience on a project management resume. I did not either, at least not explicitly. But after fifteen years delivering complex technology programs, I am convinced that two years of mission service in Brazil shaped my professional instincts more than any methodology certification ever has. Let me explain why. After a mission internship in Brazil in 1997, I committed to returning as a full-time missionary. That meant getting the right education first. I enrolled in Harding University's School of Biblical Studies, an accelerated program that compressed nearly four years of education into two. The pace was relentless. I studied beginning through advanced biblical Greek in 24 weeks. Along the way I went deep not just into Scripture but into counseling, fundraising, cross-cultural communication, and the practical realities of sustaining a mission. I was trained to enter unfamiliar territory and figure it out. That turns out to be an extraordinarily useful profess...

“ All change is not growth, as all movement is not forward .” — Ellen Glasgow One day I was at the neighbor's house, hanging out with friends, when I noticed a calendar with a quote for each month. Paging through it, I came across the one above. It impacted me deeply at the time, as it aligned with what I often felt I saw in the world. Movement without progress. As the years have passed the quote has stayed with me, and its meaning to me has evolved as I've progressed through my career. I can see that in today's business culture, we often confuse activity with achievement. Let's consider the differences between shipping and advancing. "Shipping" means delivering something, releasing a feature, completing a sprint, publishing a post, or closing a ticket. Shipping is visible. It feels productive. It checks a box. Advancing, on the other hand, means moving closer to a meaningful objective. It's creating durable value. Improving systems and not just outputs....

There we were, on a Zoom call, sharing our quarterly roadmap with leadership. The visuals were clean with dates, themes, milestones, and color coding. I think it's safe to say that the emotional effect of such a roadmap is a sense of alignment, clarity, and reduced anxiety. That's where there may be a problem. Roadmaps create psychological safety, but that safety can become an illusion of control.  Visual order reduces anxiety. We humans are social beings, and stories are core to our way of thinking about life. We prefer structured narratives over ambiguity. A roadmap, high level though it may be compared to a detailed project plan, turns uncertainty into a sequence. Having dates implies predictability, and sequencing implies causality.  Executives, for their part, want forward visibility. They want to see into the near- and mid-term future to the extent possible. Sales wants commitments that can be communicated and kept. Finance wants forecasting. Engineers look at the roadma...

Many times I have watched scrum teams ignore their historic capacity and proceed to add more work than they can possibly do to a sprint. Sometimes this is because a manager insists they include " stretch goals " in the sprint. Bad idea! Other times it's coming from the product owner who is being pressed by the business to deliver multiple features in a short time frame. This simply won't work. If you have a stable scrum team, made up of regular team members who do not switch out to other teams or work, you can determine their capacity by watching their velocity. If they commit to 100 story points of work but consistently deliver around 70 story points, then you have your capacity. The only way to increase their capacity is to increase the team size, which itself presents problems. When you add members to an established team, two things happen. First, the team overall can slow down as the new members figure things out and the team relearns how to work together. Second,...

When a Scrum team plans a sprint, they should do so with their velocity in mind. Velocity, in the context of Scrum, refers to the average number of story points a team has completed in past sprints. This metric serves as a reliable gauge of the team's capacity and should guide the amount of work planned for each sprint. Assuming the team has been working together for a while using the Scrum methodology, their historical velocity provides a realistic benchmark for future sprints. Planning sprints based on velocity ensures that teams do not overcommit or undercommit. Overcommitting by adding more work than what the team's velocity supports can lead to incomplete sprints, while undercommitting may result in underutilization of the team's potential. It is essential to strike a balance, and the team's average velocity helps achieve that balance. Temptation to include additional work beyond the team's velocity often arises, particularly from product owners who may see str...

Embracing Agility in a Major International Entertainment Company In the fast-paced world of technology, agility is not just a methodology; it's a necessity. This was the lesson learned when I joined a team responsible for the core technology at a major international entertainment company. The team, a traditional engineering group, had been working in a siloed, manager-driven approach for years. They had a strong bond but lacked visibility into the broader picture of their work. The challenge was to transition them from their conventional ways to a more agile and efficient system. The Initial Roadblocks: A 50-Page Document and Reactive Workflows The first hurdle was the team's reliance on a 50-page document for requirements management. Buried in these pages were years-old issues and bugs, making it challenging to prioritize and address current needs effectively. Furthermore, the team juggled development and support for their mission-critical system, leaving little room for delay...

The concept of Agile transformation, particularly in industries perceived as traditional, such as publishing, often comes with a heavy dose of skepticism. A pivotal moment in my career was steering such a transformation for a publishing company’s engineering team, aiming to adopt Scrum methodologies. The journey, although fraught with challenges, offers valuable insights into driving change even in the most unlikely environments. Overcoming Leadership Hesitancy Initially, the transformation encountered resistance. A new boss, with roots in a different era of publishing, held the belief that Agile frameworks, with their iterative nature and flexible deadlines, were incompatible with the rigorous deadline commitments of our industry. This underscored a common misunderstanding of Agile: it’s not a lack of structure or discipline, but a more responsive and efficient way to manage projects. Despite efforts to clarify this, my explanations met with resistance, leading to a professional parti...

The realm of publishing, like many other industries, has not been immune to the sweeping changes brought about by technology and changing work dynamics. Among these changes is the adoption of Agile methodologies, particularly in teams that intersect with technology and project management. I'd like to share a personal anecdote that highlights the misconceptions about Agile, even within progressive industries like publishing, and why it's essential for leaders to understand its real value. A Step Back in Time Years ago, I found myself working at various publishing companies. At one such company, an opportunity arose that would have been a significant milestone in my career – leading an Agile transformation for an engineering team. They were keen to evolve into a full-fledged scrum team, and the head of engineering was supportive of the initiative. However, the journey hit an unexpected bump. One day, while discussing the transformation with the head of engineering, my then-new bo...

The Definition of Done is a crucial concept in Scrum framework that is often misunderstood. It is a formal description of the state of the Increment when it meets the required quality measures for the product. It plays a critical role in the successful implementation of the Scrum framework by ensuring the creation of a 'Done' potentially releasable increment. The Definition of Done is the entire Scrum team's responsibility, but teams must also adhere to any organizational-level norms, regulations, standards, or security policies that must be part of the product's Definition of Done. The Definition of Done supports the Scrum framework throughout its five Scrum events. During the Sprint Planning event, it helps the Scrum team understand the required activities to complete the work and decompose the Product Backlog Items into an actionable plan. The Daily Scrum event helps build a "Team Goal over Individual Goal" mindset by realizing that a product backlog item i...

The tone on the call was dour and gloomy. The international team I was leading through an Agile transformation had completed its third sprint, and all three were 'bad' in terms of work completed. A senior VP was on the line with me, the co-product owners, a couple of teams leads, and one or two others from the business. We meticulously talked through the various reasons why things hadn't gone to plan, referring often to the retrospective notes that I'd compiled at the end of each sprint with the team. Chief among our problems were story point estimates that were too optimistic, 'emergency' work that came in, and extra work finding its way in without being accounted for. As I've indicated, people weren't happy. And then, it occurred to me that the group wasn't seeing the bigger picture. "Let me ask something," I said, "would these issues have come up if we hadn't changed anything?" Long pause. I asked again: "If we had not...

It was really a pretty large group we gathered for an introduction to Agile, and none of them were software developers. This was several years ago now at a major media company where I had been recently promoted to program manager. A senior scrum master was assisting me with the training portion for the archivists who were part of my newly-formed program group. They were going to be part of an Agile transformation that would range from them through the streaming partnership team and on to broadcast engineers. And, importantly, almost none of them had ever heard of Agile before.  Some might wonder why we even bothered with an Agile transformation for such a group. The answer is that 1) we weren't forcing it on them, 2) we really believed it would help, and 3) the PMO was answering a call to help the entire organization become Agile, if possible. It turns out that Agile practices, Jira, and a bunch of librarians combines marvelously. It was something of a wonder how well and quickly t...

Some of my most rewarding professional experiences have been in leading teams through Agile transformations, adopting scrum. I've guided not only engineering teams through this transition, but even business and operations groups such as the archivists at a major media company. Very early at a publishing company a supervisor told me that "we won't do Agile" because people with our brands "need deadlines." He believed that Agile meant 'loosey-goosey' and inefficient. He also believed that we wouldn't get good metrics from a scrum team. That's definitely not the case, and in this piece I'll provide a brief overview of 3 metrics that I believe should be observed and reported. First, the sprint and release burndown will provide a view of the team's progress at a glance. This chart is a representation of the effort remaining over a period of time, and if updated on a daily basis it can help the scrum master to predict whether the team will ...

While most of the Agile transformations I've guided were into Scrum, there have been some Kanban teams along the way. If done poorly, Kanban is merely understood as a task list on a board shared by a team. That really isn't the way it's supposed to be. Today I'm going to outline briefly the metrics to look for in Kanban, which should provide the insight needed to do a proper transition to Kanban. While I'm making the assumption here that the reader already has an idea of what Kanban is, here's a succinct description provided by Atlassian : Kanban is a popular framework used to implement agile software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time. The first metric to look for in Kanban is cycle time. With cycle time you are measuring how long a task remains in process before completion. If ...

"Teamwork is the ability to work together toward a common vision. The ability to direct individual accomplishments toward organizational objectives. It is the fuel that allows common people to attain uncommon results." — Andrew Carnegie Every time I hear a vendor say "we're going to do this as an Agile project," I shudder. This has happened twice, so perhaps my sample size is too small, but the fruit of such an endeavor are predictable from the attitude going in. You see, there's really no such thing as an Agile project, as I see it. There are only Agile teams. If the team isn't Agile, the work they do will only hold the form of Scrum, Kanban, or some other methodology, but the mindset will be absent. The result is a subpar project that convinces everyone involved that Agile is a bad idea. Being Agile is a way of thinking about work, a philosophy that is embraced, internalized, and translated into action. The team is at the center, and their work demonst...