Help, bots are about to take my job!

I am a self-confessed geek, and the latest shiny tech that has caught my eye is bots — by which I mean apps that work within messaging apps, pretending (or not) to be clever and human.

We use Slack at work and people have started writing bots for it. I am the scrum master for our mobile apps team, so one of the first bots I tried was Standuply, which helps run the daily stand-ups. Setting it up was very easy: you schedule the time when your team runs stand-ups and it asks the usual stand-up questions to each team member via direct message and sends the summary to a given channel or user.

When I scheduled Standuply to run a daily stand-up for my team/channel, it ran for the whole company Slack account! It turned out to be a good accident, because I could see the reaction to it from a wider user group. Most people ignored it (which was to be expected because they didn’t understand what it was and why it was annoying them by demanding them to tell it what they did, what they were doing, and so on).

Its creators seemed to have missed the purpose of daily stand-ups in Scrum, which is to enable communication between the team members. It felt more like a reporting tool, which managers would use to crack the whip.

I think an agile/scrum bot has a lot of potential as a tool, but needs to be done so it acts as a conversation starter and information radiator, rather than a reporting/big brother watching you thing…

For starters, it needs a human name, to make it sound friendly. First impressions count, especially for any newcomer joining a team. My suggestion, instead of Standuply, is calling it Stanley. Or better still, let teams give it a name they like. And we need to give it a personality… every newcomer joining the team introduces themselves and Stanley should do the same by explaining who he is, what he does, how to interact and something interesting/funny about him.

Some teams share a joke every day, others share word of the day (maybe Stanley can share a Serbian word of the day) or talk about the weather (when it’s really bad or really good). Banter is important for the bonding within the team—it acts as ice breakers and conversation starters — and might help users connect to the Stanley slightly better.

When I think what the scrum process trying to do, is a way of building a complex adaptive system. And the scrum ceremonies are the rules that guide teams to adapt themselves based on the signals they get or measure.

Below are some of the things I think Stanley could do.

Scenario 1: hello, I am Stanley
Given
Stanley has access to the team’s Slack channel
When Stanley posts his first message
Then the message will have some background on Stanley, what he does (and doesn’t) and how to use him

Scenario 2: Every morning — social banter
Given Stanley has access to the team’s Slack channel
When the new day starts
Then Stanley posts a joke/word of the day or some other trivia

Scenario 3: Standup — information radiator
Given Stanley has access to Jira
When the team is going to start its daily standup
Then Stanley should check the status of Jira tickets for the team’s current Sprint
And list any tickets that are in blocked column < to highlight blocked tickets
And list any tickets which has been stuck in the same column (excluding ToDo/Done) for more than n time (hours/days) < to highlight if some tickets are taking more than average time for that column (based on tickets story point weight?)

Scenario 4: Sprint Grooming — information radiator
Given Stanley has access to Jira
When the sprint grooming meeting is scheduled
Then post the sprint burndown chart, with forecast < show team how they are doing in terms of meeting sprint commitment. Do they need to prioritise tickets to meet sprint goals?

Scenario 5: Sprint Retro — information radiator
Given Stanley has access to Jira
When the sprint retro meeting is scheduled
Then calculate and post the average cycle time for tickets in sprint (lower is better)
And post the sprint velocity graph for the last n sprints (consistency is better)
And post the recommended number of story points the team should commit to for the next sprint based on the average for the last n sprints
And highlight which sprint columns the tickets spent more time in than average (where are the bottlenecks?)

Scenario 6: Sprint Planning — information radiator
Given Stanley has access to Jira
When the sprint planning meeting is scheduled
Then post the sprint velocity graph for the last n sprints (consistency is better)
And post the recommended number of story points the team should commit to for next sprint, based on the average for the last n sprints

Scenario 7: Keep an eye on bottlenecks 
Given
Stanley has access to Jira
When a ticket is stuck in a sprint column (excluding ToDo/Done) for more than the average time for that column for the ticket size
Then send a DM to the scrum master/product owner, informing them the ticket seems to be taking longer than expected and suggesting they check if the person working on it needs help.

It could have two modes, active or passive, to suit different team cultures. In active mode, the bot proactively post messages based on events and so on. In passive mode, the user has to ask the bot for an answer. The above scenarios could be made passive, where a user types in a keyword to ask Stanley to do something — for example, /stanley burndown could result in it posting the burndown chart and /stanley bottlenecks could list the tickets stuck in a particular column for more than average time. Both active and passive modes could co-exist and might make the bot more useful.

I can think of several other scenarios based on best practices, analytics, AI, etc a bot could help a team perform better. I think such a bot could be useful, and with access to data sets from various projects and a bit of AI, it could steal my job one day! I had better polish up that CV.