Adam Gonnerman

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

It grates on my ears every time someone says "That's not agile," even when they might be justified in saying so. It's said far too often and without much thought, often reflecting more of the bias and personal preferences of the person complaining than it does any violation of the spirit of Agile. What is Agile? It boils down to the Manifesto For Agile Software Development, as worked out in 2001: Individuals and Interactions  over processes and tools Working Software  over comprehensive documentation Customer Collaboration  over contract negotiation Responding to Change  over following a plan That is, while there is value in the items on the right, they value the items on the left more. That's both simple and sufficiently vague to allow some room for interpretation. Sadly, I hear people calling any documentation at all, any handing down of deadlines, or any semblance of a project plan 'unAgile.' This is the sort of thing that gives Agile in ge

It was painfully clear the people from the vendor wanted to please us when they started using Scrum terminology to describe what they were doing. It's just a shame that they were still doing waterfall. Sitting across the table from them at the kickoff meeting, the vendor representatives laid out their schedule. They told us what to expect with each sprint, listing out deliverables and so forth. Aside from the fact that this was all projected out ahead of time and left in no way to their development team, the sprints themselves were of irregular lengths. There were two week, three week, and even five week sprints, in no perceptible order or pattern. Finally someone asked them why the sprints were different lengths, and a project manager told us that this was necessary because some of the work couldn't be made to fit into sprints of a single length. At this point, let me make two things clear: First, in Scrum, the product owner prioritizes the backlog and the team selects w