Our process of developing software

“Being Agile it’s all about empowering the developers/designers to do as much as possible, as quickly as possible. It’s about freeing the team from depending on other people - as Product Managers/Clients - to get things done. It’s about managing code, not people. Agile increases speed and responsiveness, and reduces stress.”

The process of developing software is undoubtedly one of the most impactful factors in its quality. You can have a team with the best individual developers and designers, but the product they build will just be crap if they don’t know how to work together.

This is actually very common in junior people - some of them may actually be pretty good on their craft already, but it’s frequent for them to lack experience when it comes to team play. And that makes a big difference.

Through the years, here at Whitesmith we developed our own process. It’s something that’s not definite yet, and actually I don’t think it will ever be, but we achieved a state where we are confident of most of the process due to the positive results it gives.

Our process has been inspired in different companies - namely Thoughtbout, Github, and Etsy - and adapted to our needs, culture, and to the fact of Whitesmith being a remote-first company. Every time we find something we should improve, we do it.

Bellow I give an overview about the several steps in our development process:

Understanding the big picture

When a potential client approaches us with a project, we arranje a call with him - a discussion takes place with the goal of understanding the product as much as we can.

Directly or indirectly, we will be trying to get the answer to questions as:

• What problem is the product trying to solve?
• How does the product solve that problem?
• Who is the target customer?
• How is it different from other products in the same space?
• What does the client stand for? What are his core values?
• What kind of pain points are existing users experiencing?
• What are existing users loving about it?
• In one sentence, how will we know we’ve been successful?

These key questions give us a much better understanding of what we’re trying to achieve, what the product roadmap should be, and very importantly, understand the big picture well enough to suggest different paths and solutions for challenges that come along the way.

We do this because we don’t see ourselves simply as a team that’s focused in following a script - we also participate in the writing, and re-writing, of the story we are part of.

In other words, we really care for the products we’re building. We will discuss and suggest different types of solutions, and if we see that we’re taking the wrong path, we will tell you that. At the end, whatever decision is made, that’s the direction into which we’ll sail together.

Time and cost estimates

Before we start developing a new (or existing) product, we make sure both we and the client have the right expectations in terms of costs and time. We do it in the leanest way possible, by using the good old (but effective) spreadsheet.

The first conversation with the client was key for this. In some cases, we will additionally ask for a page with more details about the project (ex: sitemap).

We break down the the app in the various features, views, and infrastructure components. Each one of these is then estimated in terms of UX, Design, & Development.

Building the roadmap

After having the estimate accepted, we move into building the product’s roadmap. Trello is our best friend in this phase, and both the team and the client will spend a good amount of time using this great tool.

The project has his own Trello board. Here, each card of the board represent a task, and each list represents the card’s status. The team picks news cards to tackle as we go, emulating a Kanban workflow.

Each card should represent an action and consequence from the perspective of a User: “As a [type of user]” + “when I perform action” + “this should happen”.

For example: As a User, when I click on the “Extract” button, I should be able to download the CSV file

As a client, you’ll be able to add new cards to the Inbox list, prioritise cards according to your needs, and clarify any details with the team using the card’s comments section. Cards that are on the Acceptance list are finished and ready to be tested by you. :tada:

Some of the reasons why clients and teams like Trello so much are:

1. The ability to see the status of each feature in almost real-time, and;
2. The ability to communicate between everyone without the need of a middle person (usually the Project Manager). The later is very important because a) it makes communication quicker between the parts, and b) it avoids “lost in translation” situations.

Communicate, Communicate, Communicate

We already mentioned the fact that by using Trello our team is able to communicate with the client to clarify aspects as we go, without the need of any middle man/woman.

But things don’t stop there.

On a weekly basis we have meetings with our clients using Skype or Hangouts. This is where we discuss the next set of features and clarify what needs to be clarified.

The team uses Slack to speak between each other. When we think it’s necessary, an ad-hoc meeting is made, including only the necessary people to discuss the topic at stake - because we don’t want to waste the time of who’s not necessary.

For the case of some projects, during the first weeks the team performs daily standups. In these we speak about: a) what has been done on the previous day, b) what will be done today, and c) which blockers we had. This is done until the team gains the right momentum and understands how the client rolls, taking usually no more than a couple weeks. Depending on the case, the client joins the standup.

Writing code and pushing it to live

Git & Github is at the basis of our code workflow.

Every time we need to create a new feature we create a new branch from master. Then the necessary code is written with a commit correspondent to each change and, when done, a Pull Request is created.

The code under this Pull Request is then reviewed by someone else on the team, which is responsible for analyzing the code quality, guaranteeing that the good practices are being applied, and checking for any evident issue that can arise with it.

For some features we we try to keep a good test coverage, while practicing TDD & BDD - we write tests to guarantee that critical aspects of the application aren’t failing after changes are made.

If things are clear during the Code Review and tests, the Pull Request is merged with master. After this, the code is ready to be deployed to Staging or Production.

Because we are all-in for automation, we also use tools as Heroku Pipelines, Circle CI and/or Wecker to automate the process of running integration tests & deployment.

In a few minutes the code is deployed to Heroku, AWS, or Digital Ocean servers, and ready to be tested by ourselves in Staging. Continuous Deployment in Production is something we activate more carefully, considering the project phase and special needs. But when it does, in a short time a new version is ready to be tested by the users. For the case of Mobile apps we use Fastlane to automate the push of new versions, and CircleCI or Travis for Continuous Integration.

The fact that we release new code frequently, makes us able to deploy significant changes to the data structure and infrastructure bit by bit, testing changes and receiving feedback at a controlled pace. Consequently, there will be fewer bugs in each contribution, and the bugs are much easier to find.

Metrics and alerts

As the icing on top of the cake, we use tools to alert us for application errors and performance issues. These tools are New Relic, Sentry, and Logentries.

They are integrated with the project’s Slack channel for quick acknowledgment of any issue that arises.

Billing

An invoice is sent at the beginning of each month taking into account the number of days or hours that were spent on the project on the previous month.

Different clients, different needs

Our process has some flexibility - according to the type and needs of our client, we may change some aspects.

Some clients are less technical than others. Some clients prefer to lead the team themselves (usually the case for technical clients, as CTOs), while others will prefer that we lead the product development ourselves.

Some clients prefer Bitbucket to Github, and that’s fine. Some prefer Pivotal, and we’ve used in some projects, but we really like the ability of Trello to adapt to changing project needs and process tweaks.

We are open to changes in the process, as long as we believe that they will not have a bad impact. Over the years we’ve experimented different methods and tools, and are always open to try new ones. At the same time, we already have a pretty good idea of what doesn’t work, and will tell you if we believe that’s the case.

The goal of this blog post was to give you a good overview of our process of developing software. I hope it has done its job.

Since this is an overview and not an extensive document, some details were left out on purpose.

Anyhow, if you have any questions about how we work, please let me know. This is a live document, and we will update everytime we find it necessary.