When we introduced MS Teams as a trial run in my division we ran into a few problems some weeks in that proved to be rather painful and hurt adoption. We’re now rolling out to the entire company and this is part of our attempt to improve.
Problem : Low visibility due to too many Teams — We ended up with every scrum team, dev team, and test team having an MS Team. While it seemed ok to begin with, these teams would change or disappear completely, people would leave and join, different scrum teams would need to communicate on a project, and project managers would end up in a million MS Teams… It got unruly quickly.
Solution : Teams should be tied to products, business units, or societies, NOT people. I know that sounds weird, (people are teams right?) but people move around and work on many different things.
For example, we have a Team called Business Unit X¹ with channels for the scrum teams, releases, job roles, alerts, etc. That way project managers have good visibility, one scrum team can ask a question in another scrum team’s channel, and every member of the business unit has full visibility of what’s being talked about regarding the daily operations around products. In my opinion that visibility is a huge — if not the biggest — benefit of team chat and should be guarded.
Outside of that we Product X client devs have our own client dev Team, which is useful for tracking our style guide, pull requests, team building, and anything else that is really only relevant to the Product X client developers.
The rule of thumb here is: “will anyone outside of this group need to interact with us in this context?” If the answer is yes, then it’s probably a channel and not a Team.
Problem : High noise to signal reducing visibility due to too many channels — Once we put all our channels into one Team, we now had the noisiest Team ever. Not awesome.
Solution : Channel naming conventions. We prepend the channel name with the product, ie [Product X] Scrum Team X. Following the department we add a label, ie [Product Y] Project — Project Name Z.
That way we add organization to the noise which makes it easier to parse signal.
Problem : Missing important information due to the synchronous nature of chat — you come in after being sick for a day and literally everything is bold or has numbers in red circles. Ain’t nobody got time for that.
Solution : Recognize the limits of persistent chat and that email still has a place. Team chat is great for real time conversation about certain things or broadcasting quick notices. But when something needs real consideration or focus on a single topic, then email is still the king. The main issue with team chat is the lack of a subject line. Email is also asynchronous, so you respond when ready. Team chat not so much, be wary of that.
Problem : Lack of adoption — the devs thought it was magic and the Business Analysts felt like they now had more work.
Solution : Put something that is specifically useful to an individual’s job in there. Just saying “we can all talk in a channel now!” is not an inherent benefit, and for some it’s actually a hurdle. We have tried to nail down clear benefits for individual job roles, but it’s tough. One that does work is ad hoc channels for things that cross cut job roles and have a short life span. Request for Change? New channel with a dev, a tester, a BA and the service manager in there. About to deploy? New channel. Great for visibility and once we can archive channels it’ll be even better.
Problem : I didn’t know that channel existed. — Once it gets busy it’s easy to miss things.
Solution : When creating a new channel always @mention all relevant people. That will notify them to join in. Also add and intro with a lifespan, it’s helpful to know what you’re getting into.
Problem : What do I do now? — the noob guide. Lots of people get signed in, look at the interface blankly, then close it never to open again.
Solution : Have a place for noobs to go. Slack nailed this, MS Teams has failed miserably. There’s no onboarding tooltip sequence or fun bots to show you around so we had to figure something out.
First was to have an MS Team that everyone joins. We added a Random channel and a Help channel and when we got people signed in we walked them through joining and following those channels. That way they were in something and could participate immediately. The Random channel was actually the biggest draw card, turns out when someone’s first experience with something is fun they’re more likely not to hate it. Who knew?
I’m sure there are more problems, but these were the ones that caused us pain the last few months. I hope your team can avoid making the same mistakes me and my team made last year.
PS Outlook automagically creates a mailing list for any MS Team you’re in which will be delivered under groups in the left panel. Surprise.
¹ Names changed to protect the guilty.
Oldest comments (0)