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:
- 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.
- 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.
- 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.
- 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.
- 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.
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,
Don't forget to leave your comments below.