… something on upping the number of meetings
In this blogpost I describe the advantages for a software team of having dedicated ‘chewing the fat’ time whilst working remotely, which maintains the coherency of a team which can be looser than when co-located.
A team not staying in touch enough can fall back to being a ‘Working Group’.
Who would want more meetings?
I know, crazy, right?
Who on earth would want to introduce *more* meetings? Well, I would.
With caveats of course. As long as they deliver value; either in terms of ‘work done’ or just in terms of helping or strengthening the team.
Not surprisingly since March my team have all worked from home, I can’t say it has particularly affected the ‘output’ of the team as such, but what I can say is that it has affected the ‘teamness’ of the team — it’s coherency.
To begin with my team had some fairly ‘meaty’ tasks to come together on, and we did a fair bit of Mob Programming, however the tasks since have not been that conducive to working like that.
… we still stayed in touch
Don’t get me wrong, we still catch up every day for a standup in the afternoon, and a ‘text-only’ catch-up in chat in the morning (I almost called it a chat-up), as well as regular weekly planning meetings and reviews, demos and retrospectives. We’re also very regularly discussing things on slack.
But I didn’t feel the team were getting together to really chew the fat.
Two opposing trends
I know doing everything ‘async’ is apparently the new Nivarna to many, and it’s great, it certainly helps with needing to flex for different things happening in the strange world of 2020, including childcare; but it can only take you so far.
Interestingly the other ‘Zeitgiestey’ trend is quite the opposite, for Mob Programming. Everyone one in the room together, working on the same thing at the same time.
The danger is that each member of the team carves out their own niche of work, unconsciously (or otherwise) so that there is no overlap in activities between them and their team-mates; everyone just works by themselves effectively. This is what is known as a Working Group.
“Working-group members don’t take responsibility for results other than their own” — ‘The Discipline of Teams’, Jon R. Katzenbach and Douglas K. Smith
The Ceremonies weren’t enough
So, despite the team having time together to plan and present the work, it felt as if there was a danger that the work itself could become individualised. Think about the Pull Request (PR) system, which is heavily used at Redgate, is a PR owned by one person?
If there are comments that come back from a code review is it down to the author (and only the author) to address any concerns? If they’re off ill does it sit there until they come back? Or does someone muck in and see it through to completion?
Obviously you don’t want people competing to finish it off and racing to check in their updates, but with some simple coordination, some one could step in and see work to completion — that is cooperation if not collaboration.
…it all started from a retrospective
It started specifically when from a team retrospective that came out with an action to have a monthly meeting to review the data we are getting back from our product out in the wild, not only so can see what features are being used, but also so we can deliberately iterate on it.
After three or four of these, it turned out they were really useful, and that it was great to get the whole team in a conversation and review in depth what the data was telling us.
This also gave an opportunity to see if there was any data missing that we weren’t collecting, or a graph of the existing data that would tell us something.
…let’s turn up the good
This led me to thinking that it might be useful to take some similar time out (offset by two weeks) to have a step-back review of the codebase as a whole — what problems were we seeing, are there missing concepts or abstractions, is some area getting messy or out of hand, etc.
A third opportunity was when we were asked to fill in a Team Practices survey, this was about aligning best practices across Redgate, with each team giving a traffic light status against a number of criteria; eg do we hold post-mortems, are we compliant with Open Source Licenses, do we have a warning and error-free build, etc.
We were actually encouraged to do this ‘async’ but it just felt too much like this would end up falling on one person’s shoulders — which a similar previous initiative had — so I suggested we got together for an hour and talked through each category.
This had the advantage that the knowledge was shared across the team, and responsibility for actions could be taken on at the team level, even if one person did ultimately do them.
As it happened an hour wasn’t enough, so we’re about to do a second session, but as I argue in ‘…something on Minimum Viable Process’ better that than having a single interminably long meeting where everyone loses interest.
…let’s turn up the good
The definition of a High-Performing team is one where the whole is greater than the sum of the parts. This comes from the team regularly interacting, and tackling problems together —where team members learn from each other, knowledge and understanding is shared and better decisions are made by opinions and options are challenged.
Sometimes you do just need to thrash things out in a way that is not possible in a slack/email/twitter thread.
By getting the team together to have deep discussions, and not just to have ‘overview’ meetings and ceremonies, a better team can be forged.
