Have the bravery to try things you know won’t work
Being a manager of a software team can be challenging but can equally be a great opportunity to learn. To learn what works, what doesn’t work. Learn what helps people be their best and what hinders them.
It’s easy to assume you know the “best” way to do things. Whether this be through experience or intuition, it’s a managers job to enable the team to do things the best way. But do you always know the best way? I’d say most of the time you don’t — I certainly don’t.
Software teams, in fact any team is a complex system and sometimes what you assume to be straight forward and obvious isn’t. The only way to grow as a team, as a complex system, is to try things. Constantly try things, even if everything you know about an idea tells you it can’t possibly work.
At Gnatta we have many streams of work ongoing at any given time and to manage this effectively requires some degree of segregation. We divide our wider team into smaller teams and those teams need a way of updating each other daily.
Dogmatic methodologies like Scrum tell us that daily stand-ups cannot possibly function with more than 6 or 7 participants and our own bitter experience told us that daily stand-ups with the entire team, just don’t work.
In the past, we’ve had 40 minute long stand-ups where person after person would slavishly go into detail about what they’d done and what they were planning to do — 40 minutes of that can feel like a lifetime.
Follow the well worn path
Having fewer people in more stand-ups was clearly a no brainer so we split the team into smaller teams. These stand-ups were spread throughout the working day to allow people to attend more than one.
Developers loathed them (developers loath most meetings!) The meetings left precious little time in the calendar for other team tasks but it seemed like they were unavoidable and necessary.
More worrying than a fragmented calendar was the unease emerging from the team. Complaints were raised frequently, developers lost their shit on Slack, bashed at keyboards in that way only developers can, passive aggressive tickets citing “context switching” and “time wasting” appeared on retrospective boards — the troops were not amused.
And yet, if asked to pinpoint exactly what the problems were — they couldn’t. They “just didn’t like it”.
Over an hour every day was being wasted dragging various sets of people into various meetings they didn’t want to be in. An hour a day, 5 days a week — it soon adds up.
The only constant is change
When I get a situation like this, I have to change something. It’s my job as a manager to do this. Against my better judgement and with the bitter memory of 40 minute stand-ups still present in my mind, we agreed to experiment with a single daily stand-up for the wider team. I was prepared to give it a week.
4 weeks on and we are still “experimenting” with the single team stand-up. There is no sign of it falling flat on it’s face, quite the opposite. Something unexpected happened. Not a single one of the stand-ups in the experiment has lasted over 12 minutes and with no noticeable loss of communication. I haven’t heard a single negative report since the experiment began.
Why did it work?
How could it work? The same team had previously proved this concept as unworkable and tiresome so why, just by trying again did we get a more positive result?
Teams evolve. It turns out that in isolation, each of the smaller teams had been coming up with novel and intuitive ways of reducing the length of time needed to get through their stand-up. Each team had a few neat ideas which on there own gave moderate improvements but when brought together gave us significant time savings.
It had to work. Nobody wanted to go back to “many” stand-ups and nobody wanted 40 minutes of drudgery, so the team made it work. People focused, prepared ahead of time, and got far more pragmatic about what to discuss in stand-up and what to leave for later. It has now become a challenge and a matter of team pride to keep the stand-up under 15 minutes.
The point, is not about how many meetings we have or how many minutes we save. It’s not even about developer happiness or team culture (but that really matters a lot). It’s about being brave enough to try something even if you are convinced it won’t work — because you may just be wrong.
Listen to what your team are telling you, even if you are overwhelmed with doubt. Listen and be prepared to change. Try something you “know” won’t work for your team and see where it takes you.