Agile Integration: Passing On Culture to Newcomers in 5 Weeks

When a company hires a new collaborator, that person needs some time to get used to the way the company works, and learn what makes the company specific. Most companies call this process onboarding. We believe it's broken.

We believe our most precious material is our humans, their brains, and how they perform together as a team. When a new human joins us, we don't want to just onboard them, we want to integrate them into our team.

At marmelab, instead of an onboarding, we do an agile integration. I will first explain why we think it is so important. Then, we will have a glimpse at how onboarding is commonly done. Once the context is set, we will see how we do it and why, so that you can adapt it to your own needs.

Note: For our french readers, I gave a talk summing up agile integration, which you can watch here.

What's At Stake?

We think that to deliver the most value, we need the people in our team to work in near-perfect harmony as soon as they're on a customer project. And to reach that goal, newcomers need to share our values, methodologies and practices. They need to be part of our culture.

That means that we want them to agree on these values:

• We take risks and we sometimes fail. But we prefer failing to not questioning the status quo.
• We're collectively responsible for the work of each one of us. No siloes.
• Our customers and their end users require attention, and we are at their service
• User-centric design is key to a good user experience
• Shared knowledge makes everyone smarter, and the team superior to the sum of its members.
• There is no one-size-fits-all solution. Our customers challenge us to think outside the box.
• Never stop learning, be curious.

They should also get used to our methodology:

• Agile Rituals
• Systematic peer review
• Quality insurance through a robust and automated test suite
• Code as documentation
• Continuous deployment
• Automation of repetitive tasks
• Metrics-based decision making
• Strong communication based on oral discussions and real dashboards rather than digital tools

And finally, they should quickly master our tools of choice:

• GitHub
• Trello
• Node.js
• React.js
• Docker
• ...

That's a long list, and it's not even exhaustive.

We know that we can't recruit anyone who could check all these items from day one. That's why we look for people we think are able to check most of them, and help them do check the rest within a few weeks of working with us, through the agile integration.

How Is It Commonly Done Elsewhere?

People have worked on onboarding for quite some time now, and even if there are a couple of studies on this subject, most companies use the same methods.

The Big No-noes

What seems to be the most common onboarding way is to get newcomers directly into a real project (consulting firms, I'm pointing at you). The companies with such onboarding practices usually find customers before they recruit new collaborators. As the customer requirement is always urgent, the sooner newcomers arrive, the better, so what's the point of doing an onboarding in that context?

Another much used way is to make newcomers read a huge documentation on their first day. Then they'll know how they're supposed to work, collaborate, do their expenses, ask for days off... The documentation usually seems to be tailor-made to hide the most important things in a huge load of useless information, so that newcomers forget them after a week.

There's also that organization chart that helps newcomers get to know everyone, and they don't even have to meet them. In such companies, newcomers may realise that they're 7 levels down the top, if they're lucky enough to already be on the chart.

Humans Without Collaboration

Some companies figured out that they were recruiting humans and not resources, and tried to get through this.

From what I've seen, the most common way seems to do a company tour on first day. Newcomers get to know who everyone is and how the company works, if they actually remember anything about it the next day. Knowing everyone and talking to them is already a step forward, but they still have no clear idea how they can really work with them.

Another practice is training camps. I've mostly seen it in big companies. They send new recruits to a centralized place where coaches train people so that they have all the skills needed when they come back. It might be very effective on hard skills, but once back to the place they should work at, newcomers don't know anyone, or anything about how it's supposed to work.

Unoptimized Collaboration

Another common onboarding technique is pairing. For instance, for a developer, it means that the newcomer pairs with someone with the same job description. The newcomer sees what they should do day to day, and how they interact with others.

It's a lot better than any of the methods above since newcomers actually live what they're going to do, but in most cases the mentor is the last recruit in the same position. Even if it's still fresh for them, they are the persons who have been here for the least amount of time, and that are the farthest from the company culture. It's a real risk for the culture to vanish.

Also, newcomers only get one point of view, and don't get to collaborate much with everyone else. Their job most likely won't be like this once the real work starts.

Did you already live one of those situation? Did you feel "integrated" as per the definition? Most people don't.

At marmelab, we think onboarding is seriously broken, and that we need to do better.

Defining the Target

To turn a newcomer into our dream colleague, we need to know what a dream colleague looks like. The simplest form to describe that dream colleague is to build a checklist of all the hard and soft skills we need them to have.

We could let our boss do that checklist since it's their company, but would it make sense? Not much, the new recruit should get along with everyone, because they're going to work with everyone. So how do we get everyone involved in building that checklist together? Let's use post-its!

All right, it's quite cliché to use post-its for an agile-inspired methodology, but it's straightforward and you can actually run this kind of workshop at home:

1. Each participant writes all the skills their ideal colleague should have on post-its, using as many post-its they want - we look for exhaustivity at this stage
2. Each participant explains what they wrote and why, and puts their post-its on a whiteboard
3. Collaboratively, move post-its to group assets by themes

I think it's crucial that everyone participates in this workshop, as everyone expects different skills for a new recruit. It helps shape our collective ideal colleague. People usually think about skills they're good at, they're bad at, or about skills that saved them in a past situation. It's very personal, and using collective intelligence here makes the final shape exhaustive - that's what we're looking for.

It may seem quite challenging to scale such a workshop but it's really worth the effort. If you're clueless on how to do so, have a look at liberating structures. I think 1-2-4-All and World Café are particularly good fits for that use.

The most important point is that the team should completely own that checklist, every point on this checklist should be what you want, there is no standard applicable to every culture.

You can still get some inspiration from our list if you need.

Let's Go, Let's Play!

We know where we want to bring our newcomers. In addition, we believe that we learn better by doing and playing. Our entire agile integration revolves around those principles.

On their first day, we make our newcomers play a game. This game will be the subject of their integration period. They're all real world games, and quite tactical. We also like if we can play against one another. example of such games are Dobble, Connect four, Reversi, Awale, Quarto...

We think that having a game as a subject helps to break from past experiences. Besides, it's not something we're going to sell, so it helps value learning over finishing. Also, we love to play - it's part of our culture.

Iterative Integration

Our onboarding methodology is iterative: five weeks, five iterations. Each week, the new recruit receives a different challenge, focusing on a different set of items in our checklist.

Keeping the same subject for the whole period helps saving some time. The new recruit can reuse the result of previous challenges, and they don't need to understand the game domain from scratch every time.

For instance, when I was recruited, I had to work on the Connect Four game. My integration period went as follows:

• Week 1: Implement the game mechanics and make it playable in the console, in Python
• Week 2: Re-implement the game core and interface in a client-server way, in PHP/Symfony
• Week 3: Re-implement the game core and build an AI in Go, deploy it to the cloud
• Week 4: Re-implement the game interface in React Native, publish an Android app
• Week-5: Re-implement the game interface in React Isomorphic, publish it on the web

Implementing the same system in various languages helps discover the idiomatic way to program in each of these languages. For instance, in Python, the program has to use Exceptions, in Go, it must use goroutines, in React, an immutable state, etc. It also helps getting up to speed with each of these technologies, thanks to the mentoring of an expert.

One Iteration In Detail

The agile integration is actually quite experimental. We've tried it at small scale, and have been improving it step by step since. We tried to formalize a process from our practice:

The top part, that we've seen right before, is about defining the target we want to reach. Then each cycle represents a week, and a challenge.

In the center of my drawing, you can see the main actors of the agile integration: the newcomer, a mentor, and a facilitator. Actually, everyone in the company should be involved to make newcomers feel welcomed and wanted aboard. It boosts confidence, and helps make sure they're already part of the group. Being new already is a stressful experience, we have to make sure we avoid adding any impediment.

Crafting the Challenge

All newcomers aim for the same target, but they're all different. That means we can't give them a standard challenge. Each challenge should be tailor-made to help the person improve in the direction we need, based on what they already know.

How do we craft tailor-made challenges? Sometimes by instinct, and sometimes by mapping our checklist to a simple importance/mastery graph. In that graph, we place each of the skills we expect from our newcomers by importance (vertical axis) and by level of attainment (horizontal axis).

Let's say we met our newcomer at a Serious Games event. We know that they already "master" using fun in their job, but it's still very important for us. We map it to the top left part of the graph.

Another example: A customer-centric approach is one of the most important assets for us, it goes to the top part. But imagine a newcomer with no previous experiences in contact with end users. We have no idea whether or not they master that asset, and we'll have to monitor it with a particular care. To the right side!

We shouldn't care much about anything that goes into the red hatched area: these skills are either already acquired, or not that important to us.

Once we've mapped the skills to learn, we know what we want them to learn first. And since we believe people learn better by experimentation, we can imagine a specific challenge for all of the assets we want them to learn.

Failing Fast

We design challenges with great ambition. The backlog that newcomers discover for a 5-days sprint pictures a finished product, not a barely-working proof-of-concept ugly-as-hell it-works-on-my-machine script. Each challenge is hard - even for a seasoned marmelab developer.

Why? Well first because we call it a "challenge" not an "easy exercice you can roast in 2 days". By setting the bar high, we are sure newcomers will try to reach it and learn all the way. It's also because our customer projects are very ambitious, too. We want our newcomers to understand that they need to do the best they can to approach the requirements of our customers.

Finally, marmelab specializes in innovation, which means that we must take risks all the time. And since we take risks, we fail. Routinely. It can be because the technology isn't mature enough (e.g. we used a precursor of React in 2012 and failed), because the customer makes false assumptions about their market size, or because the end users simply don't have the problem our customers think they have (this is the most common reason for failure). Anyway, since we fail, newcomers need to learn to fail, too. It's very hard to learn to fail, but it's fundamental to our job. That's one of the strong goals of the agile integration.

So challenges are too hard to be completed, on purpose. Their only goal is to learn.

Agile Project Management

Each week starts with planning the work that is going to be done during that week. The new recruit discovers a product backlog. The challenge is sliced in user stories. Each of the user stories is very detailled, and contains acceptance tests. It enables the newcomer to focus on their challenge instead of wondering what's the functional scope of their project.

The new recruit asks questions to the product owner, and estimates the complexity of each user story (in days). It's the same process we use during sprint plannings with our customers.

Note: While the first challenge contains user stories that don't allow much lingering doubt, user stories get less and less detailled as the weeks go by. Why? First, because the domain is better known starting the second week. Secondly, because when our customers express their needs, they look a lot more succinct that our scrum-by-the-book user stories of the first week. Customer user stories look more like an idea, the problem of a particular user, and we have to get used to asking the right questions to discover what the user stories are actually about.

After that, the realization takes about 4 days. Every day starts with a daily (stand-up) meetings: the main actors meet to make sure everything goes well. As in Scrum, this is mostly a healthcare check to detect and address the problems as soon as they appear.

Mentoring

During the entire week, the mentor is available all day long to accompany and answer the newcomers questions - or to indicate someone who has the answer. Our mentors actually work on customer projects while mentoring newcomers, but they routinely spend an additional hour every day on coaching - cut into several discussions of a few minutes each throughout the day.

Whatever happens, the mentor should take a particular stand:

• Be kind: Being kind is not as easy as it seems, and mentors really need to mean it. Saying "It's easy!" or "It's just that little thing" is not malveillant on purpose, but it's not kind either.
• Do not give solutions: As the famous saying goes "Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime". Instead of feeding solutions, try to make them ask themselves the right questions. Point the problem, show the road to a solution, that's it. Let them live and learn.
• Make no compromise: Be as intransigeant as you would be for a customers' project. You're not doing them good if you make it easier for the integration and it all becomes harder once working for real. You're not evaluating them on real conditions either.

Every employee at marmelab gets to mentor a newcomer about once per year. Learning how to mentor is hard, but it's also an exhilarating experience, that helps us to be more aligned, more thorough, and more sure about what a marmelab employee should do.

Demonstration

At the end of the week, whether the work is finished or not, it's demo time!

Our newcomer has about half an hour to present their work to the whole company. They should explain what they've done, how, and why they chose a solution over another. We all listen carefully.

The other half hour is left for us to ask all kind of questions.

Why do we do this?

• Communication is a very important value of agility; and presenting in front of everyone is a very good training for the future demonstrations to our customers.
• We know everyone fears speaking in public, this demonstration can allay that fear and help them gain self-confidence
• We believe that teaching is a great way to learn. By presenting to people, you have to get your thoughts in order, to know what you know, and what you don't know. Doing this exercice helps strenghten what you learned, and is essential to make sure all that learning doesn't get forgotten and wasted after a few weeks.

Retrospective

Right after the demonstration, we ask our newcomer to assess their own work so far. We let them do it by themselves to train them to self-criticize. If we built enough trust, newcomers should be confident enough to admit their weaknesses. We believe that seeing your own flaws is the first step to improving; and it's one of our core values.

The retrospective should primarily focus on how our newcomer felt. Because as we deal with humans, the feelings are what are the most important, yet they are very hard to guess.

Then it should focus on what they have learned. They should acknowledge it on their own. Knowing that you know something is a learning by itself. Plus, if you assume you know something in front of everyone, it "forces" you to actually know it.

Since our challenges are tailored for learning, we've never seen anyone not learning anything for a whole week. And with all those new learnings, we ask them if they would do things differently now. Only a few days after they started their challenges, they usually would do a lot of things differently.

We believe that the fact of saying all of this out loud and in front of everyone helps strengthen learnings even more.

Once again, the Demonstration and Retrospective rituals are identical, albeit a bit reduced, to the ones we use in real-life customer projects. We've discovered that the best way to learn Agile is by practice.

Evaluation

A culture is pretty hard to pass on; we believe in experimentation rather than explanation. But for the experimentation to give results, we owe the newcomer a candid appreciation of their work.

We don't blame. We just give advice for improvement.

We should transparently make them know what we want them to progress on so that they know where they still have work to do. How to do so? We can re-use the graph we made earlier and make it evolve week after week.

We move the post-its of the skills where there are improvements to the left of the graph. Most of them should get to the red-hatched area by the end of the challenges. And if there are some remaining and if we're ready to accept it, they become the indicators of where our new team member should improve first.

Learning To Share

As a bonus to the week, we ask newcomers to write a blog post. You can find many examples of such posts in the marmelab blog by selecting the "integration" tag.

The main reason is that by writing down what you learned, where you failed, how you overcame problems, you strengthen even more your learnings. The fact that it has an even broader exposition than the demonstration and retrospective adds the need for even more structure and care. Once again, structuring your thoughts on paper also structures your brain and makes sure you get things right, and for long.

Also, if you're following our blog, you can notice we do write a lot. Writing posts is not an easy exercice, but it is part of our job. That's how we share knowledge between us - by sharing knowledge with the rest of the world. Most marmelab collaborators were not really used to writing in their previous experiences, and the blog posts they write during their agile integration are a kickstart to all the future ones they're going to write.

The Agile Integration Is a Trial Period

To be completely honest, the agile integration is not entirely dedicated to making newcomers improve. We also use it to make sure that newcomers will be a right fit for the team. That's because we're notoriously bad at the interview process. No matter how many interviews we do, with how many different persons, we never know for sure until we actually work with someone. The problem is, some candidates are really good at interviews, but not for the actual work. You can't detect that unless you make them work with you.

Newcomers know that upfront. On their first day, we tell them that we may terminate the integration before the end if we notice that they won't progress on some fundamental skills, or if they don't get along well with the rest of the team. We know it adds pressure, and it may perturbate the learning. But we're clear about it, and our trial period is usually way shorter than in other companies: at the end of the five weeks period, the newcomer is officially part of the team.

On the other hand, if it's not positive, if they don't meet our expectations, we're not scared to tell them it won't work. Throwing away what we invested in their integration period is better than having regrets once the permanent contract is signed.

Break Even?

How much does agile integration cost? We tried to do the maths...

Each challenge requires 5 days of work from the newcomer, and about 1 day from the mentor and the facilitator. There are 5 challenges, which means that the agile integrations costs about 30 man.days. Based a theoritical cost of 350€ per day, that represents a spending of more than 10 000€ per new hiree.

And this is only the raw cost. When newcomers are doing their agile integration, they're not working for our customers. It means it causes an important loss of revenue.

So the agile integrations costs a lot indeed - especially when compared to the other onboarding techniques.

But we believe that if we didn't invest that much, it would cost us much more:

• Newcomers would take longer to ramp up, and we would have to charge less for their work, leading to less revenue
• Our culture would vanish bit by bit without even noticing, leading to employee turnover
• We would hire people with a bad fit, leading to decreased quality of our delivery, and unsatisfied customers
• Our practices would stagnate, and we would slowly get old and finally die

We couldn't say how much we saved by doing the agile integration. We believe it's not just a break even, but that it is actually very profitable for us. It's at the very heart of marmelab.

Conclusion

We've developed this onboarding method by experimentation, and we know it works, in our environment. By sharing the essence of it, we hope you will try it on your own context and provide feedback.

Just like when we're contributing to open source, we would love to see you take part in this. We like to believe it could be the kickstart to fixing onboarding on a broader range.

Please feel free to comment with:

• Your feelings on agile integration
• The bad onboarding methods you went through
• Any improvements you think of
• Your challenge ideas
• Anything you'd like to share