Ability to turn on/turn off workloads?

[Brent Ellis]

What do we do about Yammer Groups that don't need the other workloads?

Will we have the ability to turn off and turn on workloads for an Yammer-based O365 Group?

We have been actively moving "collaborative" groups out of Yammer and physically into Groups and decommissioning the use of Yammer for their team discussions.

All that we want to have left are large "forum" type discussion groups that don't need all of the O365 Group Services.

[#2]

Hi Brent - new groups will have all the workloads provisioned automatically.

There isn't a way to control which are provisioned. So yes, it's over provisioning for some use cases as you mentioned, but it's also reflective of how a group's needs can change over time.

I've already found the need to have a Planner board and OneNote for large groups - which I was surprised about - but realized it helps as communications to large groups of people have quick reference materials at hand for events, meet up notes etc.

[#3]

Ya, but the idea of Joe User tasking our CEO from the "watercooler group", ugh...

[#4]

I understand.

Trust in employee behavior though - it would be possible for Joe User to email a task or assign one to anyone regardless. My feeling it that the needs of evolving groups and maximizing flexibility is better one to optimize than potential accidental/ignorant behaviors of one person... Just my humble opinion.  

[#5]

Hi Naomi

the way we are using groups and yammer this would not make sense at all. We have a O365 group where we keep all the documents and pages together in one SharePoint site. However we need multiple yammer groups to keep the various discussion topics separated. 

As I understand this would not be possible in the future while not having a O365 group for each yammer group. 

This will get VERY confusing for our users! What's your aproach to that?

[#6]

There are probably a couple different ways you could still offer your model with the Connected Yammer Groups (plus some added benefits). Maybe to add some examples, lets say the HR Connected Yammer Group is the one that has all the official HR forms in its connected SPO document library, then there are other Connected Yammer Groups like the New York Sales Team and the Branding Experts group. The New York Sales Team could link to the official HR forms a variety of different ways like pinning it in the Yammer group, or adding a link to the connected SPO team site, or adding a link in a Yammer message, or even having a shortcut in the New York Sales Team's connected SPO document library. The added benefit is that the New York Sales Team and the Branding Experts group still have all the collaborative tools for their groups and the ability to manage the group's permissions and access settings without impacting the HR group.

[#7]

Hi Bill 

thank you for your answer and the suggestions. I understand your approach, however I think that a fixed 1:1 relationship between O365 groups and yammer groups is way too limited. What if HR needs a second yammer group in order to separte discussion topics? 

Btw - the same goes for the planner: A O365 group can't have more than one planner. However if I need to plan more than one work stream with people that belong to the same project (organized in a O365 group) I will always get a new O365 group. 

I know that planner is off topic here, however it seems to me that you're following the same integration pattern with yammer as you did with planner. And I just believe that this approach is way to limited, does not scale and is very confusing for the user, as he will be "lost in groups"...

[#8]

Not exactly on topic of the initial question, but since this discussion is evolving into keeping an overview of discussions through different Yammer groups: Aren't we missing a good discussion board app (like te one in the classic Sharepoint TeamSite)?

Since the introduction of Sharepoint Modern TeamSites the Discussion board app does not longer work (newsfeed gone, mentioning impossible); so we are looking at Yammer as a replacement to hold discussions. But Yammer is about conversations (which is more then just discussions), so the discussions become scattered between all conversations in the Yammer group. It also has no discussion features as offered in the classic Sharepoint TeamSite.

Having 1 Yammer group for each discussion item seems an absurd way of approaching this issue.

Would love to hear how you deal with this!

[#9]

I share your concern about the number of "groups" individuals will be a member of, and how they'll be organized / managed. However, I also remember how many distribution lists I was a member of when I worked for a certain large tech company... the only difference was that with DLs, I rarely saw that list. I only experienced the intense pain every day of emails flooding my inbox from all of the groups. With O365 groups (whether Outlook, Teams, or Yammer-based), I self-select which group to pay attention to at any given moment.

To your point about 1:1 relationships, I wonder if you were expecting a model that I was early on when Microsoft starting talking about groups. I expected them to build the construct of a Group as just a collection of people that had rights to whatever service you created the group from (SharePoint, Yammer, etc.). Then, you should be able to quickly "spin up" or "attach" any of the other services on-demand instead having ALL of them created for you by default.

Is that closer to what you have in mind?

[#10]

---

@Chris Slemp wrote:

I expected them to build the construct of a Group as just a collection of people that had rights to whatever service you created the group from (SharePoint, Yammer, etc.). Then, you should be able to quickly "spin up" or "attach" any of the other services on-demand instead having ALL of them created for you by default.

---

That is EXACTLY where I thought things would go, and still think they should go.

Instead, I dont market Groups as "membership", because they are not.  Membership to me is just one of the services of a Group.  I market it as "collaboration in a box".  They are many front-ends destinations without a logical front-end destination.

I used to like to keep things clean and organized, now that one of everything gets provisioned, there is unused digital garbage all over our environment.  My point has been SOMETIMES I need just a Yammer discussion group only.  SOMETIMES I need all of the services.  And there are valid business reasons why some groups don't need those other services/tools/workloads.

[#11]

I totally agree! 

It's o.k. that a group comes with a predefined set of services. This makes it easy for the user to create a group and start working with a basic set of tools. However it's pretty obvious that a group will need more than one instance of some tools over a period of time. 

And I just don't understand why this is not possible. It makes me wonder if 

a) I'm having a wrong understanding about the concept of groups

or

b) Microsoft is designing groups without any real life scenarios in mind...

Any ideas?

[#12]

I'm interested in learning more about your scenario, Erich. Would you mind sharing a hypothetical example of where you see the need for "that a group will need more than one instance of some tools over a period of time" ? Thanks in advance!

[#13]

I'm interested too. I tried writing a few examples, but in each case, I asked myself "why wouldn't that additional Yammer group (for example) like to have its own file storage, planner board, or calendar?" or more importantly, "why would we prevent it by spinning up a new Yammer group tied to the same membership list?"

[#14]

Hi Bill 

thanks for asking! I can give you a real life example - it's an actual case of how we are using groups and yammer in our project right now. 

We started about three months ago with a new project in which we are evaluating and designing the adoption of O365 as replacement for the on premise SP 2010 solution. 

We started using O365 for all team collaboration within the project. 

• We started by creating a group and inviting around 30 project members and stakeholders.
• The project consists of several streams (product design, technical integration, application migration, etc.)
• We decided to keep it all together in one group, as we are mainly working on concepts (word, ppt, etc) which we want to keep in one central place. (one SP site / Document Library) 
• We also wanted to use planner for task tracking, however one single planner was too limited to keep track of all the tasks from the various streams. So:
  • The technical integration lead decided to create a new planner instance to keep track of their tasks -> BOOM there was a new Group called "Technical Integration" 
  • Users were now confused where they should collaborate : in the main project group or in their own brand new group...
  • The project lead therefore had to put a file into the document library saying "do not store any files here" 
• First we were using our group mailbox for communication to all group members. However this got cluttered pretty quickly as the group became bigger and the topics more widespread
• We decided to switch to yammer for sharing information. We quickly found out that we need more than one yammer group in order to separate product design discussions from technical integration discussion. 
• Right now we are using three different Yammer groups for the various discussions 
• As we move along, I can imagine that we will need some more Yammer groups for discussions around security, user enabling, rollout etc.
  However I'm most certain that we will not use more than one group to organize our files, SharePoint Lists shared calendar etc.

As it was with planner it will be with yammer: one instance was not enough for our group, however a second instance created a new group. Result: users were confused.

If you work long enough with O365 you forget how overwhelming and intimidating the user interface is for new users. There's so many slightly different (not to say redundant) ways to do the same things, and users easily loose the overview of where they can find their information. 

I'm less concerned aboout the "digital garbage" produced by "overprovisioning" in some (or most) use cases. I'm worried about the users getting confused, lost and end up being less productive!

I hope you can pass this along and keep it in mind for your product design. I'm aware that this also concerns other teams - maybe you can pass this feedback along.  Thank you! 

[#15]

Can you shed light on the splitting of Yammer groups for the purposes of "separate discussion topics"?  Examples to illustrate?

[#16]

At the heart of this discussion is the boundaries of a "team" or "project." You made the decision to put all files for the project into one site. I could argue that it's just as painful to put all of the design team's files in the same place as the security team's files, especially now that you can include links to other file libraries as a "file." Your decision to break into multiple plans, in my view, creates a headache for the PMO to check across multiple plans. In other words, I might organize your project differently in a way that perfectly aligns with O365's patterns. But I don't know your project or your team...

Only a team can decide when it's time to break the conversations, files, or other tools into multiple streams. O365 designers can't and shouldn't make that decision. So, at some point the decision must have been: do we give every "fork" of a team/project all the tools out of the gate, or do we provision tools on-demand? I suspect the latter is fraught with other kinds of user confusion or friction, and so I see the logic in the other path too. 

[#17]

According to this blog post from Microsoft Teams,  there will be the possibility to have more than one planner per O365 group in the future:

https://techcommunity.microsoft.com/t5/Microsoft-Teams-Blog/Our-Vision-for-Planner-in-Microsoft-Team...

-Users will the ability to have multiple plans per Office 365 Group within Planner.  When we complete that work, you’ll also be access any of the Plans you started in Teams as well. 

---

This makes totally sense, and this is also where the yammer integration should be heading towards. 

I can live with the fact that for a first release this is not yet implemented, however it would be nice to see some statements that it will go there. However from the discussion we're having here I'm getting the impression, that no one of the yammer product team even realizes that the current 1:1 integration can't be the final solution!?

Chris - I agree with you: 

At the heart of this discussion is the boundaries of a "team" or "project." You made the decision to put all files for the project into one site.

---

However there is no right or wrong way to do it - the users need the flexibility to organize it the way it works for their specific situation. The only "right way" for a integration of yammer in groups is therefore to give the user the choice.