Taking over a project, the SINAPTIA way

Sometimes we are hired to take over a project with different goals in sight: general maintenance, adding new features, or overhauling 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.

Onboarding

The first step in the takeover is the onboarding. We need to understand exactly what the project is about and what its current state, is to get a grasp of the business domain. That means doing a walk-through by the client, taking a look at the code base, and getting 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 onboarding stage is completed we should have a list of issues we need to 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. Everything we need 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 updates, cycle planning, refinement sessions, and demos. But we try to 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.

Development

Once the Roadmap and Project Management are in place, the team and the workflow have been set up, and 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 especially 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.

Moving forward

Taking over a project is challenging, from a technical perspective but also a 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 takeover 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.