The Agile Project Manager: Living in the “Real World”

One of the things I hear most often in my public speaking engagements and workshops goes something like this:

I’ll spend time speaking about an agile principal, or practice, or technique, or even a mindset. Someone in the audience politely raises their hand and asks a question. I’m paraphrasing a bit, but it usually goes something like this—

Bob, that sounds really nice as an academic scenario or generic advice, but in the real world, something like that will never fly. We have too many constraints. It just won’t work in our organization. It sounds nice, but…

And then there’s the inevitable follow-up question—

Can we still do agile if we don’t do that ____________?

Which often gets repeated over and over again as we explore additional principles and practices…

I often feel a wide variety of emotions as a result of these dialogues—from frustration to sadness to a smile at the repetition. Depending on the point being made, it’s usually an early indicator that I’m in for a tough go in the class. It often indicates that folks are being ‘told’ to attend and to “go Agile”, but who really don’t buy into the whole change thing. 

Where am I from?

I’ve started doing the following as part of my introduction in classes; heading them off at the pass so to speak. I’ll talk about my background. How yes, I’m an agile coach and trainer, so I’ve done some academic-oriented work: studying, reading, and the like. However, I’ve also spent 6 of the last 8 years as an internal Software Development organizational leader and agile coach. So, I’ve been living in the real world, with real world dynamics, challenges, and constraints. Given that, I’ve been able to generally make agile work in those contexts. Every idea or technique or practice or principle that I bring up, I’ve seen work in practice…in the real world.

Was it easy in all cases? Hell no. But did it “work”. Did it deliver in the “promises of Agility”? And the answer was yes. In fact, each organization that I was a part of transforming our customers, organization, and teams experienced significant benefit as a result.

So I try to tell students and attendees to listen with an open mind and not simply discount things because they might appear to challenge their current culture or practices. The key from my perspective is the open mindedness to simply consider Agility within their contexts. 

Another point being—I wanted to set the record straight that I wasn’t from another dimension or another planet. That yes, the last time I checked, I did live in the Real World.

Let’s get back to some specifics

So I thought it would be good to share some specific encounters of a “real world” kind. Here is a representative set of examples:

1. But Bob, that whole notion of writing User Stories that are intentionally incomplete to drive feature/work conversations during the sprint sounds like a good idea. But around here, in the real world, I’m the only Subject Matter Expert who knows exactly what to build. So, I absolutely need write everything down well in advance. I don’t have time to work with the team and answer their questions in real-time. Heck that would be an incredible waste of my time.

2. But Bob, I know the book says that we need an individual to serve as the Scrum Master and Product Owner for each of our Scrum teams. But I don’t have the headcount to go out and hire those folks. In the real world, I have what I have. So, we need to turn our functional managers into Scrum Masters and Product Owners (dual roles) for every 2 Scrum teams we have. Clearly it can’t be that hard to do these jobs—most of the responsibility is theirs already.

3. But Bob, I clearly understand that our traditional metrics and project tracking will probably drive the wrong behavior in our agile teams. However, our C-level leadership and our PMO insist that we provide exactly the same metrics for our agile adoption as a means of measuring productivity levels before and after the adoption. Yes, we realize that they’re different, but we have no choice. The teams will just have to adjust to the fact that these real world metrics are still viable.

4. But Bob, you must realize that we work in a fixed date & fixed scope environment. Our leaders will absolutely not accept a “We’ll know it when we see it” commitment level. That being said, we realize that agility struggles with this sort of commitment. How do we meet our real world commitment guarantees and still maintain our agility? Keep in mind Bob that we cannot negotiate or waffle on scope. We need to be able to make a 100% commitment and then deliver on that commitment.

5. But Bob, this notion of a “self-directed team” seems to be central to the agile methods. However, we have a very seasoned management team that understands our business and technologies very well. There is simply “no way” we’re going to ask them to defer their opinions, directions, and accountability to their respective teams. Not in the real world. We feel that they are “good” managers that effectively delegate—so they already support “self-direction”. In other words, “trust, but verify”.

Why only 5?

But Bob, in the real world, there must be many more examples than you’ve provided of these sorts of exchanges. I agree. But I don’t want to be the only one offering the examples. I’d like to gather some from readers via comments.

Why?

Because I think we can learn quite a lot about agile adoption and transformation success by examining the resistance we regularly encounter. Instead of viewing resistance as such, perhaps we can learn from it, examine its root causes and drivers, and become better change agents as a result.

I’m also simply interested in hearing your stories. So, any “but, in the Real World” stories out there?

Thanks for listening,
Bob.

Don’t forget to leave your comments below.