Year: 2016

Understanding Office 365 Groups

Published December 5, 2016

When Microsoft Teams was announced at the beginning of November 2016, I posted an article that attempted to explain the different social networking products available from Microsoft and the advantages/disadvantages of each. Since then, it has become apparent to me that there continues to be a lack of understanding about what Groups are, what they bring to the table, and where they fall short. This post is an attempt to help clear up some of that confusion.

To begin with, Groups isn’t a product in an of itself, it’s an infrastructure. Specifically, an Office 365 Group is a specific type of group in Azure Active directory. That’s it. They have a few properties, and they contain members, but outside of Office 365 administration or Azure Active Directory admin, there’s really nothing to look at. What is unique about them is that the Office 365 services are becoming increasingly tied to them, and creating one of these groups will provision multiple artifacts in multiple Office 365 services.

The value of Groups is really in the workloads and services that they tie together. This is where it starts to get a bit confusing. The way that I see it, there are currently 9 workloads (team sites, file storage, group inbox, enterprise social, group chat, notebook, plans, calendar, and report workspace) offered by 6 different services (SharePoint, Outlook, Yammer, Microsoft Teams, Planner, and Power BI). Arguably, Group inbox, enterprise social and group chat could all be considered conversation spaces, but my earlier article makes the case for considering them separately. Also, Skype for Business is notable by its absence, but I consider Teams to be the logical successor to Skype for Business.

A summary of the different workloads, and the services that offer them can be seen below.

This is a description of the various workloads offered by the component services, and it’s relatively straightforward. The only overlaps (if my earlier assertions about the different types of social are accepted) are group inbox services being offered by both Outlook and Yammer. Since Groups created and managed by Yammer will be kept distinct from other groups, this shouldn’t be the source of too much confusion.

The picture gets a little murkier however when we talk about the way that users will interact with groups, which is through a client application of one form or another. All the constituent services have at least one client application that interacts with Groups, and several of these overlaps significantly. A full understanding of Groups includes an understanding of all the available clients.

SharePoint

When an Office 365 Group is created, a Modern SharePoint Team site, which is a SharePoint site collection gets created along with it. This site collection is home not only to the Group’s team site, but to its OneDrive file storage, and to its Notebook (via OneNote). The SharePoint home page is focused on site collections, with Group site collections being called out specifically. From here one can search for Groups, pin favourite Groups, access recently used Groups, and access Groups deemed important by the tenant administrators.

SharePoint has two different clients that touch Groups – the standard web interface and SharePoint mobile. As noted above, SharePoint supplies 3 of the core Group workloads so the SharePoint interface is inherently well integrated. In addition to the native interface, the SharePoint web part framework lends itself to further integration, and indeed there are already two Modern web parts that have emerged that tough other Group workloads. The Yammer web part, which is available today in first release brings enterprise social into the SharePoint interface, and the upcoming Power BI allows the embedding of reports into SharePoint pages.

Groups can be created and managed directly in the SharePoint interface, and group conversations are accessed though a Group conversations link. Now, this launches the Outlook Web App to access the inbox, but when Yammer Group integration is rolled out, it will launch into Yammer for Yammer managed Groups.

The SharePoint mobile application is full fidelity, and modern web parts work with it. Thus, the SharePoint mobile app has all the same touchpoints that the browser interface does with one exception. It is currently not possible to add or manage Groups in the SharePoint mobile app.

There is currently no integration of Group chat (Teams), Plans, or the group calendar in either the browser or the SharePoint mobile client.

SharePoint UI integration with Groups

Outlook

The Outlook web application was originally the only place to go to create Office 365 Groups. Management of Groups is therefore its strong suit and is provided natively. The Group inbox and the Group calendar are also both provided by Outlook (Exchange) and the web client reflects that. The Outlook clients are currently the only tools that allow these two workloads to be accessed natively. In addition to these native workload, the browser client provides contextual like to open the Group Team site, OneNote, OneDrive, and the Group Planner. There is currently no integration between the Outlook browser client and enterprise social (Yammer), Group chat (Teams) or Power BI workspace.

The rich Outlook client included in Office 2016 has almost full feature parity with the browser client. The only difference is that is does not currently provide links for opening the Group Team site, or Planner.

The Outlook mobile app, available on iOS, Android and Windows Mobile is a bit of an anomaly. This client does not integrate at all with Groups. Instead, the Outlook team has published an app on these platforms called “Outlook Groups”. Given that they are known as Office 365 Groups, this name can be a bit confusing. The Outlook Groups app provides native access for the Group inbox, Calendar, and OneDrive files. It will launch the mobile OneNote app for access to Group notes, and it even allows for Group management. It is the only mobile app that allows for Groups management.

Outlook UI integration with Groups

Yammer

Yammer has historically been a completely separate application, and its user interface reflects that. To date, there is no integration with Groups, but this work has been done, and it will be available shortly. An early build of the Groups integrated Yammer interface was recently demonstrated at the Microsoft Ignite conference in Atlanta.

Groups integrated Yammer client

The integration points can be seen in the right column of the UI. Initially, Yammer will integrate OneNote and OneDrive for notes and file storage respectively, and accessing the links will open the respective web applications. The “classic” Yammer files and notes will be maintained for a period and can be accessed at the top of the UI. In addition to files and notes, both Planner and the SharePoint Team site will be available directly from the Yammer interface. There is not integration at all with the Group Inbox, Group chat, Calendar or the Power BI workspace.

IT will be possible to create manage Groups and add/remove members directly from the Yammer interface. Creation of a Yammer group will spawn an Office 365 group, and while all operations will be performed in Yammer, they will be kept in synvc with the Office 365 Group. It should be noted that Groups that are created in the manner will be flagged as “Yammer managed” as opposed to “Outlook managed” and will be invisible to the Outlook clients. All the other clients will be able to see them however.

The Groups integrated mobile client has not been shown publicly yet, so we can only speculate on what it may contain. I suspect it will mirror the browser client, but for now, the only thing that is certain is that it will support enterprise social.

Yammer UI integration with Groups

Microsoft Teams

Teams is the new kid on the block. It is currently available in preview form, so this analysis may be incomplete. Microsoft Teams was built by the Skype product team, and given its ability to do 1:1 conversations, as well as textual, audio and video conversations, it should logically be seen as the successor to Skype for Business. What it brings to the table for Groups is a persistent semi-threaded chat interface. Although it only provides one of the workloads to Groups, it’s UI encompasses most of them.

The Teams client is quite rich, and it provides “sub-team” management. Every team gets at least one channel (General) and additional channels can be added at will. These channels are the containers for the semi-threaded discussions, and each channel also gets its own folder in the Groups OneDrive, as well as a section in the groups OneNote. Creating a channel provisions these artifacts automatically. Any one of these channels can be extended through tabs. Tabs are a way of including content that may be relevant to the channel, and that content can be dynamic. For example, a Power BI report can be added to a new tab and it will always be up to date, or through a third party, a Yammer Group conversation can be embedded as well. Finally, connectors can be employed to automatically add relevant content to a channel’s conversation interface as it occurs – a Twitter feed is a good example of this.

Teams channel showing the associated artifacts in OneDrive and OneNote

The fact that there is already a third-party tool for embedding Yammer conversations speaks to the extensibility of the Teams client as well. Extensibility options are available for tabs and connectors.

The integration of Teams with Planner is notable as well. As I previously wrote about here, the Teams client allows for multiple planner plans to be created within not only a single Group, but a single channel. These plans are NOT available through the Planner client UI, although the resulting tasks are. I would look for this to change in the near future, but that’s the way it works today.

The Teams client (both browser and desktop – they are virtually indistinguishable) has access to the widest set of Group workloads of any client currently. This is partly due to the fact that it is brand new, and as such, is the only client that has access to the Group chats. It has native access to Group management, file storage, group chat, notebook, plans and Power BI reports. It has links to the Group’s Team site, and through third party integration, it can embed enterprise social content. The only workloads that it does not currently integrate with are the Group inbox, and the Group calendar.

The mobile client is unfortunately vastly different. The only workloads that the mobile client works with today are Group chat (as expected) and Group files (from OneDrive. Given the importance of mobile to the modern team story, I would expect this to change. However, if the SharePoint mobile client had access to the Group chat, it could provide a viable alternative.

Microsoft Teams UI integration with Groups

Planner

There is very little integration between Planner and Groups. The Planner UI obviously offers native access to Group plans, but as mentioned in the Teams section, not all the plans – only the one associated twith the root Group itself. Each Plan also offers a link to access all of the files stored in the Group’s OneDrive, and that’s where the integration ends. There is no integration with the rest of the Group workspace. The Palnner browser client is also the only client available. Inexplicably, there is no mobile client for Planner.

Planner UI Integration with Groups

Power BI

Power BI makes very good use of Groups – Groups provides the optimal sharing option for Power BI. Each Group is provided its own Power BI workspace, which is a container for data sources, reports, and dashboards. All members of the group get access to all the assets contained within.

The Power BI browser client is aimed primarily at the use of the Power BI service, but does provide some integration with the other Group workloads. Groups can be created and members added from the Power BI UI (although they are referred to as Group Workspaces). Native access is obviously provided to all the Power BI assets contained within, and links are also provided to the Outlook browser client for access to the Group inbox and the Group calendar. Finally, Group OneDrive files are natively available for the storage of data sources. There is no integration with the rest of the workloads currently.

The Power BI mobile client is all about Power BI – it doesn’t integrate with any of the other workloads, aside from being able to use the Group workspaces themselves.

Summary

To summarize, the modern Office 365 Group provides the membership and access services to 10 separate workloads which are provided across six different products/services. This “Group workspace” is accessed through any of 14 different clients that provide varying levels of access to the different workloads/and services. The choice of client will depend heavily on requirements and will likely lead to a combination of clients based on capability and preference. At the moment, the most integrated browser client is provided by Microsoft Teams, and the most integrated mobile client is SharePoint mobile. A final summary is below.

9 Comments

Completing the Microsoft Reporting Roadmap

Published November 18, 2016

In the recent announcement outlining the SharePoint integration strategy on the SQL Server Reporting Services Team’s blog, there was a statement that was almost hidden that I think deserves more attention. The statement was:

“….in time, we aim to support web-based viewing of Excel workbooks in Native mode…”

This may not sound like a big deal – after all, we’ve been able to serve up Excel workbooks in a browser since Excel Services was initially introduced with SharePoint 2007. However, as per Microsoft’s Reporting Roadmap from October 2015, Reporting Services is their on-premises solution for BI report delivery. If an Excel workbook is to be considered a report, the SSRS absolutely should be able to do it. The roadmap defined four types of reports:

Paginated
Interactive
Analytical
Mobile

I tend to see there being two types of reports, Structured and Analytical. In the list above, Structured corresponds with Paginated, and the other 3 types are different subtypes of Analytical. They four categories do, however line up well with the different reporting technologies available.

Report Type	File Type
Paginated	RDL (Classic SSRS)
Interactive	PBIX (Power BI)
Analytical	XLSX (Excel)
Mobile	RSMOBILE (SSRS Mobile aka Datazen)

The roadmap was primarily concerned with the future of SSRS, but SSRS is Microsoft’s stated report delivery platform for on-premises reporting. The platform for cloud reporting is of course Power BI. There is a third platform for the delivery of “Analytical”, or Excel based reports, and that’s Excel Online. On premises, it’s called Office Online Server, but it is the same technology. The three platforms and their capabilities are shown below.

	SSRS	Excel Online/OOS	Power BI
Paginated	Yes	N/A	No
Interactive	Preview	N/A	Yes
Analytical	Announced	Yes	Yes
Mobile	yes	N/A	Yes

The technical preview of Power BI reports in Reporting Services is available for testing, which covers Interactive reports in SSRS, and the above statement indicates that there is a solution to support Analytic reports in SSRS as well. The Power BI platform does this already, and it is done by leveraging the capabilities of Excel Online. Given the fact that Office Online server provides the same capabilities on premises, it makes sense that it would be used by SSRS when the Excel workbook support is added.

It should also be noted that the above comparison shows Mobile reports being supported by Power BI. To be clear, Power BI does not support RSMOBILE files, but regular Power BI reports are inherently mobile and available through the Power BI mobile client. which is also how RSMOBILE reports are delivered to end users.

The Reporting Services team is clearly very close to completing the vision laid out over a year ago, in the Reporting Roadmap for on-premises users. If the goal is to have parity between on-premises and cloud platforms, the only thing remaining (apart from possible support of the RSMOBILE format) is support for Paginated reports in Power BI. There have been no statements made regarding this capability, but its absence is certainly notable.

The Future of Report Integration with SharePoint

Published November 18, 2016

Yesterday, Microsoft made official what many, including myself had been suspecting ever since the release of SQL Server 2016 – that SQL Server Reporting Services Integrated mode would not exist in the future. With the announcement, we now know the timeline of when that will happen. SSRS Integrated Mode will not be included with the next version of SQL Server. Instead, SSRS Native mode will be more tightly integrated with SharePoint for those organizations that use both products. As someone that has always approached Business Intelligence from the SharePoint point of view, I see this is a good thing.

This change is another step in the process of de-cluttering and uncomplicating SharePoint. This process started arguably with the move away from fully trusted code running on SharePoint, to the newer app, add-in and now SPFx development models that run with SharePoint. When Excel Services was removed from SharePoint in SharePoint 2016, with its capabilities moved to Office Online Server this process became obvious. A decreased dependency on SharePoint allows for simpler, more streamlined architectures, better options for upgrade management, and better, more targeted performance management.

SSRS SharePoint Integrated mode has been with us in various forms since it was first introduced in SQL Server 2005 SP2. The original goal was to simplify the integration of the two products, and to take advantage of SharePoint’s storage and authorization capabilities. The integration has always worked well, but the very fact that these two products were delivered by two different product teams on different media, often on different release schedules has typically led to a great deal of confusion. The SharePoint prerequisite for Integrated Mode leads to far too many SQL servers having SharePoint installed on them.

Managing SSRS in SharePoint Integrated mode requires a combined skill set to some degree as well, with knowledge of both SSRS and SharePoint. SharePoint administrators tend to be intimidated by SSRS, and SharePoint simply mystifies SQL DBAs.

The fact that the two different modes did not always maintain feature parity is another problem. PowerView and several other features are only available through SharePoint integrated mode. This results in entire SharePoint farms being created for the sole purpose of providing reporting features. Since those performing these installations are typically not familiar with SharePoint best practices, these farms tend to be unreliable. The latest release of SSRS 2016 contains a massive number of new features, but many of them in Native mode only, leaving the SharePoint integrated folks with a decision whether to favour features or integration.

A strategy that reduces the dependency of one platform on the other is therefore to everyone’s advantage.

The two operating modes also represent two different code streams for Microsoft to maintain. Given the finite set of resources that is any development team, resources must be spent on maintaining both of these streams that could otherwise be applied to features. A single code stream is simply more efficient.

Preventing the wholesale move to Native mode are several SharePoint integration features that have been employed over the years that are only available in SharePoint Integrated mode.

There has been a SharePoint Report viewer web part for SSRS Native mode since SharePoint 2003. The trouble is that while it does work, it is deprecated, and hasn’t been updated since SQL Server 2008 R2. It also doesn’t allow for parameter binding, or interface control. For all intents and purposes, it is an iFrame embed of a report. The web part that is available through integrated mode allows for parameter interactivity, and significant control of the look and feel. It has been widely deployed. Integrated mode also allows for the reporting of SharePoint list data, and the ability to publish reports to a SharePoint library on a schedule. These features are well utilized in the market today.

Power View reports (RDLX) built on top of SSAS tabular models, or Excel Power Pivot models also require Integrated mode. Compounding this is the fact that Power View requires Silverlight, which does not work in either the Chrome nor the Microsoft Edge browsers.

These integration features will need to be added to Native mode before it will be possible to fully abandon Integrated mode. The good news is that the announcement commits to doing just that. Report embed, Report viewer web part, and SharePoint library destination capabilities will all be added. For Power View reports, a conversion tool will be provided to convert from RDLX into Power BI Desktop (PBIX). A technical preview is already availably that demonstrated PBIX rendering in SSRS.

This announcement signals the end of SSRS SharePoint Integrated mode, but it does not spell the end of SSRS SharePoint integration. The single mode architecture should be more approachable, simpler, and more efficient. It’s a win all the way around.

3 Comments

With Microsoft Teams, Office 365 Groups Can Now Have Multiple Planner Plans

Published November 10, 2016

Microsoft Planner went into general availability in June of 2016. It allows basic project and task management for organizational teams. Like most products in the Office 365 suite, Planner makes extensive use of Office 365 Groups, which provides membership services through Azure Active Directory, and Storage through SharePoint. Creating a new Plan in Planner is one of the ways to create and Office 365 Group – each plan gets a Group. Conversely, each Group gets a Plan.

Adding Members to a Plan – Adding to the Office 365 Group

One of the more requested features on the Planner User Voice site is to break this 1:1 relationship so that a Group could contain multiple Plans. It’s currently marked as “Thinking About It” in user voice, but it appears that far more work has gone into it than that.

Microsoft Teams was released into preview earlier this month, and included in Teams is very tight integration with Planner. Teams is also tightly coupled with Groups (each Team gets Group), and adding the Group’s Plan to the interface is relatively straightforward. Simply click on the “add tab” icon, and choose Planner.

And then give the plan a name and save it.

However, there’s more to it than that. From the Teams interface, it’s possible to create additional Plans. To do so, simple add another tab and repeat the process.

How is this possible? If there is a 1:1 correspondence between Groups and Teams, and a 1:1 correspondence between Groups and Plans, then there must also be the same correspondence between Plans and Teams. As it turns out, that the relationship between Groups and Plans is no longer limited to 1:1. The plans created in Teams are not (or do not appear to be) a part of the group. This can be seen if you open Planner on its own, and these plans will not appear in the “All plans” list, because this is just a list of Groups. The Group itself has a Plan associated with it, but it’s not any of the plans that are created in Teams. However, if you have tasks from these Plans assigned to you, they will appear in the My tasks list.

Conversely, in the Teams interface, I cannot find a way to have this default plan appear in the Teams interface. This is something that could be very confusing for any users that use bot the Planner ands the Teams interfaces. Given that Teams is only in preview now, I can only assume that these user interface inconsistencies will be remedied.

The bottom line to all of this is that it appears that the bulk of the work has been done to allow multiple plans in a single Office 365 Group. You simply need to use Microsoft Teams in order to access them.

2 Comments

Microsoft Teams and the New Microsoft Social Landscape

Published November 2, 2016

Today, Microsoft debuted Microsoft Teams. Microsoft Teams allows teams of people to quickly get together to collaborate in real time. If you’re keeping count, this represents Microsoft third tool in the Social Computing space.

Why would Microsoft want to introduce yet another social computing tool? They already have Yammer, Skype (for business and personal), and Outlook Group conversations. What would be the reasoning for this new product? At one level, Microsoft Teams is aimed at the same group of users that find value in Slack, which is a social tool that has grown in popularity recently and is particularly popular with developers.

I was first exposed to Slack a little over a year ago. I had heard about it, and the buzz around it was that it was the “next big thing”, so my expectations were high. When I did first use it, my thoughts were, “That’s it? That’s all there is to it?”. Functionally, Slack doesn’t really bring anything to the table that we didn’t have 30 years ago with IRC chat. Now, given the demographic that Slack is popular with, they are likely not old enough to remember IRC. Of course, none of this really matters, what matters is that Slack fills a need for immediate, almost synchronous communication with very little structure. Slack doesn’t even support threaded discussions. However, it’s simplicity is its strength and its value proposition, and Microsoft hasn’t had anything in the market quite like it. Until now.

So how does this product compare with its existing Social tools, Yammer and Outlook Groups? When would you use one vs the other?

Microsoft bought Yammer in 2012 and quickly championed it as the cornerstone of its social computing strategy moving forward, replacing the social features of SharePoint Online, and making them optional in SharePoint on-premises. However, at Ignite 2015, Microsoft introduced Groups for Office 365, which included a conversation platform based on Exchange (Outlook conversations). This was essentially a group inbox with a number of social features added such as likes, etc. It was pretty clear that Groups were going to be the underpinning of the next generation of features in Office 365, and this led to quite a bit of uncertainty about Microsoft’s social strategy. The recent Ignite 2016 made it pretty clear that Microsoft is doubling down on Yammer as its social strategy, but that does little to clear up the confusion. What happens now with Outlook conversations? Microsoft Teams would seem to only make it worse.

The reality, in my opinion, is that these tools are not exclusive. Although there are some areas of overlap, I see them at complementary, with each serving a niche depending on requirements, or at the same time. The problem is that they tend to be positioned as competitors. In my opinion, we have an “or” vs an “exclusive or” situation.

I have used Yammer, Outlook Groups and Slack (used here for comparison purposes) of these platforms fairly heavily in the past year. At UnlimitedViz, we have moved most of our collaboration and document management away from Team sites and into Groups. On a side note, we’re very happy to see Team sites now following us over. Yammer is the platform that we primarily used for our threaded discussions. Slack is used by the MVP community for quick and easy chats. I like all three and dislike all three for different reasons.

Once we moved most of our customer focused content into Groups, the value of having an inbox for each group became readily apparent. When going through email, I could simply forward important ones to the group, where it would be retained, and accessible to other members of that group. I could now delete customer email with impunity. From a feature standpoint, this is gold. We also decided to run one of our more significant projects using Outlook conversations alone, and that aspect wound up being a very poor experience. The email infrastructure simply wasn’t built for threaded conversations.

Yammer can infuriate me from time to time, particularly with its unread mark handling (which has admittedly gotten better) and its poor to non-existent search capabilities. Content stored in Yammer is effectively gone as far as I’m concerned, which makes it particularly difficult to have conversations around context. Keeping the content in Office 365 Groups requires a lot of URL copying and pasting if you want to socialize or discuss it in Yammer. A “group” in Yammer is not the same thing as a Group in Office 365. With all of that said, Yammer delivers a superior threaded discussion experience. Its similarity to Facebook makes adoption relatively easy, and its threading keeps relevant content at the top.

Slack is the simplest of the bunch, which makes it the easiest to get up and running. It is almost totally unstructured, meaning that while anything goes, it’s not too long before it disappears. Messages are kept, but I grow weary of scrolling back through the pile of previous messages to find something that I think that I saw. Slack lives in the “now”, and the more current the content is, the more appropriate Slack is. However, it doesn’t take long for a Slack channel to become noisy, with several conversations going on at the same time. It’s like having ADD while being at a noisy cocktail party.

None of these tools on their own deliver everything necessary for a complete social experience, although they are suitable on their own for their own niche. I think that my biggest pet peeve about using these different tools is that I need to jump from interface to interface to complete the experience. This, I believe is where Groups comes in.

Office 365 Groups is (I so badly want to use “are” here… but Groups is the name) designed to be an integrating construct. Groups really has no interface of its own, but when it was originally released, it backed the interfaces of Outlook, OneDrive, and OneNote. Outlook Groups is the Exchange based conversation interface. Shortly afterward, Office 365 Groups became an integral part of Power BI and Planner as well. Integration of Modern SharePoint Team Sites with Office 365 Groups provides a logical entry point for the Group, as SharePoint can integrate disparate UI elements. At Ignite 2016, both Yammer and Power BI content was shown in pages in a Modern Team Site through web parts. It’s not hard to see how these things can coexist in the same container.

Yammer embedded in a Modern Team Site

Power BI embedded in a Modern Team Site

The introduction of Microsoft Teams would seem to muddy the water a little. The important thing is to understand which tool to use under which circumstance. This is a much-discussed topic, and there are hours of presentation material available that discuss it. The decision is a combination of personal preference and applicability to the task at hand, but far too often it becomes a matter of familiarity. When you have a hammer, everything looks like a nail. I wince every time that I’m asked to build click throughs into an SSRS report, or to design a Power BI report to optimize printing – these are two different tools that are good at doing different things. Often, if it can be done with the tool that you know, often time we don’t look elsewhere, even when that other tool is better at that task. Further to this, the “difference” can often be a matter of perception, and in the case of an online service like Office 365, of branding.

These components can be used within team sites as appropriate wherever suitable. With the team site providing the “glue”, it will be possible to surface content from any or all of these tools as appropriate. All the products already require, or use an Office 365 license already, so that is not a consideration. The question is where would you use one versus the other?

As mentioned above, Outlook Groups makes for an excellent Group inbox, but is not great as a conversation platform. This Group inbox also provides the destination for content brought in from Office 365 Connectors. It’s a logical and effective landing spot for content that is sent to the group. If the group needs an inbox, this is it – straightforward. Less straightforward is the difference between Microsoft Teams and Yammer.

I’ve been using Slack thus far as an example of group chat simply because it’s what I have experience with. Microsoft Teams is new, and while it compares favourably with Slack, it also includes threaded discussions. Threaded discussions are something that Slack does not have, but Yammer does, and this makes the decision between the two a little less clear than between Yammer and Slack. IN fact, looking at the UI, it’s a little difficult to spot the difference.

Microsoft Teams threaded conversation interface

Even with threaded discussions, Microsoft Teams has more in common with Slack than it does with Yammer. Microsoft Teams is highly appropriate for small groups that get created, have a relatively short or defined life, and are then retired. Yammer groups are more structural – they are typically managed by someone to help foster participation. Microsoft Teams follow a bottom up approach, where Yammer is more top down. Small groups will participate in a single Team, but too many users will likely make it too noisy to be useful. Conversely Yammer groups can reach the entire enterprise, and like most networks, their value increases with the number of nodes. Microsoft Teams are focused of chat, and Yammer is focused on conversations. If you need to get a quick group of collaborators together around a specific goal, Microsoft Teams is likely the right tool, but if you’re trying to build a community, Yammer is likely a better choice. There are of course other technical factors that may dictate one versus the other, but these factors are subject to change.

This leads me to my suggestion. We can see that the technology is emerging that will allow us to work with these tools simultaneously, as appropriate. Office 365 Groups along with Modern SharePoint Team Sites will become the containers for this convergence. However, if these products maintain their own identity, there will continue to be confusion around which one Microsoft is “betting on” or which one is “the best”. I believe that a rebranding exercise is in order.