The Process

Our working process is built around three principles:

  1. Payments are based on closed tasks. We do not use hourly rates nor fixed monthly salaries.
  2. All the project communication must leave a document.
  3. The Project Master is responsible for everything

To be able to follow the principles, we have created automated robots to help the management. The robots opens new tasks, assigns the task to suitable developers and process payments when the task is closed. Also the Project Master role is essential. The Project Master has ultimate power to make decisions related to the project. The great power comes with the great responsibility.

Task based payments

The main difference between Devolution’s development process and status quo development process is how we compensate to our contributors. When we develop a new feature to our software project, we create a design issue. The design issue contains initial explanation of the UX design, required end-to-end test automation cases and sketch for development process. The Project Master starts a micro-task for each “branch” (UX, TA, dev), which are randomly assigned to the contributors who has skills to do the micro-task.

When the contributor gets the micro-task, she creates minimal increment toward the final goal. The feature won’t be ready after the increment, the developer creates “TODO” flags for next steps. The developer gets paid for the minimum increment, once it passes strict quality review and the incriment is merged to the master version control branch.

Robot creates new micro-tasks from the added TODO flags. If Project Master accepts them, the developer who created the flag, gets a small extra payment. The accepted new micro-task gets automatically distributed to developers by software robot. If the task requires some other tasks to be created first, a dependency is created by Project Master at the task acceptance phase or by the developer who notices the dependency.

Contributors can also earn money by creating issues. Issues can be software bugs or unclear documentations. Contributors can also raise issue, if they think that architectural decisions are notSolving the issues are paid like normal feature tasks.

The Project Master ultimately decides, which tasks are accepted and steers the development process. However, the Project Master does not need to know everything. The Project Master can raise question tasks, and contributors can earn by answering the questions.

Project Master also decides suitable payment levels. The payment level should be high enough to attract the contributors but small enough to keep the project in budget. The aim is that, competent developer can earn relatively well with the freedom to choose own working amount, but also that rookie developer may get decent compensation for his contributions. More the task developers can close, the better the payment.

Communication

The Devolution’s development is designed to work 100% remotely. The process is also designed to not depend on individual contributors. Therefore, we want to make sure that all relevant information is available at anytime. We raise issues when the information is not available. The idea is that, if our developer want to work in the middle of the night, she can find all the context information from feature descriptions, project documentations and test cases.

The project documentation and development tool data is also available for customer. The customer should be able to get clear understanding of the current situation from the project documentation but the customer can also raise questions. In the end, the Project Master is responsible for managing the customer communication.

The Project Master

The Project Master role is challenging role. Devolution uses external contributors, but the all Project Masters are Devolution’s own employees. The Project Master’s role reminds of Scrum Framework’s Product Owner role, but the Project Master’s role is also technical and resembles software architect’s role.

The Project Masters of different projects work together. Project Masters review other projects and can give recommendations. However, despite the recommendations, the Project Master has ultimate power over her project. The Project Master has Devolution Project handbook as a guide. The project handbook contains the process implementation recommendations and checklists. The Project Master tailors template project from the handbook to suit for the particular case.