Best Practices for Knowledge Transfer and Software Project Handoff
When choosing to outsource development work to an outside party, many of our clients have valid concerns over knowledge transfer and the handover process. Praxent’s Director of Engineering, Ryan Ostrom, walks through some of our best practices for ensuring a painless project handoff including: Involving internal development teams into decisions, ensuring high code quality, documentation, and the handoff sprint.
Video Transcript
Hi there, I’m Ryan Ostrom, Director of Engineering at Praxent. From time to time, our prospects ask us about the knowledge transfer process. It’s one of the more challenging aspects of the software development process. If not done properly, it can result in your developers not being clear on how to contribute to a given codebase. For you, this might result in missed timelines and expectations, and sunken opportunity costs. Today, we thought we might share a few tips on how we think about a good knowledge transfer process.
Number one, it starts with our ideology. We believe our role is to work ourselves out of a job. What this means is that on day one, we’re bringing your development team into the mix. We want their thoughts and opinions about technical decisions, about architecture and infrastructure, CICD pipelines, automation — we want them to be just as much a part of the process. And, we’re going to involve them at every step along the way. That way, at the end, once we’ve delivered on your objectives and handed over the project to your team, we don’t have a meteoric event of trying to bring up your team to speed on the application. Instead it becomes more of a formality because they were already a part of the process.
Number two, code quality. There’s two frameworks we subscribe to that help inform better code quality. One is the book called Clean Code by Robert C. Martin, affectionately referred to as ‘Uncle Bob’ in the development community. The second is SOLID Principles. Together these two frameworks establish that all of our code should be reusable, composable, and easy to understand. What this means in layman terms is that any reasonable person could look at the code and articulate what the code is attempting to do.
But how do we actually ensure that we’re following these code standards? One of the many things that we do is we implement a PR process, that is, a Pull Request process. When a developer is ready to contribute code to the codebase, they request another developer to take a look. The other developer will do a sanity check to make sure that the code is meeting the standards and point out anything that could be optimized or improved.
The third thing we do is the documentation itself, and there’s two types. The first is application documentation. For each application in your product suite, we create a readme. That readme espouses four things: how to download and configure a codebase locally, how to install and run that codebase locally, how to contribute to that codebase, and how to make deployment changes on that codebase. If we covered just these four things on every application in your product suite, that covers about 80% of the questions that developers have in the first few sprints of any given project.
The second type of documentation we do is architecture documentation. Architecture documentation ties all of your applications together. It shows how these applications talk together: what is your environment strategy? What is your development workflow? What about your CICD pipeline? And where does automation testing fit into the mix? Architecture documentation paints a clearer picture of the holistic setup of your product suite.
The fourth thing we do is the actual product handoff event. This likely is a full sprint dedicated to handoff with your team. We’ll schedule meetings with your team, review the codebase with them, point out gotchas and landmines so that your team is entirely equipped to work within that codebase. In that last sprint, we look to your development team to implement the features. We’re there to support them every step of the way. When your development team is able to deliver those features within that sprint, it’s a very good indication that your team really is empowered and equipped to own that codebase moving forward.
These are just some of the things that we do to ensure a good knowledge transfer process. We’d love to have a conversation with you and your team, and share some more examples where we’ve led highly critical knowledge transfer processes.
[End video transcription]Achieve Greatness During Every Stage of Your Project
When it comes to outsourcing development projects, you need a highly capable team that roots for your internal team, too — empowering them every step of the way. We’re here for you – schedule a call with us today to discuss your development needs.