03-07-2017 09:01 AM
03-07-2017 09:01 AM
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.
03-07-2017 09:07 AM
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.
03-07-2017 09:14 AM
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.
03-07-2017 09:19 AM
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?
03-07-2017 12:00 PM
03-07-2017 02:10 PM
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"...
03-07-2017 11:38 PM
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!
03-08-2017 12:14 AM
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?
03-08-2017 06:14 AM
@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.
03-08-2017 06:40 AM
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
b) Microsoft is designing groups without any real life scenarios in mind...
03-08-2017 07:21 AM
03-08-2017 10:04 AM
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?"
03-08-2017 03:34 PM
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.
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!
03-08-2017 10:47 PM
Can you shed light on the splitting of Yammer groups for the purposes of "separate discussion topics"? Examples to illustrate?
03-09-2017 09:09 AM
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.
03-09-2017 11:57 AM
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:
-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.