FEBRUARY 1, 2016 // By Sam Flood
It’s happened to anyone who’s managed or worked on a Software Development project: sometime in the middle a project resource leaves or a new member joins and you – the QA Lead – are left with the need to onboard someone. This always feels as though it occurs at a critical project juncture, raising the stakes for you to bring them up to speed as quickly and efficiently as possible, to make them full contributors to the project. This is not an easy thing. Mid-stream, most projects have full-fledged technical structures, mature processes, a well-established set of tools, and a hefty pile of documentation that all have to be learned and internalized before a resource can be truly effective. In some cases – for a highly experienced or senior resource – simply throwing them into this pile of documentation and process may be enough, as they can “swim” rather than “sink”, and be useful contributors. In most cases, though, your new QA resource will need help, and this can become a time-sink for you or your other resources; taking away valuable time that you could be spending elsewhere in improving your project and process quality.
Onboarding doesn’t have to be painful. Over the next couple weeks, we’ll examine ways to effectively organize your information, capture documentation, and onboard both quickly and (almost) painlessly.
Before anything else: get to know your new resource! Whether or not you work for the same company-- or on the same continent—understanding who you’re getting and what existing skillset they have is crucial. If you can, schedule some time and talk. Learn about their career in the industry, the previous tools and processes they’ve worked with, the types of methodologies they’ve used, what their interests are. Understanding and analyzing this skillset will help you immensely as you begin to formally onboard. Everything I’ll discuss over the next two weeks is context dependent—if your resource has existing knowledge and skills that are directly applicable, there’s no need to spend time reviewing what they already know.
Once you’ve analyzed your resource’s skillset, and understood how it applies to your project (and where it might have gaps), onboarding your new resource begins. But where to start? Perhaps the greatest challenge in onboarding a new resource is in simply providing them all the information they’ll need to know, without overwhelming them in data overload or forgetting something critical. Organizing your onboarding strategy is an absolute necessity, especially in a larger-scale project. It’s perhaps most useful to think of any project as breaking down into three key areas, when considering what information needs to be presented, and when to present it.
The Three Keys
Unless your project uses only basic tools that any resource is likely to know, training on the tools your new resource will need is the place to start, as these are typically the steepest learning curve, and the one where people will need the most time. Of course, this is all skillset-dependent, and brings home the need to know your resource’s experience beforehand. If they have spent years using one testing tool, and you’re using that tool as well, they probably don’t need training on it. Keep a list of the tools you use, analyze what your resource needs, and determine which ones you should set up for training.
Once you’ve done this, demo the tool(s) that are new to the resource, and talk about what they do and how your project uses them. Record any sessions you can, as a good recording can be reused for further onboarding later (we’ll talk about recording again in a later section). As much as possible, get your resources access to the tools they’ll need early (even before they’ve officially joined the project), and point them to all of these resources. Focused practice – especially when learning a more technical tool or framework – does make perfect, and the better your resources are at utilizing their tools, the more efficient they’ll be (and the more your team will be able to accomplish).
In the consulting world, every project with every client is different. Some clients are devoted disciples of Agile methodology, while others are just as dedicated to Waterfall. Some clients prefer 2 week sprints, and others prefer 4. Even two clients who are otherwise nearly identical will have some quirks to the way that they prefer to have their processes work: a specific field in their defect-tracking template that needs to be completed, a particular person to whom critical defects need to be triaged. All these differences and quirks fall under the realm of Process, which is the second pillar in effectively onboarding a resource mid-project.
As a QA Lead, helping your project leadership define and refine their processes is a core part of your job. As the project starts and ramps up, you will (hopefully) be involved in the conversations that define how your SDLC will work. As you have these conversations, document; then document some more! You can use whatever tool is your favorite (Visio is mine), but boil every process down into its essence. In this case—unlike tool demonstrations—while recording sessions about process can be useful, don’t lean on those as “process documentation”, as those conversations often meander and make tangents. Instead, after a process has been defined in a discussion, carefully document it, then send it to the project team (encouraging any revisions/suggestions for further improvement). This way, you’ll have an approved document that you can provide as a reference to both your current team, and to any future resources you may onboard.
Speaking from experience: while all this documentation may feel like a lot of up-front time and effort for a minimal gain, it will save you time later. Having a clear document in hand makes onboarding a project mid-stream much easier and faster. This strategy also helps prevent (or at least reduces the likelihood) of general process faults, as it reduces the chances that your newly onboarded resource will forget who a critical defect goes to, or which fields are important to fill out to get the defect caught in your query for triage. As a side bonus, you can (and should) send the finalized document to the whole project team, so that the process is followed by everyone, not just QA.
As you are onboarding your resource into your project processes, it’s also important to provide emphasis relative to the criticality of the process. Some processes – while still useful – are less important than others. The process which ensures a defect gets in front of developers for resolution is probably somewhat more important than the naming convention that you use for those defects, for example. Since a new resource is already trying to learn everything they need to about your project, the more you can stick only the critical pieces in their minds, the less likely they are to make mistakes.
“Domain” is the term I use to refer to project artifacts and context. These are the documents, notes, technical drawings, etc. that define what your project has already done and what it is planning to do. Requirements fall into this category, as to specification documents, wireframes… anything which would tell your new resource what the software does and/or what it will do as your development project continues to build it.
This area is in some ways the easiest to onboard a resource, but in other ways the most difficult (particularly for the resource him or herself). Learning the ins and outs of a technical project – particularly a larger scale one, or one that has been running for many months or years – can be hard!
As a lead, bringing in a new resource, providing a rich domain resource list is the best thing you can do. Give your new resource everything you have. Some possible things to consider:
- Requirements queries (in TFS, Quality Center, or another ALM tool), both of finished work and work still to be done
- UI Design documents (Wireframes, comps)
- Technical schematics (Database diagrams, service layer interaction flowcharts, etc)
- Specification documents
- Functionality demonstrations
- Test Cases
One “domain” area in particular deserves a specific call-out: Tribal Knowledge (also known as “information silos”). If your project is mid-stream—and especially if it’s a larger or lengthy project—chances are there’s a lot of information out there that’s just captured in peoples’ heads. Maybe it’s a particular quirk with the build server, or an oddity in a workflow that was designed for a complex technical reason; but whatever the case, this knowledge isn’t formally documented, it’s just ‘known.’ Handling this kind of information can be frustrating to both a new resource and someone trying to bring a new resource to speed, and it often results in lots of time ‘wasted’ explaining things. Much as it’s important to ‘Document Early and Often’, it’s also important to think about breaking down Tribal Knowledge consciously and making sure it’s documented as well. Work closely with Business Analysts and Project Managers to ensure that these items are all captured in your ALM system(s) so that it all becomes part of the shared “domain” rather than trapped in a few peoples’ heads.
It’s also important to put all this domain information into a shared context. Without a general sense for the project structure and goals, your resource will just be lost if you provide nothing but links and documents. In order to best facilitate this, schedule an overview with them as one of the first things you do. Talk about what the project’s end-goal is, what’s been done so far, what’s still outstanding. Briefly cover the technologies used and their structure (depending on how large + detailed the project is).
Finally, encourage your resource to explore, and give them the time to do it as much as possible. A day spent exploring a SharePoint site can go a long way to helping a new resource understand the intricacies of vendor interactions, technology stacks, etc.
This week, we’ve covered how you can optimize your onboarding strategy to efficiently onboard a resource without leaving critical gaps. Hopefully these Three Keys will be helpful to you in organizing your next resource’s onboarding. Next week, we’ll dive deeper, considering how some simple tips and tricks –starting on day 1 of your project—can make day 278’s onboarding easier.
If you’d like to contact Magenic, email us or call us at 877-277-1044.