3-part illustration of people voting and people creating a map

One of my go-to interview questions is, “What would you do if you were asked to change the practices in your current team?”

95% of the time, it triggers rich conversations. First, it’s system thinking. We talk about how the candidate views their team as a living system with all its dynamics and inefficiencies. Second, it helps me assess whether the candidate would be a good fit with our culture. Because when we talk about practices, we’re actually talking about culture and values.

There was a moment in my career when I realized that I’d stopped asking this question of myself. My team had reached a level of maturity and we’ve been viewing ourselves like a well-oiled machine for a long time. But in this comfort, our day-to-day practices stagnated. We weren’t striving to be our best version as a team and this was putting our culture, performance, and happiness at risk.

How could we keep our practices up to date as we evolved as a team?

What we talk about when we talk about team practices

Culture is everywhere. From how we translate an idea to a piece of work to how often we discuss ideas with a teammate to our general ways of working. 

“Company culture isn’t a moment in time,” tweets Jason Fried, founder and CEO of Basecamp. “It’s not something you write down. Culture is the by-product of consistent behavior. Your current company culture is essentially a 50-day moving average of your actions.” At the team level, a culture with the right blend of structure and flexibility will lead to the best performance. It helps everyone build productive habits and keep their focus on solving problems. It even increases confidence by providing guardrails that protect people from the fear of making mistakes.

However, those structures may need to evolve – that’s where the flexibility comes in. Teams might grow or shrink in numbers. Eventually they get more mature or face a new problem domain. In those times we often find our current practices are not serving us as well as they used to. If this is happening to your team, it’s probably reflected in your performance metrics. 

The problem’s that inertia tends to keep us in our comfort zone – we know where we perform well. Or, used to. Stepping out of our comfort zone so we can improve feels risky and takes conscious effort. I sometimes find myself biased towards the practices I’m familiar with even though deep down I know a change might make my team much better. That’s my cue to push myself to give change a chance.

Change as an individual is hard enough. Changing a team’s habits while keeping the team efficient is an even trickier thing. Teams are complex systems. One property of complex systems is that it’s very hard to predict how the system will react to a change in its dynamics.

The agile guide to winning at team development

Alright, we need to change our practices… but how?

One way to handle this is by letting someone in a leadership role define new practices based on their experience, observations, and gut feeling. But this may create a controlling environment that many teams don’t want, as we mostly prefer autonomy over control. We want to reach alignment without giving up our autonomy. Because when a team has a say in things, they’ll own their work and be more engaged.

A better way to handle this situation would be to involve all team members in this process. This gives everyone a feeling of autonomy and power to influence ways of working. It also means that, because every right comes with a responsibility, everyone will feel more responsible for the practices and results produced. I highly suggest including new joiners in this process as they have a fresh perspective that helps them spot inefficiencies that others are too familiar to notice.

Hypothesis-driven team rituals

One great way I’ve seen this work in one of my earlier teams is a meta-practice we adopted. Let’s call it “hypothesis-driven rituals.” 

As I mentioned earlier, there was a time when my team had fallen into “comfort zone inertia.” We were resisting change to the practices that were no longer working well. Some of them had become outdated as our maturity and team size increased. We resisted change by challenging ideas in long, detailed, unproductive discussions. (Analysis, paralysis!) Eventually, we started to approach this problem the same way we approach our product: iterate, be data-driven, experiment often, and learn fast.

We encouraged everybody in the team to come up with ideas in the form of a hypothesis whenever they saw an inefficiency or a team metric declining. It went like this:

  1. Create a hypothesis with a success metric.
  2. If the majority agree it might produce better results, move forward.
  3. Set a checkpoint in the future when you’ll decide whether to keep the change or pivot or revert depending on the success metric. Make sure to give enough time to see its effects.

Here are a few simple examples inspired by the syntax of hypothesis-driven development. The structure can be as flexible as you wish, as long as it works for you.

  • We believe that grouping tech-debt tasks that share the same technology and working on one group at a time
    Will result in less context switching
    We will know we have succeeded when we are finishing more tech-debt stories per sprint than before
  • We believe that having story kick-off sessions with our Product Owner will help the developer(s) understand the story better and uncover missing use cases in the story
    We will know we have succeeded when we produce fewer bugs because of a missed edge case
  • We believe that making tea at 5 pm once a week to have a fun chat will help us empathize and understand each other better
    We will know we have succeeded when the team feels they’re in a safer, happier workplace(we measure with simple voting)

In thinking about how practices create the culture, one great by-product of this meta-practice is creating a culture of continuous improvement. The impact was clear. It showed everybody in the team that change was okay, that it’s a sign of evolution. 

One critical survival skill is the ability to adapt. Therefore, our processes and practices need to adapt as we (or our environment) change. With hypothesis-driven rituals, or whatever you want to call it, everybody is responsible for keeping the processes healthy and the team performing well.

Can hypothesis-driven rituals boost your team’s performance?