Adam Gonnerman

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

Ideally, backlog refinement should be handled primarily by the product owner with input from the tech lead. The product owner is taking direction from the business on prioritization, and the scrum master simply makes sure refinement takes place. What do you do though when stakeholders aren't in alignment on on the priorities? Here are a few steps I take when this comes up. First, I ensure there's clarity in the backlog items. We need to have well-defined user stories complete with scope and definition of ready clearly outlined. Business value, effort, and dependencies should be plainly stated.  Second, I facilitate a stakeholder discussion based on these backlog items, focusing on organizational goals and not personal preference. This means I need to frame it in terms of return on investment (ROI), risk, and dependencies. Once this is understood by all, we can move on to actual prioritization.  Third, I use a prioritization framework to draw out the relative importance of the ...

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

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

It's one thing when agile coaches pipe up with "that's not Scrum," and quite another when accusations of "fake Agile" are thrown around. I find the former irksome, but at least they have a leg to stand on with the 'End Note' of The Scrum Guide in their corner: "Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum . Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices." (emphasis mine) This is why I've taken to calling any more pragmatic approach 'Notscrum.' After all, if they insist that Scrum is 'immutable' ( like Plato's heavenly perfections ), then clearly what I introduce to teams and use to coach them is a more mutable creature, one that adapts to situations to achieve the dream of Agile. "We are uncovering better ...

The Scrum Guide has changed a few times, and the most recent revision was published in November 2017. Although a number of people have contributed to defining Scrum over the years, the key parties and primary authors of the Scrum guide are Ken Schwaber and Jeff Sutherland. That Scrum has changed over the years should not come as a surprise to anyone who is familiar with it or with Agile in general. Change is core to Scrum, with 'inspect and adapt' being a key activity for teams. With this comes learning that can at times be universalized and shared with teams everywhere. When it is particularly compelling it becomes part of the Scrum standard. Scrum is mutable. Several months ago I was listening to an Agile podcast and end up shutting it off about 20 minutes in because the guests and the host attacked Scrum itself as a bad methodology and then turned around and complained that 'no one does Scrum right.' One guest seemed to think it was downright scandalous that Agile t...

Not everything about Scrum has to be serious. In fact, because of the Agile emphasis on ' Individuals and interactions over processes and tools ,' I've personally found this mindset often fosters more 'fun' work environments than anything traditional project management can do. Aside from this natural Agile tendency towards a less dour situation, I also like to inject a little levity into the process wherever seems appropriate. One way I do this is with Sprint mascots. Every scrum team I work with through an Agile transformation chooses a genre when we plan our first sprint. It can be absolutely anything, from a movie franchise to celestial bodies, and all points in between. When a team completes planning a sprint, I ask them if they have a mascot from whatever they have chose that they would like to use. This can work in different ways.  One team I've worked with uses Star Wars, and so each sprint is named after a character from that franchise. There...

Once, in a project management role with a tech startup in NYC, I led the dev team into adopting Scrum. We had daily standups as well as sprint retrospective and planning meetings at the close of each sprint. A point of contention, though, was around ‘release notes.’ In standard waterfall development it is common to have release notes go out whenever a new product or an update to the product ships. This makes a great deal of sense given the amount of time that went into making the finishing product, with well-defined requirements from the outset. In Agile, however, the idea is to be…well… agile . When a sprint concludes there typically will not be a finished product, neatly wrapped up with a bow on top. What is delivered is a potentially shippable product increment. Here’s a very rough outline of how an Agile approach should work, as I see it: User stories are written, covering what is believed to be needed for the product. These follow the pattern of “As [user/r...

[ Read Part 1 Here ] When I was asked about my ministry experience during the team interview for my first startup job, I didn’t miss a beat. The question was straightforward: “How do you feel your mission experience might help you at this job?” It was fair to ask, given that at that point the only roles since my time in ministry work were English teaching, office assistant in a law office, and enterprise customer service at AT&T. I told them that I knew how to organize work, projects and people. Further, I was accustomed to handling my own area and working independently, so I didn’t require a lot of supervision. In other words, I was a self-starter committed to seeing people succeed individually and in teams. It may sound like fluff, but it’s true and I stand by it. There is something truly pastoral about project management, as it involves ‘shepherding’ a project through to completion, as well as taking care of the team that does the work. I wonder if perhaps...

Sitting across from the gentleman in downtown Uberlândia, Brazil as he reviewed my résumé, I expected a standard line of questions. He’d ask about projects I’d worked on, whether or not I’d managed teams and to what extent I understand code in particular and the software development cycle in general. Instead, what came first out of his mouth instead was a statement: “So, you’re a theologian.” That floored me. Although I hold a Bachelor’s degree in Ministry, the bulk of my professional life has been spent in software and website development. Rarely in New York City have I even been asked about the nature of my undergraduate study, something I suspect comes as much from indifference as a suspicion that it’s not okay in interviews to get too close to the topic of religion. Having spent a few years following graduation in mission work and then serving a church in New Mexico, I became disillusioned with ministry and resigned. After moving my family to New Jersey I ...

Early on in a brief stint as a project manager with a startup in New York, the product manager told me we needed to track individual velocities on the team. We had only just begun an Agile transformation, with me as the Scrum Master and her as the Product owner. She said it was just for our own tracking purposes, but having been told before by someone in senior management that he wanted to know which of the developers were 'slacking off,' I knew why she was really asking. The short answer to a request for individual velocity tracking, in an Agile environment, is ‘ no .’ This is actually a big no-no, for at least a couple of reasons. First, story points (or whatever method is used to weigh effort on user stories) are not precise. A team might look at a story and call it a ‘5’ (using Fibonacci, considering ‘8’ the largest) when it turns out to be a ‘3.’ Another ‘5’ could turn out to be an ‘8’. In the first case, the developer could end up looking like a whiz. In t...