Ruby on Rails team for a leisure services company

Before we even started working with DiscoveryMap, we had a long chat with Michael to understand the project and the challenges they were facing. We quickly realized that the project was in a bit of a mess: there were no clear processes, no proper documentation, and no clear ownership of the codebase. The team was distributed across different time zones, and communication was not great.

Once we assessed the situation we designed a roadmap.

Infrastructure

One of the reasons why the team had low productivity was that deploying new versions to any environment (testing, staging, or production) was a very complex task.

First, they had several VPS (Virtual Private Server) with different purposes. For example, one of them hosted the production Rails app, another one hosted the staging Rails app, another one hosted the production MySQL server, and so on.

Second, not all developers were able to deploy the application. Those with access must follow an undocumented process to deploy manually.

Lastly, there was an attempt to automate some parts of the infrastructure with Puppet. This was incomplete and was only partially working on production. And again, not everyone had access to deploy using Puppet in production.

As you can imagine, this was a huge problem. So, we proposed to migrate the application to Heroku to:

• simplify the infrastructure management
• simplify the deployment process
• fix the staging/production disparity
• have a working testing environment

Communication

The existing team mainly consisted of freelancers who had limited availability (most of them worked part-time or quarter-time). They were also distributed geographically and in different time zones.

They met only once a week, which, in combination with infrequent communication on Slack, means a lot of wasted time when encountering blockers or needing help understanding a bug or new feature.

Also, it looked like there wasn't enough communication between the team members to sustain the asynchronicity of the distributed team.

For us, good and fluent communication is key to a healthy collaboration. We needed to have clearer and more frequent communication. So we proposed to:

• concentrate the async communication in Slack
• add sync daily standups
• keep the weekly planning

Project management

The team used JIRA for the project management, but there was a lack of organization. There were tickets that no longer made sense, epics for people instead of for grouping related tickets, and there were no sprints. So tracking who's doing what and how long the tasks have been in development or waiting for development was impossible. This was a big problem as it gave everyone the impression that nothing was moving forward.

So, we proposed to:

• use epics for high-level feature specifications
• use tickets for each task inside the epics
• use independent tickets for small tasks or fixes
• plan a couple of weeks' worth of work in sprints

The workflow

The development workflow was also a weak point. The pull requests needed 2 approvals before merging, and often the freelancers would avoid reviewing other freelancers' work. As you might guess, merging a medium-sized ticket could take months.

We proposed a frictionless workflow that would allow the team to move from development to production swiftly and effectively. So we proposed our standard workflow:

• one pull request per ticket
• once a pull request is open, any team member can review it
• once a team member approves it, it can be deployed to stage
• once a team member tests it (we normally include QA analysts in our teams), it can be merged
• once a pull request is merged, it can be deployed to production