A Sprint at Life360
At Life360, we are focused on building technology that helps families feel safe and together even when they are outside of the home and apart. Our mission is to become the must-have Family Membership that gives families peace of mind anytime and anywhere. In this article, I would like to give an overview of the process we built (and evolving) and tools we use to accomplish our goal. Though it is my (an Android Software Engineer) perspective, it is roughly the same across the organization.
We follow Scrum and our Sprint is 2 weeks long. Every two weeks, we do Sprint planning and schedule JIRA tickets for the upcoming Sprint from the backlog. We would have done our backlog grooming previous week and pointed our tickets. We look at our velocity last sprint and approximately plan to finish similar points, considering holidays and any time offs.
Team structure
Our teams are cross-functional and built around features, like location, growth, core tech, driving, etc. and typically contain a PO (product owner), UX designer, an engineer or two from each discipline — Android, iOS and Platform (backend) and test engineering. One of the engineers is the team lead who attends Scrum of Scrums that happens every day after individual team stand-ups, which are just 15 min long.
Workflow
The JIRA tickets follow through the work flow depicted below.
We create tickets for research spikes, design, development and unit tests. Ideally, we create a ticket for a user story and subtasks for each discipline to complete the story and whole team works on the story till its done and moves on to the next, but sometimes, we create stories specific to each discipline — we are flexible. Our UX design team makes sure they are ahead of implementation by at least a Sprint. We also have tickets for bugs that are filed. We categorize them P0, P1, P2 and P3, where P0 is highest priority. PO decides which bugs to pull in to the Sprint. We also schedule any pure technical work not related to the feature that should be done — for example, evaluating the impact of a new Android OS version preview on our app.
After the Sprint is planned, the team lead starts the Sprint. The team schedules design sessions based on the need and usually involves a white board session to figure out the design for the feature. If the information is not clear, some one creates a research spike and once the spike is done we get back to the design. We document our designs — create a pull request (Markdown format) for the design or write a Google doc and open up for comments. We have design awards too.
Collaboration
We use GitHub for our version control and code review. Once an engineer has some code to be reviewed, he/she opens a pull request and asks one or two reviewers from the same discipline. We strive to do reviews within 24 hours. We rotate through reviewers so every one is familiar with all parts of the code. We encourage building expertise, so sometimes we request reviews from an expert in the matter. We use labels on pull requests to say its work in progress or if its mergeable or a cherry pick, etc. We also assign milestones to PRs, so its easy to know what changes were made in a particular release.
Automation
Our PRs must pass the checks — unit tests, UI automation tests, release build tests and so on. We use Appium for automated tests for UI and run the UI automation on SauceLabs. We use circle-ci as our continuous integration tool and each PR must pass the checks before it can be merged. Each PR must be approved before it can be merged. The really cool thing about this is that it stops number of P0 and P1 bugs from getting into the codebase. Our pre-commit tests (both unit and automation) regularly find crashes and similar bugs. This enables us to release faster and maintain a high quality app.
We follow trunk based development. Every PR points to the development branch. Hot-fixes and cherry-picks go to production or beta branches. We watch test automation dashboard and make sure its all green all the time.
The Android team uses Android Studio as the IDE. Majority of our code is in Java but we have started using Kotlin. We use RxJava, Dagger for dependency injection, robolectric to write our unit tests. We use stetho to debug network issues. We use library modules to modularize our code and we currently have 20+ modules.
We use Smartling as our translation service provider.
Communication
Most of the team communication happens via Slack. We have all kinds of channels — android, iOS, platform, feature team channels, UX channel, products, test automation channel, announcements, design-reviews, engineering, high-fives, etc.. One channel is interesting to me — life360irl (in real life), where we post any real life situations that made us proud of our work/product. Anyone can create a temporary channel to discuss issues involving three or more people. We also have slack hooks for many things — PR check results, crashlytics, tweets, PR review comments, and so on.
Release trains
We use two week release cycles with alpha, beta and production release trains.
This process is completely automated. We use beta channels supported by AppStore/Play store and found them to be tremendously helpful.
At the end of the Sprint, we cut the beta branch from our development branch, create a beta build and upload to play store and app store — all automatically done by fast-lane scripts.
If your feature missed the deadline to make it to beta, it will go in the next release which is after two weeks. That is why it is important to wrap your work-in-progress with experiments.
Once the beta build is available, whole company does manual regression testing focusing on different features. We also have the best bug filer award each Sprint. All the employees subscribe to the beta program and the builds automatically get updated. Since battery drain is a critical performance metric for us, we run battery tests every sprint and compare with previous release, analyze logs and understand the differences or fix any issues that come up.
Once beta release is stable for a week, we promote it to production.
Deployment and Tracking Performance
We built an experiments system in house and use it to deploy, test, rollout or rollback new features without a new release. This system gives us so much power, we can release new features to selected set of users, for example, only users in US, only new users, only users with Android-Oreo, or only 10% of users, and so on.
Amplitude is our metrics system. We created dash boards with key performance metrics and watch out for any issues or performance of new features or campaigns.
Each team has their own dash board and watch for signals, analyze and act upon.
Appboy is our tool for AB testing which we mainly use to evaluate design options, but also to get feedback from users or let users know about any outages, etc.
On the mobile development side, we found fabric to be an extremely useful tool for crash analytics and developmental metrics. We take crash-free rate seriously and strive to maintain above 99%. Every time we make a beta release, we watch out for any new crashes and address them before the production release. We act on velocity alerts with priority. We also watch Google play console for crashes and ANRs.
HockeyApp is used for internal alpha build deployment that every one in the company uses everyday and report issues as soon as they observe.
The team tests their own tickets during weekly team testing or “bug bash” as we call it. We built an automated web tool to analyze logs and generate battery metrics.
We dogfood our beta builds and file bugs just by shaking the phones or by sending emails.
Review and retrospect
At the end of the Sprint, we have Sprint review where each team presents how they delivered what they promised and any unforeseen issues that have come up. We demo our work to the exec team and product owners. We also communicate the next two week plan and discuss.
The Sprint ends with retrospective where we discuss what went well, what we need to start doing and what we need to stop doing and we keep improving Sprint after Sprint.
Like what we do? Come work with Us!
Life360 is creating the largest membership service for families by developing technology that helps managing family life easier and safer. There is so much more to do as we get there and we’re looking for talented people to join the team: check out our jobs page.
