How We Organized Transparency in the App Development Process Share: datarockets Date Published 29 October 2018 Categories Blog, Showcase, Tutorial Reading Time 9-Minute Read In this post, we shared the usual approach that allows us to stay transparent with clients. Our team at datarockets spent years to create an effective management and transparent communication process on projects. After a number of pleasant comments from our clients and realizing that it’s our strength, we decided to share how we organize our work in a blog post. 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 steps of future collaboration. This blog post is going to make such process even easier, as we are going to describe our work style here in details. We work iteratively Iterative approach means that we work in short cycles and are very flexible for changes. The workflow is repeating and general steps in our process are: Planning meetings Implementation (includes code review and testing) Delivery Retrospective meeting. Iterative approach helps us to deliver features right when they are ready, collect feedback from users and analyze metrics to see how our work influences the product growth. Next, we will describe how do we do this. 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 influence the product growth. This data helps to 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. Implementation 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 developers and product owners. We may use Trello, Jira, Asana or Pivotal to visualize Kanban methodology. Our 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. We organize the workflow in 6 columns: “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. “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. “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. “Testing”. We set up staging environments and autodeploy, so as soon as a feature is reviewed and gets merged you can try it out. “Done” column contains tasks that are tested and ready to be delivered to production. “Backlog”. This list contains tasks that are planned to be developed in a product but not included to the current iteration. Every card moves from column to column until it reaches the stage called “Done”. We have described the general workflow. Let’s look at our basic task description. We create cards for every task and name them in user story format. User story format allows a product owner 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. We 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. 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. 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 and we pay a lot of attention to it. Our most important quality is that we are absolutely open as we work with our clients as a single team. 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 our needs. We create different channels inside the workspace: #general, #dev, #product, #standups, #random. Every channel has its own purpose: 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. standups – We use a separate channel for standup reports generated by chatbots, automatic reminders about standup time and standups discussion. random – This 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. We always write results and important points in chats if we have offline discussions or video calls so that everybody is informed about changes. Integrations with other tools We like when it’s possible to monitor changes in all services and see notifications in one place. So we set up integrations between Slack, Trello, GitHub and other tools. Video chat 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 clients and developers benefit from video calls. Clients learn more about us, 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. View this post on Instagram datarockets weekly meetup We work remotely and use Zoom to chat. Four of us have cats 😺. Sometimes cats grab the attention. Happy Birthday @nixololo! A post shared by datarockets (@datarockets) on Dec 19, 2017 at 11:00am PST Delivery 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 We think about how to improve our work that’s why we have weekly retrospectives. During them we discuss the next questions: 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 discuss how effectively we spend our time. 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. 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 us to stay transparent with clients. The key points of the transparent development process are: We plan every week and measure progress to stay effective and not to lose focus. We use Kanban boards for transparent tasks management. We use only public chats and don’t hide anything from clients We initiate video calls to involve all teammates. They build a trusting environment in the team. We automate routine tasks and use robots for code checking. In the end, our CEO left a couple of important quotes for us while Slack is loading. This article was originally published on datarockets’ website, and authored by Yulia Garanok, business development manager at datarockets.