How To Spot an Agile Imposter at Your Next Interview

So here’s the thing. Too many companies claim to be agile shops. Far too many in my opinion. I can’t count how many conversations I had where someone claims their approach is an agile one, but a few questions in, and I’m convinced it’s something else. However, it’s not my place to judge an approach harshly when another feels it’s working, and this post isn’t to play whack-a-mole with agile imposters.

I’m writing for another reason, and it’s to help us talk to potential employers. After all, shouldn’t we know what we’re getting ourselves into before we start that new gig? And asking outright if our future employer is utilizing an agile approach won’t do. Why? First, it’s like when my dentist asks me if I’ve been flossing. Of course I say yes. And second, agile is misunderstood by a great many.

So here are some questions I find myself asking that distinguishes the imposters from the experts, and I encourage you to ask some of these at your next interview. I’ll lead with the most important question of them all:

  • How often do your teams deploy features to your users? If they’re not deploying to their users, how are they learning? And how can they avoid a wasteful pivot if they’re not delivering their work frequently? I’ve discuss before why frequent deployments are essential so I won’t rehash it here.
  • How do you know what to build? I hope they’re asking their customers. If not, that’s a potential sign of an imposter. If they are talking to their customers, who’s having those conversations? Only the C-suite? I hope not. Instead, we hope to hear how team members are involved possibly through usability testing or by inviting users to sprint reviews. A/B testing is another useful approach when mixed with other techniques. If they’re deploying frequently, there should be tons of data points and potential conversations to enlighten them.
  • What kinds of issues have your teams been facing lately? Also, what’s the last big change they’ve made to how they work together? We should be curious what the teams find worth discussing at the retro. Are they even have retros? Imposters often don’t or only have them infrequently. And when was that last big change? How about smaller changes? How long ago was that and what was it? Knowing how often they make changes to working agreements helps us understand how married–or not–they are to the status quo.
  • How are your reviews organized? Who typically attends? This is similar to our question about knowing what to build. Are reviews just a team affair? Or do they invite guests–stakeholders or members of other teams–to gain some insights as to what to do next? Also, what kinds of work are they showcasing and how? Is a product owner or product manager directing the conversations and controlling the keyboard? Let’s hope not. Are guests encouraged to engage in informal conversations with the team to gain understanding and build relationships? Let’s hope so.
  • How do you handle inter-team communication and coordination? This gives us some insight into that nefarious thing some call scaling. It also makes for a good segue into team composition. Are they cross-functional teams? Or are their teams organized by discipline creating a need for a bunch of inter-team murkiness? Do they employ project or program managers to wrangle the complexity or employ some kind of scaling framework like LeSS?
  • What kinds of data do your teams find valuable? I have some of my own thoughts on that matter here. Unfortunately, many organizations have a myopic fascination with velocity, but there’s so many more worthwhile metrics. And note that we asked about what data the teams find valuable. When they answer, do they start answering about what the organization finds valuable instead? After all, some imposters can’t fathom how team metrics would be useful. If they are answering about the team, are they looking at something other than speed, like quality or employee engagement?
  • How often do you change up team composition? Do they reform teams often? Maybe quarterly? And who’s deciding new team composition? Stable teams are paramount to establish trustful relationships so we hope to hear that teams stay together as long as possible. That’s not to say changes shouldn’t occur. There’s any number of good reasons to change up teams, but a constant reshuffling of teams tells us they undervalue relationships and possibly overvaluing employee specialties, as imposters tend to do.

That’s all for today. If you’re preparing for your next interview, I hope this helps you identify the imposters from the experts. If it did, I’d love to hear about it in the comments below.

Do you want to get notified when new posts are published? Leave your email below.

4 thoughts on “How To Spot an Agile Imposter at Your Next Interview”

  1. Once again a very good post. I will keep it in mind at the next interview I have but I also used it as guide if someone asked our team those questions. I feel like we passed but definitely need to revisit the team’s working agreements as I don’t think they have changed in a couple years. Very good point about valuing metrics other than velocity. We definitely focus on that too much.

Leave a Comment

Your email address will not be published. Required fields are marked *