How we created a transparent development process in the team

Developments teams spend years to create an effective management and transparent development process on their projects. At the same time product owners always look for guides like “How to work with developers”. After a number of pleasant comments from our clients and realizing that communication process is our strength, we decided to share how we organize it in a blog post.

transparent development process

The biggest doubts of product owners who want to hire a dedicated team for their project are:

  • the ability to obtain full process control
  • trust
  • response time
  • work quality

To put aside all these doubts we schedule an introduction call where we discuss the next steps of future collaboration.

We work iteratively

Iterative approach means working in short cycles and delivery of new functionality by the end of every iteration. The workflow is repeating and general steps can be:

  1. Planning meetings
  2. Implementation (includes code review and testing)
  3. Delivery
  4. Retrospective meeting.

Iterative approach helps us to deliver features right when they are ready, collect feedback from users and analyze metrics to see how your work influences the product growth. Next, we will describe how to make it transparent.

Planning meetings

Together with clients, we discuss results they want to achieve, problems with current solutions and features that we plan to implement.

At planning meetings, we set up the main goal of the app and features that have to be implemented first. In addition, we discuss metrics that we are going to collect to see how our work influences product growth. This data helps analyze our work and decide what to do next.

If you want to learn more about our approach to startups strategy and metrics we suggest to collect, read our post about building MVP.

planning meeting


We organize our task management process using Kanban boards. The aim of such boards is to make the general workflow and the progress clear to you and your team. You can use Trello, Jira, Asana or Pivotal to visualize the Kanban methodology. The choice depends on the team size or project complexity.

Kanban boards

In general, Kanban boards consist of columns that represent a certain stage in the development process and cards, where every card is a separate task. You can organize it in different ways. We organize the workflow in 6 columns:

  1. “Todo”. Here we put all the tasks that we’ve planned for the current iteration. When we start an iteration, developers take a task they are going to do, assign themselves to the task and move it to the next column.
  2. “In progress”. The card stays in this column the whole time a developer works on it. Every task in this column contains members (people who do it), so it’s easy for a client to see who can answer questions concerning this task.
  3. “Code review”. We use GitHub as a version control system and clear review process. Developers open pull requests, where other teammates can review and comment on the code changes. When the changes are approved, the pull request is merged and automatically delivered to staging.
  4. “Testing”. We set up staging environments and autodeploy, so as soon as a feature is reviewed and gets merged you can try it out.
  5. “Done” column contains tasks that are tested and ready to be delivered to production.
  6. “Backlog”. This list contains tasks that are planned to be developed in a product but not included to the current iteration.
kanban board

Every card moves from column to column until it reaches the stage called “Done”.

We suggest creating cards for every task and naming them in the user story format. User story format allows you to skip writing a long product specification and shows the desired functionality in a couple of sentences. A classic user story format is:

As a < actor >, when <action> then < expected result >

But it can be changed if every side accepts a different format and understands the description clearly.

User story format

It’s a good practice to leave notes and comments under every task. As we don’t require a detailed specification we clarify tasks’ details on planning meetings first and in comments later. There we also discuss ways of solving tasks or problems we face to provide a transparent development process.

proactive discussions

We split tasks into smaller ones if it takes more than 1 day to implement. For hourly progress tracking, we break tasks down with checklists.

tasks splitting

As you see, Kanban boards is a transparent way to monitor real-time progress and discover bottlenecks if there are any.

Daily communication

Working in a team means daily communication so you should pay a lot of attention to it. Create a chat for all your team members including designers and developers. Stay open with your team, take part in discussions in chats and comments, ask questions if something is not clear.

We don’t hide our team. Moreover, we encourage discussions between engineers and clients (product owners). The whole team saves a significant amount of time by having the ability to discuss things with each other without misinterpretations.

Public chats

We use public channels instead of direct messages because direct messages can lead to miscommunication and can leave a client in the dark. It can sound strange for some teams, but we are not afraid of showing problems to clients if we have them (everybody has them :)).

Slack works perfectly for such needs. We suggest creating different channels inside the workspace: #general, #dev, #product, #standups, #random. Every channel can have its own purpose. Look how we organized it:

  • general. We use this channel for greetings, from which you are informed who and when is available. We publish retro results and general inquiries here.
  • dev This channel is created for low-level technical discussions. Clients usually mute notifications from there, but are still able to see all the discussions if they want to.
  • product– Here we discuss high-level requirements like product related questions, strategy, competitors, features and bugs.
  • standupsWe use a separate channel for standup reports generated by chatbots, automatic reminders about standup time and standups discussion.
  • randomThis is a watercooler chat for non-project discussions, memes, and jokes.

The chatbots that we use for standups can be set up for a certain time of the day with special questions. From standups, you can learn how teammates feel and what’s in their focus right now.

standup bot for Slack

Always write results and important points in chats if you have offline discussions or video calls so that everybody is informed about changes. It’s also a good practice to save these notes to return to them later or refer to them.

Integrations with other tools

It’s convenient to monitor changes in all services and see notifications in one place. To do this we set up integrations between Slack, Trello, GitHub and other tools.

Slack and Github integration

Video chats

We work remotely with clients and know how difficult it is to build the trust when you have never met in person. We try to have video calls at least once a week, turn on cameras and show that we are real people 🙂

Both product owners and developers benefit from video calls. Clients learn more about dev team, while developers feel like they are a part of the client’s business. Moreover, face-to-face interaction is more engaging than audio. It helps to build trust and stronger relationships. For such meetings we use Zoom or Skype.


We prefer to automate everything that can be automated. We deliver features frequently as soon as they are ready and don’t spend time on deploying them by hands.

We’ve implemented Continuous Integration (CI) to ensure that the code doesn’t have conflicts. CI runs all necessary tests and checks code automatically. It helps to find errors and bugs and keep the code clean.

By adopting Continuous Delivery and Deployment we are able to release our work to staging and servers automatically. It’s helpful for both developers and clients because they get features faster and see the changes interactively.  

Retrospective meetings

If you always think about how to improve your work, set up weekly retrospectives. Try discussing the next questions on retrospectives:

  • What went well
  • What we need to improve

During these calls, we analyze our previous work by deciding what we will do in the same way and how to fix things we don’t like. We collect feedback from all team members to have a chance to make our work better.

Additionally, we suggest discussing how effectively your team members spend their time. In our team, developers and managers track their time on Toggl. They do it for every task they are working on. Then we send detailed reports to our clients. Basing on Toggl stats we can measure if we use our resources efficiently.

toggl time tracking report
toggl time tracking

We believe, that the honest retro is one of the most important parts of product development.

The key points of the transparent development process

In this post, we shared the usual approach that allows a product development team to stay transparent with clients. The key points of this process are:

  • Plan every week and measure progress to stay effective and not to lose focus.  
  • Use Kanban boards for transparent tasks management.
  • Use only public chats and don’t hide anything from clients
  • Initiate video calls to involve all teammates. They build a trusting environment in the team.
  • utomate routine tasks and use robots for code checking.

In the end, a useful quote from our CEO   🙂

transparent communication