Projects with existing codebase

These type of projects are hardest one to handle and many companies fail with it, but we know how to make it a success.

While technically our skills allow us  take any project with existing source code and follow up with its development we are not willing do it. This is because some codebases may have a lot of architectural debt accumulated, which requires a huge effort to deliver any new feature and affects quality. And this is not a level of service what we would like to offer to our customers.

So we would like to be sure that we can resolve existing code issues in a timely & efficient  way. To ensure that new project width the existing codebase can be taken we are always doing a code review to make sure its code matches our minimal quality standards. It’s important for us to check this upfront as we are taking code ownership and responsibility once we accept the project.

Code review document not only answers the question if we are proceeding or not, but also allows to sync development vision and set tasks to mitigate issues present in the code.

In most cases fixed price estimates are not possible  for large portions of work on existing codebase, because precise estimating require full understanding of the business logic implemented in code and clear requirements for the increment of the functionality being developed. Apparently it’s hard to have such knowledge when just starting with the new project.

So we consider  time and material approach to be the most relevant for a such type of projects. As in case with not fully defined requirements we apply Scrum methodology to give our customers confidence in development speed and direction.

Results are delivered in short iterations called sprints. Each sprint takes 1-3 weeks to release. Continuous integration principle as long as commitment to automated testing allows us to deliver fully shippable product increment. Quality improvement and architectural debt payback happens over sprints as well.

For this approach it’s very important to have stakeholders involved into the process as we not only need some initial input, but also a regular review and feedback on results shown. It’s a responsibility of the product owner to maintain prioritized list of requirement in a form of user stories called backlog with a comprehensive help of Forma Pro.

Project development planning is a repeated activity in this case. We schedule a regular meeting that involves a team and a customer to actualize backlog and plan next sprints. Additionally Scrum as a methodology takes care of a business value of an increment released.