Practical tips on how to improve communication in the team of developers

1. Effective Communication within the
Mobile team
Prepared by:
Natalia Klymenko

2. What is communication?
● It is not just “Let’s have a chat”
● It is everyday work in different environments
Slack, JIRA, Bitbucket, Emails, Documentation

3. Daily communication
● Daily Standup
Describe your current work on standup meetings. Consider that some people can
miss Standup or could have bad connection. Repeat on the Slack channel if you
feel it is important
● JIRA Active Sprint Board
Update your current tasks within Active Sprint in JIRA. Also, review other
developers tickets to be aware of what part of code other developers are
currently working on

4. Code Review
● Avoid Huge PRs
For effective code review, PR should not exceed 4-5 screens. If more, open JIRA
Epic and split into smaller tasks
● Link Pull Request to a ticket
PR name should start from
ticket’s number to be correctly
linked to JIRA ticket

5. Code Review
● JIRA tickets description
On the code review stage, update your ticket with all details
● Avoid comment of outdated code
● Code Convention and Formatting
One style through the whole project - tabs, spaces, lines, etc

6. Code Review
● One PR for one ticket ideally
Acceptable to have 3 PRs if we do changes in the library and then in the related
main code
● Respect tickets life cycle
Code Review -> Testing. Do not revert to code review again to add a couple of PR
with additional functionality. It could be acceptable only if a ticket was failed by
QA

7. New features
● Discussion before implementation
A major feature that affects the major part of the app and requires a major QA
testing has to be discussed within the dev team before implementation
● Feature description
A spec or clear description. The responsible developer/an initiator presents the
necessary information so the team can make the right decision
● Prioritization
Tech features should be prioritized in the dev team. User features are discussed
with product owner and dev team before implementation

8. New features
● Publish spec
Notify developers/product team when your spec is ready for discussion in 1-2
weeks before implementation
● Review specs of other team members
If you miss spec and then understand something was wrong after the feature has
been implemented, reimplementing will cost the company time and $$$

9. JIRA Ticket
● JIRA tickets description
Ticket should contain detailed and clear description, a link to the documentation
and specifications, steps to reproduce, testing areas/affected areas, a crash
report of production
● Epic for big features
Big features should come with Epic and be split into several tickets
Do we need Epic or Ticket?
Code volume -> PR up to 4-5 screens -> Tickets -> Epic

10. Sharing code
● Avoid merge conflicts in the code
Should be a rare situation. Merge conflicts can happen during code redesign,
significant changes related to new library implementation. If you know that
somebody else is doing some feature in this file and you are going to do some
redesign in this file, try to communicate with a developer to align the date of
committing
● Communication in PRs
Try to communicate with other developers with which you can have common
code. Include people to PR reviewers for monitoring if you are not sure which
part of code they are working on

11. Responsibility and Delegation
● Team Roles
Define responsibilities within a team
● Responsibility assistant
Make sure you have an assistant that can help you when you are off/on holidays.
Provide her/him with the necessary information, passwords and docs. So the
company is not going to stuck when you are off. It is a personal responsibility to
find your own assistant

12. Effective Communication
● Visit/Don’t ignore Effective Communication
meetings
● Feedbacks
All your feedbacks are very valuable and can help to
make a great team