Why PMs Need (to Understand) Agile

This year I had the honor of providing some opening thoughts at the NTPM conference. As the conference is aimed at Program Managers, but has a lot of Agile content, I chose to give three reasons why PMs should understand Agile. I’m rehashing them here.

Common Language with Delivery Teams

At the end of the day, PMs and delivery teams* have the same goal – maximize the value delivered as part of the project. To be able to determine what maximizes the value and how to best deliver it requires a dialog between the PM (especially if playing a PO-type role) and the team. You can’t have a good dialog without a shared language.

* I use the term delivery teams as Agile has grown far beyond software development teams.

Personal Efficiency

Practitioners of Agile quickly realized that they see benefits not only to team efficiency, but also personal efficiency. Be it through following concepts like limiting WIP, maximizing work not done or reflecting on how we work or implementing specific techniques like Personal Kanban.

Agile Adoption

The least obvious (but most dangerous) reason is that PMs are often chosen to lead Agile adoptions. To management this seems like a no-brainer – Agile adoption is an internal project, so it should be managed by PMs. But we know that projects are more effective, when PMs have an understanding of the subject domain (even if cursory). And an Agile adoption is so invasive into culture and the way people work that it’s very easy to mess it up or bend it to optimize the PMs job, not maximize value delivery.


Are you regressing to the mean?

As Reese’s Peanut Butter Cups teach us, some of the best ideas come from combining to possibly disparate things. Here’s on of mine.

I recently finished Geoff Engelstein’s “Gametek: The Math and Science of Gaming“. This book is a compilation of segments he recorded for the the Dice Tower podcast. These segments explore how math and psychology (among others) affect good game design.

At the same time, I’m struggling with my scrum teams, which recently had trouble completing there last few sprints. This is not only bad for morale, but also diminishes my ability to provide good timelines to our stakeholders.

One of the segments that resonated with me was the regression to the mean. In a nutshell, this states that performance clusters in a bell curve around the median performance. Which means that any incident of being above average is most likely to be followed by comparatively worse performance and vice versa. This also means that criticizing seemingly works (because the next performance after a bad one and criticism is usually better), while praise doesn’t.

I went back to look at the size of sprint backlogs over a period of time, I saw an increase in the number of stories selected by the teams (we don’t use story points #NoEstimates). To me this looks like a situation in which the teams saw they were able to deliver commitments, so they “challenged” themselves to do more. These challenges usually work for a time (reserve energy, sacrifice of slack), but as the sprint backlogs grew, so did technical debt, WIP items, items bouncing back to the backlog. Until it came crashing down in unsuccessful sprints.


Adopting Agile using Waterfall

Something that bothers me, is when organizations go out to adopt Agile, but try to do it using traditional program management or waterfall methods. “It’s the only thing they know” – you might say. But if it is, how are you doing the adoption? You have to have Agile coaches or Scrum Masters or Agile practitioners. Someone who knows how Agile works. And why wouldn’t you ask them to organize the adoption.

If you see value in adopting Agile, why not do it correctly? And if you don’t, and treat it as a fad – just don’t do it. Or better yet, let those that want to, do it and let it grow and spread organically. Otherwise, you’ll alienate both the practitioners as well as those that don’t want to change.

Is this just an anti-pattern of “those that can’t do, teach”?

(Note: I do say anti-pattern. I’ve had many amazing teachers throughout my life).

Why I’m not pumped today

In a couple of hours, I’ll be teaching a class on Kanban. I should be pumped – I mean it’s expected from a trainer, right? But I’m not.

Why? It’s a “mandatory” class.

At the risk of sounding like a zealot, I’ll admit that I find Agile not dissimilar to religion. Sure, you can force people to come to the temple/church/stand-up, follow the rituals, repeat the prayers/three questions/etc, but unless the people believe in what they’re doing, it’s for naught.

The way to convince people, is to show through your own life/work that these practices make a difference, make you happy, make it easier to achieve your goals. And when they see it, they will want it for themselves.

Hey, maybe if I’m pumped, I’ll convince some of my audience.