How to hand over your project to another software house? A CEO guide.
Handover is a crucial process in the software lifecycle, and it may turn out to be costly and harsh unless you take the appropriate precautionary steps to make it smooth and downtime-free. The following article answer the question how to transfer software development works to another programming team.
The majority of Clients that end up in Merixstudio with the legacy projects either decided to reduce cost by outsourcing the development to Central Europe or were left in shambles being dissatisfied with the current provider. Whichever rationale makes you reach out to another software provider, be aware that the process is always critical for both parties — you, who need to evenly onboard newcomers as well as a new development team, who is about to take responsibility for the legacy code and often rectify the mistakes made by the other programming crew. Then, a solid plan comes in handy — here goes a checklist to help you get prepared for the challenge and facilitate the teams’ transition.
Note: The flow of the project hand-off is often dependent on the project’s scale, complexity and maturity, then, the points below are more of a suggestion than a must-have.
Think twice when selecting the new dedicated developers team
However evident it may sound, make sure that the conclusions of your retrospective assessment of the previous programmers team are translated into the selection criteria of the new one. Building the partnership on trust and transparency pays off. Then sharing openly the lesson learnt from the false start with the previous team may be an incentive to test the new partner against the challenges you have had faced before by listening to their feedback, assessing their know-how and attitude. It can help to understand standards of the software development company and check their expertise. If you need advice on how to do precise research on software houses — feel free to read Michał’s article that explores this topic.
Provide sufficient information and documentation
Without the documentation, even best software developers are forced to analyse the entire source code on their own, which is a time-consuming and sometimes frustrating task. A good set of materials that you provide to the new development team should include:
- Description of the app’s architecture (i.e. particular modules and their correlations),
- Updated README file (i.e. guidelines for system’s configuration and installation, operating instructions, list of files included, troubleshooting, changelog, detected bugs),
- Requirements files (requirements.txt, package.json) that contain the lists of packages to install when setting up the environment,
- Description of key algorithms (e.g. calculating the service price or any algorithms that are unusual) + mechanism of importing data from 3rd party systems,
- Description of key classes and the application’s layers (this simply makes it easier for the new team to find the place that requires changes),
- Description of the database structure (additionally, in case of a relational database, a description of their correlations should also be included; this can be presented on ERP — Entity Relationship Diagram),
- Deployment guidelines (i.e. how to deploy the source code, database and run the project on a new server, any necessary administrator/test customer login credentials).
The handover process is about transferring both a software system as well as the knowledge, experience and responsibilities that are required for managing and maintaining the system during a product’s lifecycle. The new remote dev team should receive comprehensive information about the digital project in order to clearly understand the product itself and its challenges. Such top-down knowledge and perfect understanding is core to the partnership based on consultancy, responsibility and strong motivation. The key areas that should be discussed:
1. General introduction to the product’s idea
Sharing the product’s goals, business model concept, unique product value, strategic knowledge of users (needs, expectations, pain points), core features, user types, product’s context of use, competitive solutions. Here you have a few tools that can be used to share that information efficiently: Business Model Canvas, Value Proposition Canvas, User Persona, Story Map, Development Roadmap (functionalities divided into groups for next releases).
2. Project’s status — “done”, “in progress” vs. “to-do” list
Outlining what work has been done by the predecessor, at what stage on the development roadmap you are now, what work remains on code that has been not deployed yet; what is the upcoming scope of work and next priorities.
3. Challenges
Summarise what challenges have you encountered so far throughout the software development process; what has worked fine and what has not; evaluate with the development team what obstacles can stand in the way of the smooth transition and further development as well as how to prevent them.
4. Operational fit/workflow
Point tools, workflow, management method that you used previously and decide which ones will be used after the team transition; define the roles and responsibilities of the team members-to-be, especially your duties versus the upcoming project manager’s ones. A few key questions to cover:
- Management: What kind of management method should be applied (e.g. Scrum, Scrumban)? When should you agree on Scrum, how long will the Sprint last? What days should Scrum events take place on and who will be involved in them?
- Roles: What are the responsibilities of particular team members (e.g. PO, SM, the rest of the team members)?
- Communication: What tools will we use to handle communication (e.g. Slack, Skype, Hangouts)? How often will we organise the video meetings?
- Workflow: What tools will we use for task management, time tracking etc.? How will the development workflow look like?
Let the new business partner perform a code review
Nobody wants to buy a pig in a poke. This is why one of the must-haves in the software handover process is a code audit which is a prerequisite for measuring technical debt as well as assessing the general health of the application and the new team’s capabilities to handle it. This is a top-down source code analysis that takes place whether there is an app’s documentation or not. It’s natural that long-established code can have some defects. However, the problem arises when their scale and severity is high. This can make implementing new features time-consuming and costly and disable effective code refactoring. And here comes code review that triggers objective feedback, risk evaluation and a rescue plan if needed.
At Merixstudio, we test the web application for its security, performance and code quality, then summarise all the issues including a description of the problem and the remedial actions with its prioritisation to give you a sense of its severity. Some of the questions that are addressed during code audit:
- Is there compliance with the coding standards (e.g. PEP8)?
- What is the unit test code coverage? (Unit test facilitate further development and error detection)
- Is the code secure and breach-resistant?
- Are there any sensitive data stored in the code?
Allow time overlap with the outgoing team
Ideally, the software developers who have been working on the project have a chance to work with the developers who are taking over the project, during the overlap period. Direct information exchange between engineers is short and straight-to-the-point, which leaves a room for facilitating communication and shortening the feedback loop. It should be assumed that a new programming team may initially work with lower velocity as they need to get familiar with the app’s code and architecture. Having two teams overlapped can speed up the onboarding process (by being a support for a new team when specific information is needed), reduce the risk of setback and keep the velocity constant.
Meet the new development team
Simply, there are new people with whom you’re going to closely collaborate probably over a fair period. The chances are that the better rapport you have with them, the greater achievements you can get. Create an opportunity to build a relationship — meet the development team personally, see their office, chill out with them. The human touch can only foster the team spirit and make your cooperation more fun.
As has been shown, the project’s handover embraces numerous processes such as development, testing, deployment, maintenance, project management etc. I hope that this blog post guides you well how to go through all those aspects as smooth as possible. Good luck!
Magdalena PODOLSKA, Business Analyst at Merixstudio
Originally published at www.merixstudio.com.
