The Project Management Perspective is Process-Oriented
Project management is about shepherding process. As such, implementation details such as XP practices or training are (at best) tangential to the role.
However, there are things you can promote at the project level. For example:
- Make on-boarding a defined process.
- Make the development team responsible for designing and implementing the on-boarding process.
- Work with the development team to identify metrics and milestones for on-boarding.
- Agree on a "definition of done" for the completion of the on-boarding process.
- Enable success, but fail early when (not if) on-boarding is occasionally not successful.
Why the Details Don't Matter
Specific implementation details will vary based on project requirements, organizational culture, team composition, and (most important of all) the personalities of those already on the team. That makes prescribing a generic "best practice" almost useless.
From a project perspective, the focus on the entrance and exit criteria for the on-boarding process is what's most important. For example, the project might:
- Want all new developers to be competent to handle routine bug tickets, with deeper mastery of the code base reserved for "down the road" somewhere.
- Want initial on-boarding to be completed in six weeks or less.
- Want some way to know if the on-boarding process was successful or unsuccessful.
- Want a feedback mechanism to inspect-and-adapt the on-boarding process to make it more efficient.
On one project I managed, the on-boarding process included daily pair-programming focused on unit tests, which is often an excellent way for a new programmer to understand the underlying assumptions, assertions, and expectations that an application has. The team considered on-boarding successfully completed when the new hire could turn an uncomplicated SEV-3 ticket into a failing unit test within 48-72 hours.
If your shop doesn't do unit testing, resists pair programming, or has some other metric for deeming on-boarding to be complete, then you will obviously need a different process and a different set of procedures. The people who are best able to identify those processes and procedures are the development team itself, so why not let them do what they do best?
Focus on tracking project performance and the exit criteria for the on-boarding process. Don't try to do the development team's job for them. At the end of the day, integrating a new team member may be a project process, but it's inherently the development team's responsibility.