You’re sitting in a meeting about how to improve your team’s way of working. Someone confidently says, “At my last company, we did daily standups at 9 AM sharp, and it totally transformed our communication.” Another person counters, “Actually, we tried that and it was terrible—4 PM worked much better for us.”
Sound familiar?
Most of us have a relatively limited range of experience with different ways of working. And that creates an interesting challenge: we tend to advocate strongly for what we’ve personally seen work, without always understanding why it worked in that context.
The ScrumMaster who’s had exactly one successful agile transformation is a classic example. They might insist that you need a physical task board with color-coded cards because “that’s what made the difference last time”—even if your team is distributed across three time zones.
That example highlights the problem: your current context probably has important differences from past situations. And if you haven’t experienced a wide range of variations, it can be hard to tell what works most of the time and what only works under specific conditions.
So how do you avoid this trap? How do you turn your group’s collective experience into useful insight about what might work in your context?
Here’s a practical approach:
- Share experiences completely, not just the headlines.
- What specific benefits did you see?
- What challenges did you face?
- What conditions were present that might have contributed to success?
- Look for opposites.
- Play “What if?”
- “What conditions would cause this practice to fail?”
- “In what context would the opposite approach work better?”
- “What would have to change for this not to work?”
-
Instead of “Pair programming worked great for us,” dig deeper:
-
When someone shares a success story, actively seek contrary experiences. These differences often reveal crucial context factors that matter more than the practice itself.
-
Even without direct opposite experiences, imagine them:
Such a conversation might cause the team debating the time of their standup to discover it wasn’t actually about the time of day, but about when they had the most team overlap and the fewest interruptions. The 9am option might have worked great when everyone was coming into the same office and it provided a strong kickoff to the day. The 4pm option might have been better for a team with other meetings in the mornings and people in multiple time zones—maybe 4pm was the easiest time to sync up the whole team and make a plan for the next 24 hours. Given that extra context, the new team can ask, “So what would work here?”
Once you’ve teased out the context and principles, use your collective insights to design experiments that:
- Test your assumptions about what matters
- Start small and expand what works
- Include clear measures of success
- Have a defined timeline for evaluation
The goal isn’t to find the “one right way” or to prove whose past experience was “correct.” Instead, aim to understand the context factors that make different approaches more or less effective.
The next time you’re in a room full of people advocating for their favorite practices, try shifting the conversation from “Here’s what worked before” to “Let’s understand why it worked and what that tells us about what might work here.”
What context factors have you discovered that made a big difference in your work? What assumptions about “best practices” turned out to be context-dependent? Share your experiences in a reply or on LinkedIn.
Last updated