Maturity Model for Microsoft Teams Development

During the Collaboration Summit I had the opportunity to present on Microsoft Teams Development. It was a great experience to catch up with old friends, make new ones and simply get inspired by cool stories again. I for one surely missed that! While preparing my session I couldn’t help to implement some low-code scenarios in the Microsoft Teams experience and while doing so I started thinking about Fusion Development scenario’s.

Microsoft Teams Development

We have most likely all seen the different Microsoft Teams Development scenarios. Building solutions for Microsoft Teams or extending the Microsoft Teams experience can be done using different components. Ranging from tabs to full integrations where you work with data from Microsoft Teams. Those different scenario’s all have a different developer experience and might require different components in Azure as well. The general concept is that you use the Microsoft Graph to work with the data. And that you use the components from Microsoft Teams depending on your requirements. If you are new to Microsoft Teams Development a great place to start is the getting started overview. If you are considering building solutions for Microsoft Teams, I love this visual to describe the different possibilities

Samples

Considering a simple scenario, I started with a demo on the Teams App Package and how to expose a SharePoint site as an App. The advantage of this scenario is that you can walk through all App package components without having to write Microsoft Teams specific code. And there are a few great SharePoint samples out there so things look good straight away.

Using Power Automate you can also work with some more complex scenarios. You can use adaptive cards to capture results of your users. In a demo we went through all options to retrieve users input and since we use a Flow there is almost no development involved.

But adaptive cards can also be used in Teams itself and send from custom applications. It does require some additional configuration and some code; but the advantage of full control can help you make things even prettier then with the out of the box scenarios.

Using a Maturity Model

But when you are thinking about all those options and all those technologies you might lose track of the business side of things. When you are building software there is (in most cases) a business case. So when designing capabilities I love the Maturity Model for Microsoft 365, they describe in detail how to design tools for different competencies within your organization. With that in mind I figured you could use a somewhat similar approach when designing software for Microsoft Teams. Being part of both Collaboration and Communication competencies the Microsoft Teams solution can be a bit of a weird duck; but conceptually speaking each component you develop requires a certain level of maturity in your organization. Showing a tab requires less from your users compared to a chatbot they can interact with. With that fact we took the idea of different maturity levels and plotted the capabilities for Teams Development and plotted them on those maturity levels.

Given it is not an exact science: some companies might require you to shuffle some of the capabilities to another maturity level. Yet it is a great image to discuss development opportunities in Microsoft Teams. We use it quite often just to start discussions to make sure what we are building is the correct way. Let’s say you want to build a chatbot and leverage in Microsoft Teams only to be confronted by the fact that a large portion of your users are not using chat options in the Teams client. Or that you build a notification functionality to learn that users just ignore those triggers as they are in Outlook all day.

Hope it helps you when think about Teams Development options 🚀.