Best practices for iOS development I've seen is at Grubhub

Given that GRUBHUB is the first technology company I’ve worked at, some of the practices that I’m sharing may be limited. Prior to joining GRUBHUB, I worked at corporate companies where there is usually a split between business and technology practices. They didn’t necessarily align with each other. More often than not, businesses have a bigger say because they control the financial aspects of the company. So I enjoy working in a technology-driven company. This is also my first time experiencing true agile development processes. The following sections describe the team structure and management processes that worked well from my experiences as a developer.

Team Structure

In order for the process to work, everyone has to be on the same page. Stakeholders in our case include developers, product owners, analytics representatives, and QA engineers. Sometimes, the designers are involved on a need basis. At GRUBHUB, we have a strong emphasis on the quality of the product. Therefore, we choose to implement less number of features with higher quality.

Product Management

At GRUBHUB, we work closely with the product owners. Product owners manage the priority of their tickets, which we groom together as a team. The grooming process takes place once a week for 30 minutes and with occasional ad-hoc meetings to groom additional tickets that need to be completed urgently. During the meeting, developers identify any gaps in the requirements and add any unit tests and functional tests into the mix because developers are also responsible for implementing the automation tests, both unit tests and functional tests. Our QA team does more of the exploration manual tests to check the health of the entire application. They have a more holistic view. This is a reason the QA team is involved in the grooming process. They help ensure that the tickets include use cases that need to be automated by the developers. Product owners are responsible for providing sufficient details including acceptance criteria, design mockups, API requests, flows, and test data.

During planning, the leads of the development team will grab the tickets for the sprint based on the prioritized backlog by the product owners and assign them accordingly. At this point, any tickets that are groomed and available for planning will have all the details for the developers to work on. Since our sprint cycles are roughly two weeks, we are all on board to ensure that the tickets have sufficient information to be completed within a short development cycle of one week.

Development Management

No pull requests are created unless unit tests/functional tests are included and passing for the code changes. In order for the development team to achieve this, we have design reviews before work begins, coding style guides, a continuous integration system, and code review processes.

Developers work from their individual branches and are responsible to create temporary builds from their branches to complete any verification before merging into the main branch. Verification includes any visual QA testing from the designers and functional testing from the responsible product owner.

Other additional tasks that developers need to complete include experiment set up on the staging environment. One important key to note is that we have a blocked chunk of time to focus on development without any interruptions. Any meetings are scheduled before 12pm and after 4pm. So anything in between those times are dedicated for development.

Release Management

Our release cycle is every two weeks, so release meetings take place on a daily basis to triage any new defects and check on the status of the release. Folks involved in the meeting include QA team and developer leads. During this time, they also prioritize any critical bugs that need to be resolved. Anything raised that is out of scope including changes that product owners desire, they are put into the backlog for prioritization into future sprints. Minimizing scope creep allows us to release every two weeks.

Our goal is to eventually bring the release cycle down to one week and as we are perfecting the processes above, we will be able to achieve this and publish to the app store more frequently. Our processes are predictable, provide some stability for developers to complete their work, and deliver on time and on schedule.

Where to go from here?

Have you experienced similar best practices in your teams? Are there others that you found valuable in delivering quality.