“The company had grown to the point that we didn’t all know each other’s names and roles within the business anymore. New starters were no longer able to absorb information in the way they would at a small business, but were keen to learn about how the company worked, its history and vision for the future, and find out what was happening in other departments. We also felt it was important to give everyone a common vocabulary and understanding of SaaS economics, so they could understand the strategy, why recurring revenue is so important and the benefits of Agile software development”.

Our induction involves each department sharing their vision or process, illustrating how they add value to the business as a whole, and divulging some important nuggets of information to those who are new to the business. It is a great opportunity to engage with the people outside of their own departments and learn more about what they do and why.

As part of DevOps, we encourage people to learn by doing rather than listening, and have come up with a unique way to engage with the new recruits and instill a sense of meaning in our use of Agile and Lean practices to deliver value to our customers.

The Game

Borrowed from the guys at .Net Objectives, our current game involves pitching our new starters in two teams against each other to deliver features to their customers using different styles of delivery. Over the course of two rounds we measure:

The number of defects

The amount of work In Progress at the end of the round

The number of features accepted by the customer

The time in which the team delivered their first feature to the customer

The team members are each assigned a role in which they work as an isolated workstation. They are discouraged from talking to their peers but encouraged to work hard and optimize the output of their workstation without consideration for the system as a whole. The teams provide their feature using sticky notes and coloured dots. Each workstation has the sole skill of being able to add a particular coloured dot to their sticky in a position described by the customers requirement.

Round 1

The teams have 5 minutes in a race to produce their features using a "Pull" system and a "Push" system. The push system operates in big batches while the pull system limits their work to one feature in progress per workstation.

At the end of the first round we collect the metrics and ask the participants to discuss what they noticed about their process. If all goes well we will clearly see that the pull system delivers their first feature fastest and also dramatically reduces the waste in the system. During the discussion, the team will identify that some team members of the pull system may have more waste in terms of people—workstations idling as they wait for their next item from the proceeding workstation. This illustrates the counter-intuitive nature of making all people 100% productive all of the time, and the assumption that this delivers better results for the delivery.

This round is aimed at illustrating the principles of reducing work in progress to deliver value faster and the resulting waste produced when working in big batches.

Round 2

Both teams are guided to use the same process, but are again pitched against in each other to create some friendly competition. In this round the teams are cross-functional and each workstation has the skills to produce all aspects of the feature. The testing role is encouraged to review each workstation continuously in order to provide feedback to the workstations as quickly as possible.

The importance of this round is how it relates back to our team structures in DevOps. We understand how passing work between teams of specialists creates delays in our ability to deliver features. Each team or workstation the work passes through is placed into a queue and has to be scheduled. By assembling cross-functional teams who have all the skills to take a feature through from its inception through to production and beyond, we are able to deliver small increments of business value fast. After each increment we can re-evaluate what we have done and what needs to be done next, allowing us to change direction if needed and to react to our market and our customers.

As we continue to learn, gain feedback, and adapt, the induction process changes over time. We haven't always had this format. In previous incarnations we have a done straight presentations using Prezi or have used Lego instead of Post-its and coloured dots. What led us to making our session interactive and engaging was our appreciation of learning by having fun. By getting people involved, our induction actively engages the audience and allows them to observe more about what we do, illustrating our principles in a practical way that people can relate to.