Robots bring business and IT together

Maybe you’ve already read the diary of one of our mBots, if not I encourage you to do so first! So, what was this day all about? How did we come to organise this and what did the participants learn?

Changing teams

As companies decide to adopt a more agile way of working, they also start to form multidisciplinary scrum teams. However, there still is a big challenge. When you work with several disciplines in your scrum team, you are exposed to the risk that you still create mini-handovers. First the business analyst will make the design, the developer(s) will build it, the testers will test it and if you’re lucky the business is happy in the end. Team members tend to keep doing what they’ve always been doing. Nothing really changed! Of course, we cannot realistically expect that the business suddenly starts programming, but it would be great if they know the difficulties that developers cope with. It works the same the other way around. We need to learn from each other and bring our work closer together.

Learning by programming a robot

Last year we already found out that a robot is a great tool to get familiar with ATDD. Since then we’ve traded our Lego Mindstorm robot for a whole family of Makeblock mBots.

Out of the box these mBots can be programmed with a Visual Programming Language called Scratch. Makeblock created its own IDE for this ‘language’ called mBlock. This seems simple, but it turns out that writing complex features still requires good specifications and the same logic that is used in ‘more advanced’ programming languages. It’s easy to get started with, but difficult to master. Perfect for a workshop!

ING Tribe Day

At ING, a group of scrum teams that work in the same domain is called a tribe. Within ING these tribes come together for team building days. During this day they get a company update, but also have participate in some fun and learning activities. The goal is to learn from each other in another environment than the office and so become more connected teams.

Xebia helped to organize this episode for the tribe ‘Advies & Affluent’. We drove 20 mBots out to the Undercurrent in Amsterdam-Noord. There, the biggest workshop we’ve done with the robots took place.

Specify the behavior of the robot

We kicked-off the day with a short introduction on what an mBot is and how you program it. Teams could follow along live with a demo on how to get their robot to move forward. Next, the first assignment was to implement a ‘simple’ user story.

As a robot-owner
I want my robot to follow the path on the course
So it can reach the finish line

This seems simple enough, but when you start thinking about it, what does this really mean? The path can move left and right and has sharp corners and long corners. We explained the basic concepts of Specification by Example to the teams. That means that the team first writes out the acceptance criteria in examples. By doing this, the teams started to ask questions, interact and experiment. Scenarios they found for example were:

Given the robot is traveling on the course
When the robot goes off the course of the left
Then the robot steers to the right

Creating a shared understanding

The developers quickly realised that direction should be a variable, and they needed a speed variable since the speed might need to be different in the corners. They showed the business what they meant and the understanding grew. The business also grasped the concept of loops and statements and could see that changing requirements means that sometimes the code needs to change completely. They reached a shared understanding.

The business weren’t the only ones who were learning. Developers have the tendency to dive in and immediately think about the how while business is concerned with what. The teams that discussed their specifications before starting development delivered quicker in the end. Some developers started programming right away to let the robot follow a line. They created a function that worked for the long corners, but as soon as they hit the sharp turns the robot failed. They didn’t think about this beforehand and needed a lot a rework to fix this. They didn’t finish before the end of the sprint…

Competition

We had a total of 15 teams, 80 people, competing in three sprints. Teams were rated on Specifications, Collaboration and Functionality. All those teams could practise their functionality on test tracks.

At the end of the three sprints, the five teams with the highest rating were left to compete against each other on the main track. The team who was able to complete the track the fastest, while keeping to the requirements, won! This element really pushed the teams and put them in a competitive mode!

What’s next?

Having 15 teams compete against each other, while learning things that can be applied in their daily work felt really great. People had a great time and we were asked multiple times how much the mBots cost and where to buy them. Some teams even continued fixing issues during the drinks at the end of the day. 

This day was hopefully the first workshop of many to come. We now offer this workshop in two different formats with slightly different goals. We have a training where scrum teams work full ATDD style on implementing features for the robot using JavaScript, NodeJS and CucumberJS. And we offer this workshop that scales great to a large amount of teams that allows to business to start programming as well. Just visit our trainings page for more information.

By the way: In January we will re-run our Robot workshop from TestWorksConf at TestBash Netherlands 2017. This is a short version of our ATDD robot training. Hope to see you there!