Our Process

The software market is exponentially expanding and the pressure to innovate is compelling companies to reduce the time to market and increase their product quality. All of this is happening while having specialized teams for their particular business cases.

On the other hand, new technologies, new approaches, new frameworks emerge to achieve just that, but there is no time for the companies to re-specialize a development team focused on anything other than the business case.

Here are the five major aspects that we consider that need to be dealt with for a software project to be executed successfully.

 

Scope

The scope, the information required to start a project and the features the product would have, needs to meet its stakeholders’ requirements. Making sure the scope is complete is something that is required of every single person on the team, with the content of the scope depending on his own responsibility. Considering the usual team structure and needs, we try to have the following 3 tiers of information:

 

Every 3 months we update:

Business case – The reason the customer would need the product, and how do we intend to benefit from it.

Requirements document – A list of small isolated wants and needs from the customer side of priorities.

Risks analysis –  A list of possible developments of the project during the interval and their solutions.

 

Every 1 month we update:

Specifications – Clear and detailed description of how the software is supposed to look like and function.

Non-functional specifications – A table of clear performance attributes required for the business case to be met

Architecture – A document describing the high-level inner workings of the software.

 

Every 1 week we update and communicate:

Development task list – A list of technical tasks meant to create isolated user-ready features.

Human-readable tests plans – A list of tests required to be done in order to ensure the project is functional.

Bug list – A list of software defects or cases in which the software doesn’t comply with the specification.

 

These 3 tiers of decision, allow us to be as informed as we need on every stage of the project and have the required stability in order to complete the project.

 

Communication

While building software in a team, responsibilities, rules, and processes provide a predictable environment for the people involved in the project. Effective communication, on the other hand, directly supports the effectiveness of the team and we consider it to be a critical point. We consider four types of communication scenarios:

Development – People who work on the project every day and are within the organization define this group, like developers, testers or designers. This group generates the largest amount of internal information. All communication within the development group is supposed to be recorded and clear inside the group. Communication towards management needs, in addition, to be particularly transparent in regards to the correlation of the work amount with the results.

External – Similar with the development group, but not necessarily fully committed to the project, this group might have restricted access to their specialized scope (ex: a third party company creating a plugin)

Management level – A group of people responsible for both the product and the success of the project in general. The focus of this group towards the development groups is supposed to be formal, recorded, clear and complete. Communication towards the executive level needs to be both summarized and comprehensive, often presented as clear reports.

Stakeholder/Executive level – This is usually not our side of the communication, but we do encourage clear communication of strategic decisions towards all the groups.

 

Process

We don’t use a one-fits-all process for all software projects, but we are adepts of agile development. We adapt to the customer’s needs if necessary, but if we have a choice, we use two of the most commonly used approaches in the industry:

Scrum is a project management framework with a focus on transparency, inspection, and adaptation. The process is organized in sprints in which management and team leaders choose a list of development tasks for a relatively short interval of time. After every sprint, estimation quality and implementation speed are evaluated, and after enough iterations, the project and the work involved become more predictable. This is our preferred framework in case the emphasis is on finishing a project that’s reasonably specified and has a somewhat strict timeline.

Kanban is a scheduling system with a focus on the visibility of the team’s maximum capacity per responsibility. This system compels management to better understand priority-to-delivery ratio and make reasonable short-term estimations and decisions. We prefer to use kanban when the nature of the project is not predictable enough to go with scrum.

 

Knowledge distribution

In our company, we do encourage teamwork, transparency and effective communication. We know that specialists in software engineering have many years of uniquely accumulated knowledge. There are no two equals in a team and we see this as an opportunity:

  1. We encourage knowledge sharing about the sessions among ourselves but also with our customers
  2. We keep our team structure flexible, with the best person for the position for every project. A team leader for one project might be a developer for another.

Managing the knowledge imbalance helps us to keep the team’s performance stable, use specialized knowledge effectively and also enhance our team’s knowledge as well as yours.

 

Values

All that being said, as a company and as persons, we surpass the challenges of software development through clarity, discipline, rigor, adaptability, transparency and continuous learning. We’re holding ourselves accountable for our customer’s and partner’s success, and we won’t ever make a compromise in delivering the best we’re capable of.