Onboarding Trials #4: Trial
Trial
To prevent past issues from occurring again, we’ve decided to better organize and give more structure to the trial work period. Instead of “throwing them into the fire”, we’ve decided to focus on education, training, and preparation of employees through project and interview simulations. Hopefully, this will bring us closer to the goal of making employees ready to take on any project and communicate with teams and clients on a respectable level.
Education
The education of developers isn’t focused on coding itself but covers broader topics such as methodologies used for organizing, tracking, and managing projects and tasks. It’s about explaining the software development process and its aspects, such as implementation, quality control, quality assurance, and deployment steps. Naturally, it also addresses the roles and responsibilities related to the previously mentioned aspects. All of this is done through researching online materials and conducting workshops, lectures, and discussions.
Software Development Methodologies and Life Cycle Models
Since our developers have a number of meetings with a variety of clients, they need to be educated about different methodologies and life cycle models used in software development, whilst comparing their advantages and disadvantages. This includes, but is not limited to Waterfall model, Iterative and Incremental Development, Agile methodology, Lean, SCRUM, and Kanban. We compare the quality of documentation, overview the level of the application, scopes of development, product time of arrival in the cycle, technical debts, etc.
We cover the meanings and structure of User Stories, Backlogs, Acceptance Criteria, Definition of Ready and Definition of Done, Statuses, and Bug Reports. Workshops are organized to help them estimate in story points, plan a Sprint and read reports and hours invested, using tools made for that purpose.
Software Development Aspects
We also educate our employees about different parts of the broad topic that is Software Development. This includes, but is not limited to: Quality Control, Version Control, Code Review, DevOps, Environments, SysAdmin, Quality Assurance, Testing, UI/UX Design and Task Management. The links between these and other aspects are depicted below.
Team Member Roles
Team members with specific roles and responsibilities are assigned to work with specific aspects of the Software Development. These must be explained to the employees so they know what others expect from you and what you should expect from others, as well. We cover the roles and subroles of Manager, QA, Designers, Developers and Infrastructure officers, as well SCRUM-specific roles, as depicted in the picture below.
Project Simulation
After educating the employees (or often during) we want them to use their newly attained knowledge and apply it toon a project. However, they still need to have room for errors and receive feedback in a stress-free and comfortable environment. Otherwise, on an ongoing project, they will still face the dangers of learning on-the-fly and have a hard time overcoming their insecurities. They’ll also have trouble identifying whether what they’ve learned is actually being used, because the project needs might be different and organization of it might be custom-tailored for specific purposes. That’s why we organize a project simulation.
Parts and Goal
With project simulation we involve corporate employees in every aspect of the project from specification analysis to deployment, so that they could gain knowledge and more easily identify what’s missing when they join another project. We create a team of mentors to play their roles, including client roles, organize SCRUM meetings, and explain their own and the participants’ purposes. Then comes the hands-on technical setup of tools, repositories, pipelines, and environments. We also give them any existing code we have and teach them to navigate, debug and analyze it.
The focus is then shifted to communication with the client, giving feedback on work and estimations, analyzing mistakes, fixing them and avoiding their future repetition. We test the features, uncover bugs, roleplay the dissatisfied client, give tips and hints on how to handle conversations, especially regarding wrongly estimated tickets, non-delivered features and non-covered edge cases. While introducing other challenges, like feature paradoxes in specification, unclear, vague and/or urgent requests, we show how to overcome them via communication.
The goal of the simulation is to prepare the employee in the best possible way for any problems that may occur,project, code, communication or client related. We want them to be ready to engage in any project, keeping their anxiety in check. Of course, Mentors and Leads are still available for support and consultation afterwards.
Steps
Project simulation starts with a full analysis of the project’s specification, prewritten by our mentors for employees to read, understand, comment, point to inconsistencies, provide possible solutions and write questions for discussion with managers and mentors. Afterwards, storytelling sessions are organized, in which user stories are written and their acceptance criterias are defined, as well as Definition of Ready and Definition of Done, which can be updated later if needed. Stories are then grouped into epics, which are used to create a roadmap.
This leads to the prioritization of the Backlog and splitting it into Sprint Backlogs, each with a defined Sprint goal to be accomplished in one week (in the beginning). Upcoming Sprint’s Backlog tickets are refined in Sprint Refinement meetings, where subtasks are created for each of them, such as: creating or updating entity structure, implementation, writing unit, integration and end-to-end tests, QA test cases and executing them. Before or during the first Sprint, the local environment is set up with IDEs, editors, SDKs and Git. Then comes the setup of a remote repository and additional environments (dev, test).
Finally, we initialize the project, configure linters, code analysis tools, test runners and reporters to run locally, on command and via pre-commit hooks, and as part of CI build pipeline. The development can then start, according to the style guides, conventions, best practices, principles and patterns, refactoring and optimizing before and after submitting the code changes to a mentors’ review via a merge request. The manual deployment process and CD pipeline are then introduced to employees. Tickets are then tested by QA, and the test results and bugs are reported, after which we focus on code debugging, analysis, and navigation.
Interview Preparation
Before each interview with the client, employees are required to refresh their technical knowledge, usually via education books, tutorials, documentation, and other learning materials, physical or digital. At least a day before, at least one interview simulation is conducted, between the employee and their Lead, in English, focusing on questions from technology, SCRUM, general software development, and previously gathered questions.
At the end of each interview, the employee is required to ask for the client’s feedback. This way, we ask the client to be transparent about the interview directly to the employee, and not just to our company. The feedback reports given to the employee and the company are then compared and analyzed for any discrepancies.
After each interview with the client, the employee is required to document it for future reference by other employees, including personal feedback by the employee, the client’s feedback, questions asked, and the answers provided. This document is then given to the Lead to archive and update with the client’s decision when it becomes available.