Engineering Culture

Our engineering culture enables us to create innovative products that people love while ensuring cybersecurity. We seek to push the boundaries of technology to achieve the new and exciting. We automate and continuously integrate to make our products truly great.

Engineering Culture

Engineering Culture values derive from Company culture and Agile Software Development values. We believe they complement each other in the right way and enable us to create innovative products that people love while ensuring cybersecurity. We seek to push the boundaries of technology to achieve the new and exciting. We automate and continuously integrate to make our products great.
In Agile way of working, we value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the things on the left more.
You can find more information about the twelve principles of the Agile Manifesto (written above) here.
In Software Engineering there are two teams: Quality Assurance and Software Development. The Development Department is divided in two teams that need to deliver features every release cycle - Feature OS Team and Apps Team. We use the Scrum Framework for the Apps Team. It is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. The essence of Scrum is a small team of people - Apps Team - Scrum, and their associated roles, events, artifacts, and rules. The team is highly flexible, adaptive, and collaborative.
Our talented engineers are at the cutting edge of driving our business forward with advancing technology. Building great software is as much about behavior as it is about coding. Our engineers are responsible for more than just coding. To create excellence requires a commitment to and ownership of the development processes. By committing to this Engineering Culture, we can perform better and achieve so much more together.

Coding Standards

• We follow the general Android coding style (default for Android Studio which is listed in the Android website)
• We follow the Android Naming convention and naming conventions provided by Java/Kotlin coding standards.
• We format code and file structure using "ctrl + alt + L" everywhere so that the code remains consistent and easy to understand.
• Commit naming – the name must contain the task number, and it should briefly explain the implementation or problem it fixes.

Code Reviews

• At least two other developers must review each commit before it is tested.
• If the scope of the review is too big, we estimate additional time.
• During the code review, all Unit tests should be passing. They are automatically run by Bamboo, and prevent in Bitbucket a pull request to be merged.
• Each review should focus on evaluating code quality. If you are reviewing a fixed bug, the solution should be the simplest one.
• If a bug requires refactoring or a change in design and architecture, it should be planned separately as an improvement.
• If feature implementation is reviewed, the reviewer should make sure he/she knows the implementation logic. Check it covers all the acceptance criteria.
• Code reviews are done at the start of each working day to avoid disrupting other daily activities. Items should spend the minimum possible time in the "In Review" stage.

Architecture

• We aim for scalable, easy to explain and support, design of architecture without implying over-engineering.
• We follow SOLID principles and Clean Architecture patterns. We meet and present the new plan, and if it has any team dependency, the team is asked to join.
• Everyone is welcome to share an opinion regardless of seniority.

Programming Language

• We prefer to use known and proven languages.
• We explore new options but only implement them if the benefit is confirmed and if maturity is high enough.

Testing

• We follow TDD, so each new feature must be tested. Our goal is 100% test coverage of new features so each merge request goes through QA.
• Everyone is responsible for the quality, and this starts from the planning stage, goes through development, and ends up with testing.
• Each team member tests their work before handing it over. This way we can ensure no time is wasted on small defects caused by underlooking a ticket.

Build vs. Buy

• We prefer to build most of our environment and tools.
• Buying sometimes requires a higher investment than just the price of the tool.
• A key concern is our customers' privacy, and we cannot rely on others to protect that.

Security and Data Privacy

• User privacy is a core goal.
• We do not store private information or take information without first requesting it.
• When we need user data, we have to request permission first to the user and bring awareness to him/her of the need behind this request.

Team Culture

• Scrum is an empirical process, "the art of the possible," and places great emphasis on mind-set and cultural shift to achieve business and organizational Agility.

The three pillars of empiricism

1. Transparency - This means presenting the facts as is. All people involved are transparent in their day-to-day dealings with others. They all trust, respect, help each other. They also keep each other informed of good news as well as bad news. Observers should share a common understanding:

• All participants must share a common language referring to the process
• Those performing the work and those inspecting the resulting Increment must share a common definition of "Done."

2. Inspection - Scrum users must frequently inspect the work items and progress toward a Sprint Goal to detect undesirable variances. It is an action required by everyone on the Scrum team, not by an auditor or external party. Inspections are most beneficial when diligently performed by skilled people at the point of work but should not be so frequent that it gets in the way of the work.

Adaptation - Adaptation is about continuous improvement - the ability to adapt based on the results of the inspection. Everyone in the team must ask this question regularly: Are we better off than yesterday? If any member determines aspects of a process and progress deviates outside acceptable limits, the team should adjust their process or work as soon as possible to minimize further deviation.
When the Scrum values commitment, courage, focus, openness, and respect are embodied and lived by the team, then transparency, inspection, and adaptation come to life and build trust for everyone. People becoming proficient in living up to those values leads to a higher personal commitment to achieving the goals of the team. The members have to have the courage to do the right thing and work on tough problems as well as respect each other to be capable, independent people. Everyone focuses on the work of the Sprint and the goals of the team.

Engineering Process and Roles

The Product Owner

Product Owner is a role within Agile teams and in our company, belongs to the Project Management framework. He/she is responsible for maximizing the value of the product, which is a result of the work done by the Development Department. The Product Owner is the sole person responsible for managing the Product Backlog. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren't. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team. Even that Scrum Master is a different role, in our current implementation of the Scrum framework, the Product Owner serves it. In this setup, the Product Owner scope is:

• Ensure arranging the Product Backlog to maximize value.
• Find techniques for effective Product Backlog management.
• Understanding and practicing Agility.
• Ensuring everyone on the team has a context on the product Business goal and scope.
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
• Ensuring the Development Department understands items in the Product Backlog to the level needed.
• He/She is a single entry point for any communication and work that needs to be done by the Development Department.
• Helping the team understand the need for clear and concise Product Backlog items.
• Understand product planning in an empirical environment.
• Facilitate the Scrum events as requested or needed.
• Coaching the Development Department in self-organization and cross-functionality.
• Coach the Development Department in the framework Scrum.
• Help the Development Department to create high-value products.
• Remove impediments to the Development Department's progress.

The Development Department

The Development Department consists of professionals who do the work of delivering a potentially releasable Increment - a portion of "Done" product items at the end of each Sprint. The teams in this department are structured and empowered by the organization to manage their work. The result is optimized overall efficiency and effectiveness.

• They are self-organizing.
• The teams are cross-functional, with all the skills needed to create a product Increment.
• Scrum recognizes no titles nor sub-teams for team members, regardless of the work performed or domains like testing, architecture, operations, or business analysis.
• Accountability and responsibility belong to the Development Department as a whole, despite specialized skills and areas of focus.
• Each team member owns his tickets and tracks their statuses during the whole process and progress as well as corresponding pull requests and branches.
• Each team member must ensure the reviewer and QA have enough information to test the corresponding ticket. It goes both ways; if you do not have context, ask the person to bring it to you.
• Each member is responsible for making sure all the dependencies on his/her ticket are taken care of, and everyone is notified as needed.
• Each team member can request a holiday before the upcoming Sprint, so the capacity of the team is known, there is time to find a replacement when needed and possible, and Sprint Planning can be executed properly without endangering the overall team productivity and efficiency.
• Technical specification documentation is part of development work (Self-documented code or product space's KB in Confluence).
• Functional specification documentation is a user guide made by the QA's (Academy for public features, Confluence for internal/sensitive features).
• Each team member logs the spent time working on a ticket daily.
• Each team member respects and acts with integrity and is not afraid to ask for help from his/her colleagues.

Team Events and Processes

We use the Scrum Framework, and here is a list of our events and meetings. Each Sprint is time-boxed to 2 weeks. Sprint Planning, Daily Scrum, Sprint Review, and Retrospective is mandatory for every member of the team. A team can only have one open Sprint.

Scrum Events

Scrum has five events to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed and have a maximum duration. Once a Sprint begins, its length is fixed and cannot be shortened or lengthened. All other events may end whenever they achieve their purpose, ensuring spending an appropriate amount of time without allowing waste in the process. The five events are :

1. The Sprint
2. Sprint Planning
3. Daily Scrum
4. Sprint Review
5. Sprint Retrospective

The Sprint

The heart of Scrum is a Sprint. It is a time-box of two weeks during which the teams create a "Done," useable, and potentially releasable product Increment. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. During the Sprint, The Development team works on the Sprint Backlog Items. The Sprint Planning marks its beginning. During the Sprint:

• No changes are made that would endanger the Sprint Goal.
• Quality goals do not decrease.
• In case new information comes up and the team learns more under development, the scope may be clarified or renegotiated between the Product Owner and the Development Department.
  

Sprints have to accomplish something. Each Sprint has a goal of what to be built, a design, and a flexible plan that will guide building it, the work, and the resultant product increment.

Sprint Planning

Sprint Planning is when the team plans what and how to perform as work. It needs the collaborative work of the entire Scrum Team. Sprint Planning answers the following:

• What can the team deliver in the Increment, which would be the result of the upcoming Sprint?
• How would the team achieve to deliver the Increment that they plan for the Sprint?

• What can the team complete in this Sprint?
  

The Development Department works to forecast the functionality it can develop during the Sprint. The Product Owner discusses the objective which should achieve and the Product Backlog items. The entire Scrum Team collaborates on understanding the work of the Sprint. The input to this meeting is the Product Backlog, the latest product Increment, the projected capacity of the Development Department during the Sprint, and the past performance of the teams. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Department. Only the Development Department can assess what it can accomplish over the upcoming Sprint. During Sprint Planning, the Scrum Team can also craft a Sprint Goal.

• How will the chosen work get done?
  

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the teams decide how it will build this functionality into a "Done" product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog. Enough work is planned during Sprint Planning for the Development Department to forecast what it believes it can do in the upcoming Sprint. The Development Department self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint. The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. By the end of the Sprint Planning, the Development Department should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

• Sprint Goal

The Sprint Goal is the objective the team can meet within the Sprint through the implementation of the Product Backlog items. It guides the teams on why it is building the Increment and which items would help to reach the goal. As the Development Department works, it keeps the Sprint Goal in mind. To satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Department expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Daily Scrum

The Daily Scrum is a 15-minute time-boxed event for the Development Department. The Daily Scrum happens every day of the Sprint at the same time and place. At it, the Development Department plans work for the next 24 hours. It gives an overview of the progress towards completing the goal and has the intention to optimize the probability of the team to meet the Sprint goal. It has to answer the questions:

• What did I do until this Daily Scrum that helped the teams meet the Sprint Goal?
• What will I do until the next Daily Scrum to help the teams meet the Sprint Goal?
• Do I see any impediment that prevents the teams or me from meeting the Sprint Goal?
  

Daily Scrums improve communications, eliminate other meetings, identify obstacles to development for removal, highlight and promote quick decision-making, and improve the Development Department's level of knowledge. It is a key "inspect and adapt" meeting. The Daily Scrum is an internal meeting for the Development Department, and if others are present, the Scrum Master ensures that they do not disrupt the meeting.

Sprint Review

During the Sprint Review, the Scrum Team and stakeholders collaborate about the work done in the Sprint. Attendees collaborate on the next things that could be done to optimize value. It is an informal meeting, not a status meeting, and the presentation has the intention to elicit feedback and foster collaboration.

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner.
• The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done."
• The Development Department discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.
• The Development Department demonstrates the work that it has "Done" and answers questions about the Increment.
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed).
• The entire group collaborates on what to do next so that the Sprint Review provides valuable input to subsequent Sprint Planning.
• A review of how the marketplace or potential use of the product might have changed is the most useful thing to do next.
  

The Product Backlog may also be adjusted based on the discussion on this meeting to meet new opportunities.

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to act on during the next Sprint. The purpose of the Sprint Retrospective is to:

• Inspect how the last Sprint went with regards to people, relationships, processes, and tools.
• Identify and order the major items that went well and potential improvements.
• Create a plan for implementing improvements to the way the Scrum Team does its work.

During the meeting, every member of the team should answer three questions:

• What did we do well?
• What went wrong?
• What can we improve?
  

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint.

Ongoing Meetings

Product Refinement

Product Backlog refinement is an ongoing process in which the Product Owner and the Development Department collaborates on the details of Product Backlog items. During the meeting, items are reviewed and revised. The Scrum Team decides how and when refinement is held. Refinement usually consumes no more than 10% of the capacity of the Development Department. However, Product Backlog items can be updated at any time by the Product Owner. The goal of the refinement process is to have a clear understanding of every item so it can reasonably be "Done" within the Sprint time-box.

Technical Debt session

A technical Debt session is a process that brings value to product quality. Those meetings happen when needed and requested by the Development Department. Their scope is to discuss technical quality-related topics and create a plan for handling the technical debt. At the end of the session, the team should have a clear idea of what is to be done and how it would happen. The Development Department creates diagrams related to the desired solution or if the scope needs further investigation and time - the Product Owner creates a ticket for needed diagrams and documentation for the plan. The ticket has a responsible person and prioritization to enter in development ASAP.

Problem Review and Retrospective

This meeting happens after we have encountered critical obstacles. We see a continuous cycle of repeated mistakes or unproductive behavior. We discuss what happened and list all the events that caused the issue. We make improvement items that we can act on, related to process, communication, and collaboration. It is essential to keep the focus on the main goal: to find better ways for us to work together.
We bring transparency for finalization on items through:

Concepts

Definition of "Done"

Definition of Done guides the Development Department in knowing how many Product Backlog items it can select during a Sprint Planning. Each team creates its own DoD, and then the PO puts it in each Story. As Scrum Teams mature, their "DoD" will expand to include more strict criteria for higher quality. New definitions, as used, may uncover work to be done in previously "Done" increments.

Product Backlog

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. Requirements never stop changing, so a Product Backlog is a living artifact.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Department plans to accomplish during the Sprint, and it belongs solely to the Development Department.