How Bots support remote teams, collaboration & communication — Part III

In part II , we discussed the technical elements in building a bot and learned to distinguish what is behind it. In part I, we discussed some characteristics of how a bot behaves and what a user can expect when interacting with a bot. In this post, we will discuss the different types of bots and how an organization can leverage them to increase the performance of remote teams. We at SoftwareDevTools are interested in the way remote teams use Agile methodologies and have build Stand.Bot, a slack bot as an alternative to have asynchronous stand-up meetings.

Bots with Personalities

Bots with personalities

One of the challenges in operating a bot service is understanding a user’s space context. Chat platforms have several ways to interact with a user, they can be classified as follows:

  • Notifiers
  • Reactors
  • Space Reactors
  • Responders
  • Space Responders
  • Conversationalists

We’ll be touching on all of them so you can have a good perspective on what type of bot suits your team’s style best and, in return, have a successful implementation or development of the service.

It’s important to consider the type of technology needed to support cross platform interactions and the increased complexity of each type of bot. Each one of them interacts in either a “room” or “channel.”

Your team needs to recognize their User Space (context) and not just a user’s environment. We will be exploring each type of bot and see how it leverages the User Space / Context to maximize interactions between the team. Some will sprout more communication and flow than others, so you will need to find a balance that will allow the team to achieves its goals.

Serving Notifications

The simplest form of a bot is the Notifier. An easy example of a notifier are the bots on Twitter which are made to send messages based on certain criteria programmed in their services. Another widely used service is Jenkins for monitoring services.

Even though notifiers represent the less complex bots, they still offer benefits to an organization:

  • Easy to implement
  • Require a simple logic to interact with the team
  • An excellent way to propagate a message to everyone on the team
  • Can be used outside bot platforms
  • You only need to know “what to say”

These type of bots are the first interactions that an organization has with bot services. This makes their life time value short lived once everyone is accustomed to the services but they give way to more robust platforms.

Reacting to Users in a Timely Manner

Bots

The difference between a Reactor and Space Reactor is that the latter does remember the space it is operating in. They respond to messages and know where they are receiving the message from, they have the capability of storing the place of the conversation in their service.

For an organization to truly benefit from these type of bots it needs to implement a Space Reactor bot which will allow an organization and its teams to improve conversation.

Space Reactor bots improve the communication of remote and distributed teams by:

  • Bringing only relevant information to the room/channel audience,
  • Allowing anyone from the space access to contextual information,
  • Providing access to the latest data being used, and Highlighting information that everyone in the team needs or uses.

An example is our Scrum Poker Hipchat add-on which sends remote or distributed teams a message of each estimated JIRA issue on a chat room and then provides a message of all the results at the end of the estimating session. We also have a

Reactors do have shortcomings, however. They do not know who they are talking to. But no worries, there are other bots for the job!

Responding to Callers & Spaces

The fourth and fifth types of bot are Responders. Responders support features that know who they are talking to, they can learn from what was said and can react to messages in their simplest form.

An evolution of Responders is those that fall in the Space Responders area, which has all the characteristics of a Responder but adds the value in remembering where it is being called from. Not an easy task, because if the bot serves multiple spaces that require different permissions for the same user it needs to understand it and save it somewhere. Now, multiply that by a number of members on a team and… you get the point… it is very hard to scale.

These bots are the Swiss army knife of the bunch and a team that uses them will experience several benefits:

  • A user can move from space to space and have access to all their information.
  • The bot can serve several users and bring information catered to each user.
  • The space will serve highly granular information, regardless of the user’s level of access.
  • Information shared will be traceable during the lifetime of the space.

Since information will flow more rapidly than the organization’s internal speed, an organization needs to be prepared to leverage Space Reactor bots. It will mark a paradigm shift and some internal areas from the organization might be disrupted. For example, gatekeepers will become obsolete since members with access to the information can share just the necessary data into spaces and remove the information gaps in the organization.

Start a Conversation with Your Bot

A conversation with a bot

Last but not least are the Conversationalists. These bots are the most complicated and the holy grail of the bot revolution. They share the following characteristics:

  • Reacts to messages
  • Knows who they are talking to
  • Can learn from what was said
  • Has a conversational state
  • Knows why it’s being called

Conversationalists deduce why they are being addressed and will try to adapt to the context of the User Space to react accordingly. But it will be very verbose to make sure it can provide the correct data or react properly to the request.

At this stage we only have hypotheses as to the team benefits of using these type of bots:

  • The bot will be the team’s memory.
  • It can learn to anticipate user’s request that are done periodically.
  • Support team members that have missed critical information.
  • The bot can understand the context of the conversation.

Such benefits might seem far off from reality, but technology is evolving at a very rapid pace in bringing to market the platforms to build bots that can learn, understand and respond to human interactions. Just wait and see.

The future is just a chat away from being the now.


Happy planning!

Here’s Part I of this blog series. And here’s Part 2, we discussed the technical elements in building a bot and learned to distinguish what is behind it.

P.S.
Visit SoftwareDevTools to try our Stand.Bot in Slack.
If you are in a remote team, and you use Agile methodologies, you will find these helpful:
Agile Retrospectives for Confluence.

Scrum Poker for Confluence.

PlanningWith.Cards.


Follow us on our networks:
Facebook: /PlanningWithCards
YouTube:SoftwareDevTools
Twitter: @softwaredevtool
Email: hello@planningwithcards.com
And Subscribe to our blog below!

Claudio Cossio

Read more posts by this author.

Subscribe to SoftwareDevTools

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!