Adam Gonnerman

"Progress is impossible without change; and those who cannot change their minds cannot change anything" ― George Bernard Shaw "All change is not growth, as all movement is not forward." — Ellen Glasgow It happens when I kick off a project that will alter existing processes. It also happens when I introduce Agile to teams. Whatever the scenario, human beings are creatures of habit, and so when change is brought up, dread, anxiety, and resistance are usually the immediate reaction. The good aspect of this is that not all change should be accepted. Establishing a rule that all office photocopies have to be documented on a shared document, including number of pages and purpose, is likely to get a lot of pushback. It represents a lack of trust in employees, and creates additional work for them as well. Anyone would be right to argue against such a rule, perhaps advocating for a guidelines quantifying what would be considered excessive use, and asking people to be respo

"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

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

"You can't be agile when you're knee-deep in mud."  -  Martin Fowler One of many mistaken ideas I held when I first got into Agile project management was that over time a Scrum team should be able to increase its overall velocity. The scenario I had in mind assumed that the team was stable and had become consistent on forecasting story point values (commit vs complete). The problem begins right there, with those two assumptions, and goes much further. There are ways to improve team velocity, but there are limits. First, although a team may be fortunate in remaining stable over a period of months or years, this is not something I've found to be the case very often. Team members come and go, sometimes because they're reassigned and other times because people naturally come and go from the company. One often overlooked source of instability is out-of-office time, whether through maternity/paternity leave, vacations, or illness. Capacity planning can be challenged

"The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner." - The Scrum Guide There are a lot of ways in which my approach to Scrum differs from what's in the official guide, and since that document refers to Scrum as 'immutable,' let's just call what I do 'Notscrum™.' In Scrum, there is only one product owner per team. That person is the sole person responsible for the product backlog, and the person who advocates for the work to be done. In Notscrum there is one product owner, but there can be multiple deputy product owners. Here's how it works. When my program at Viacom was first forming I met with the then-director of the Library & Archive group and learned that while he set the priorities on work done, the archivists were organized in three distinct areas with a team lead

"Ethical living is the indispensable condition of all that is most worthwhile in the world." — Ernest Caldecott Much is often said about the skills required to make a good project manager, and not quite so much about the virtues of a good project manager. By 'virtues' I'm talking about those positive ethical characteristics that are generally associated with the best among us. There are three specific virtues that are of utmost importance for a project manager. This isn't to say that there aren't other significant virtues for this role, nor that we shouldn't look for these traits in people generally. Rather, if a project manager possesses these specific virtues to a healthy degree, over half the battle is already one. Then we can talk about skills. "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest." ― Confucius First is wisdo