Adam Gonnerman

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