Taking over a project, the SINAPTIA way
Sometimes we are hired to take over a project with different goals in sight: general maintenance, add new features or overhaul them completely. In this post, we'll share our methodology for taking them over, what we do to gain the feel of owning the project, and how we start delivering fast.
The first step in the takeover is the onboarding. We need to understand exactly what the project is about and what is its current state, get a grasp of the business domain. That means doing a walk-through by the client, taking a look at the code base and get to know the infrastructure, little nuances and problems the app is currently facing.
The outcome of this first look at the application, the code and the infrastructure is usually another list of issues we want to fix to keep the application healthy.
Roadmap and Project Management
Once the onbarding stage is completed we should have a list of issues we need tackle. The first step in this phase will be prioritizing and organizing the issues in epics. Once we have the prioritized epics, we can start building a roadmap that will serve as a guide for the whole project. This roadmap should have a balance between technical tasks that we discovered during the onboarding and features and changes that you have in mind or your business needs.
Next, it's time to assemble the team, define the methodology of work, and refine and write tickets. Basically, everything we need in order to start working.
As for the team, the composition varies from project to project, and it depends on several aspects: the complexity, the duration, the needs and the budget. Experience has taught us that our ideal team for taking over a project consists of a fullstack developer, a frontend developer (or 2 fullstack developers), a project manager and a QA engineer.
As for the methodology of work, we use a mix of Agile techniques and tools, mostly taken from scrum and Kanban. This means we split the work in cycles, we have daily status update, cycle planning, refinement sessions, and demos. But we try keep bureaucracy to the bare minimum.
One thing to note is that it's extremely important for us that you become part of the team. This is for 2 main reasons:
- you are the one who has the vision of the product and a clear perspective of how the business works. Experience has taught us that is crucial for a successful project to be constantly aligning the work with the business objectives.
- transparency and visibility. By working side by side with the whole team, you will know how things are progressing and how we are solving issues. Communication is key.
So we will invite you to every meeting in the development process.
Once the Roadmap and Project Management are in place, the team and the workflow has been set up, development begins. The progress of the project will be gaining pace as the developers start to get familiar with the application and the business logic.
It's fundamental to have fluid, constant communication specially during the very first cycles. This will let us solve doubts and blockers as quickly and directly as possible.
The ultimate goal is to guarantee a smooth and effective ownership and understanding of the application.
Taking over a project is challenging, from a technical perspective but also from the business perspective. We learned that if you have effective and constant communication, if you are methodical and tidy from the technology side of things, the take over is usually a success.
Over the years, we've worked on several projects that have a few years in production and we are still working with them and built long-lasting, healthy relationships with their owners. If this rings any bell, stay tuned as there will be more articles coming over related to working with mature code bases