What If HR Onboarding Was Agile?

Your company’s new hires step through the front doors on their first day excited and full of optimistic energy. They have been recruited with promises that they are signing on to work in a dynamic, collaborative, and “Agile” work environment – one that enables each employee to do their best work by allowing an employee to engage in whatever way works best for them.

Then – they are “onboarded.” An HR professional leads the new employee into a room, sits them down, and proceeds to download to the employee a heap of information that follows a set script. The new employee scratches their head, thinking, “is THIS the company I signed up to work for? This process is not dynamic or tailored to my needs. It’s a lecture!”

Why do HR departments hire dynamic, creative individuals to work in dynamic and creative ways and then subject them to a static, inflexible onboarding processes? Static, inflexible onboarding processes arose from a management culture that values efficiency at the cost of other possible intangible goals of onboarding like introducing the new employee to the culture and work values of the company in an immersive, practical way; one that echoes the methods used in the rest of an agile firm. If HR isn’t agile, doesn’t that send a signal that the company isn’t actually Agile? HR departments should be just as Agile as the company they serve. Otherwise they do not compliment the Agile shop; they corrupt it. It doesn’t take much to destroy an Agile environment or end an Agile transformation.

How can it look differently using an Agile approach?

To start, if the premise is that the company onboarding new employees is one that aligns with Agile values, principles, and frameworks to design consumer products, then the best definition of a well-onboarded employee is one who is not only conversant in all of the necessary new hire information, but also is somewhat conversant in Agile. If Agile is the presumed mode of interaction, agility should begin within the first minutes a new hire is in the office – on their first day – because this working method is the way the company is organized, from design to engineering, and in every other department. In the first three minutes, even before the new hire can remove her backpack and coat, the same people who would be charged to impart all of the HR specific information would be assembled as a greeting committee. The assembled group of people designated to discuss, share, or process HR items is the cross-functional team that, in Scrum vernacular, is called the Development Team.

The Development Team exists to serve the priorities of the new hire, or in Scrum, the Product Owner. The Product Owner (new hire) determines value: what tasks need to be accomplished, in what order, for the purpose of achieving the goals of the Product Owner as quickly as possible. In other Scrum contexts, the Product Owner normally works with the Client. In this onboarding model, these roles are combined and are assigned to the new hire, who should be led through the decision-making process by a trusted guide.

The Product Owner (new hire’s) trusted guide is there to keep the needs of the new hire as the highest measure of value. In Scrum, this person is called the Scrum Master. The Scrum Master keeps the process from spinning out of control and becoming overly administrative. Because this is a quasi-Scrum introduction to both the company and to Agile, the person in this role needs to deeply understand and embody agility. This person would likely have specific items to communicate, and may be a Scrum Master or Product Owner for the company already.

On Day One, the Development Team and the Scrum Master are waiting at the door, ten minutes before the door is unlocked, drinking coffee and chatting. Once the new employee is allowed in, his/her first impression of the company is of a group of people smiling at them, welcoming them into the building. After the initial hellos, this group is quickly moved by the Scrum Master to a nearby room. A wall displays a simple Scrum board featuring a color-coded, but not ordered, mass of sticky notes. What was once a static checklist of HR-related items is now a dynamic, movable set of ideas.

With the Development Team witnessing, the Scrum Master makes a very brief pass at describing what all the artifacts on the wall represent, keeping to an extreme less-is-more strategy when explaining things. Sometimes, too much leadership ruins the organic nature of discovery and innovation.

Because the onboarding process is guided by the new hire’s interests, the Scrum Master asks the new hire, “Which ones would you like to do first?” Because the new employee is likely to be a little thunderstruck by the whole situation and not have a preference for which things get done first (having been in the building now approximately five minutes) the Scrum Master makes a recommendation of an item or two that are in the Scrum Master’s responsibility – a quick primer on Agile perhaps.

The Scrum Master and the new hire then work to order the entire pile of sticky notes (in Scrum, the “backlog”). Precision does not matter. This process usually takes less than five minutes. Once the backlog is organized, the members of the Development Team weigh in on any insights they may have. Perhaps an item at the top of the list and one at the bottom go together, or maybe one has to be done before another. With this discussion, the backlog is then re-ordered to prioritize the preferences of the new hire/Product Owner, while taking into account the realities and special insights known to the Development Team.

The next step is to move the most important items (those at the top of the backlog) into a column labeled “Sprint”. The only items allowed into the Sprint column are those that can be completed THAT DAY.

Filling the Sprint column with backlog items forces the onboarding team to be realistic with respect to which backlog items can actually be accomplished that day and which cannot. For example, Karen from accounting is out of the office starting tomorrow, so her piece needs to be done today. Committing items to the Sprint column also reveals impediments to progress. If Stan from HR is available to go over the dental plan between 2:00 PM and 2:30PM today but there are no tasks in the Sprint column that can be accomplished between 2:30PM and quitting time at 5PM, progress on the backlog comes to a halt. This two-and-a-half hour “loss of productivity” is identified as an impediment by the Scrum Master.

However, this impediment is treated as an opportunity by the Scrum Master, whose job is to be creative about what to do with that balance of time. She might have a ready list of possibilities in her back pocket: is there is a department head that is available to give an introduction to an active project or Development Team? Can the new hire observe a daily standup with a Development Team in engineering?

In a traditional onboarding process, these opportunities would be lost because the process is not typically flexible enough to pivot when faced with obstacles. Through the process of ordering backlog items, opportunities are revealed that might otherwise in a traditional onboarding context have been discovered too late and abandoned as “dead time” or a “break”. Impediments in an agile onboarding scenario can be easily and organically flipped into huge cultural gains. Over the course of a few days, backlog items are moved from the Sprint to the Done column, and the new employee gets to meet new people in an immersive, and very agile way, that can’t be scripted or predicted. Each day is ended with a review of backlog items between the new hire and the Scrum Master. Maybe the order is changed, maybe it stays the same.

Day two begins with the entire Scrum Team (Development Team, Product Owner, and Scrum Master) seated, in a meeting at the same Scrum board. A twenty to thirty minute discussion (retrospective) is held reviewing how yesterday’s Sprint tasks were accomplished – were they done or not done? What could be done better to improve the experience of the new person in the next Sprint, etc.? All completed items are moved to the Done column, impediments are reviewed, then a new Sprint is planned using then next items from the top of the backlog.

What have we accomplished by applying Agile principles to onboarding? First, by allowing the new hire to determine the order in which HR items are communicated, the new employee will begin to feel empowered, listened to, included, and encouraged to be extroverted and entrepreneurial from the first minutes of employment. The new employee will live in the loop of innovation as a player, not as a worker-bee in an impersonal hive.

Compare this agile onboarding process to the traditional HR cohort/classroom methodology, where information is downloaded to the new hire in a fixed order following a script. Is the traditional onboarding process more efficient than the Agile onboarding process? Yes, for whom? Is “efficiency” the most useful objective for the onboarding process? Is an “efficient” onboarding process in keeping with the way of the rest of the company operates? What do we lose when we prioritize efficiency over the need of the new employee to be heard, valued, and empowered as an individual, the need of the HR professionals to be collaborative and innovative, and the need of the company to usher its new employees into its culture as quickly as possible to ensure a smooth transition? When we use an agile onboarding process the quality of communication of benefits and compliance information does not suffer, but when done in an Agile way the process is empathetic to the needs of the new hire and also empathetic to the needs of the people in HR, who are allowed the flexibility to integrate new hire onboarding with other important tasks.

For those reading this that don’t know Agile or Scrum well, the onboarding process described above is pretty much Agile and Scrum. No, it isn’t strictly Scrum. Does that really matter? Because Agile requires agility, it isn’t necessary to be exactly Scrum-perfect at first. What is necessary is to “uncover better ways” of doing everything. By bending the roles of Scrum a bit, we put the person being onboarded in the position of working with the Scrum Master to determine the value of the product being produced. What is the product being produced? It is a fully onboarded new hire (quality determined by the new hire, not by company management, or the HR department). By utilizing the basic tenets of scrum during the onboarding process the new hire can begin to form the reflexes and vision required for when the training wheels come off and they start doing Scrum for real.

Using a Scrum-esque Agile approach to onboarding – before the newbie can even remove her backpack – demonstrates to the new hire that the company values her/his opinion and that the company believes that every employee, even one that has walked into the building on their first day, can help make the company better. Human Resources is positioned to present a company and its benefits as a truly Agile organization should, and it would amplify the spirits of every new employee, validating their decision to join the firm.