Redirecting to default login... Development Standards Evolution for KP Mobile Team – Mobility Center of Excellence Team Website

Q3-2019: Standards and best practices for mobile dev teams; article by KP Mobile Principle Engineer, David House.

Development Standards Evolution for KP Mobile Team

The KP Mobile development team consists of 7 different scrum teams distributed in 3 different locations. Having standards and processes for a team of this size is critical to the long term success and quality of the team. This was the fundamental reason we created the Development Playbook, and it has been helping the team quite a bit.

The KP Mobile Playbook provides a rich set of resources that provide guidance for our development team in several key areas: Coding Patterns, Processes, Tools, and Dependencies. There is also a process put in place so that every team member can get involved in making the Playbook a great resource for existing and new team members.

Bookmark the Playbook on Confluence now, and check out this Playbook Overview Video (12:03).

During the summer, however, we wanted to focus even further in a few areas and completely up our game to ensure that the work being done had a consistency in 2 main areas: branch naming and pull request standards.

Branch naming standards

The branching strategy for KP Mobile has been changing in the last 2 years. We have gone from each scrum team having a long lived branch to now we have no long lived branches. One of the primary motivators has been to reduce the complex merging conflicts that the previous strategy would create. Now we have a much easier to understand and simple flow that prevents most of the complex conflicts. In addition, each branch now helps tell the story of the work, just by looking at the branch name. We ask that each developer have their name in the branch, along with the JIRA/QC ticket number and some kind of description. Now at a glance you can get some information about the work just by the name. You can see the full details on this playbook page:

Pull request standards

We also wanted to standardize how developers create & manage pull requests. The pull request represents some completed work by one of the teams and indicates the work is ready for review. This is the most critical part of the development process and is the primary mechanism from the development team to ensure quality. Reviewing pull requests is both a method for ensuring the changes being made to the codebase are correct, but also a place to learn. By standardizing many aspects of pull requests, we can again improve the overall story of the work and reduce the number of back and forth questions that come up during review.

As we put together the standards, GitHub released a new feature for pull requests that we are taking advantage of: the ability to create a Draft pull request. In the past, the teams would have to put some kind of label or message in the title of the pull request such as **DO NOT MERGE**. This is very distracting and many times it wasn’t clear when the pull request could be merged. Now developers can create a pull request as a draft and it will not get all the full review by the platform leads. This gives time for internal review by the smaller team, along with allowing the automated quality checks time to run and pass before requesting a full review. It is also easy to see from the pull request list which ones are in draft, or not. Once the developer thinks the work is ready for full review, it can be taken out of draft and the review requested.

To find out more about these pull request standards, check out the page in the playbook here:

Other team-sourced standards: Titles, templates for comments, and labels

Some other standards we added were to ensure the pull request title was consistent and always contained the JIRA or QC ticket number and a description. In addition, we created a template for both the text of the pull request and templates for different kinds of comments someone might make during the review such as a question or a required fix. We also standardized on what labels to use and the use of the milestone feature in GitHub to indicate which version of the app the code change is for.

All of these standards have reduced common questions and allowed reviewers to focus on the most important aspect of reviewing pull requests. This was a team effort and we received input and help to create the standards from many people on the team. To review all standards maintained by the MCoE, check out the Playbook Process page here:

Thank you

Thank you for reading this article by David. Take a minute to send us advice about this submission or feel free to suggest another topic for the MCoE Newsletter.

Stay up-to-date with mobility industry technical news; access tech news archives here.

Making connections through mobile

For help with developing and designing your POC, or certifying and deploying your mobile app, submit an intake form. We’ll make the connection from our team, products, and services to our partners.

OUR PARTNERS include Business and IT groups such as CDO, CDTS, DEC, IMG, IT Finance, ITSS, HPO, TEDD, TRO, TPMG, and many more. We also collaborate with contractors and vendors, including Lolay, HES, ProKarma, PwC, and TTEC.


  • Mobile App Certification – all mobile apps used by Kaiser Permanente’s members, providers, and workforce must be certified according to the KP Policy owned by the MCoE
  • Mobile DevOps Delivery Pipeline – a Continuous Integration & Continuous Delivery platform for both iOS and Android mobile operating systems
  • Mobile Design Resource Center mDRC – a repository of UI/UX assets, case studies, best practices, standards, design kits, and more
  • Mobile Developer Kit MDK – reusable libraries, for example: KPAuth for Enterprise Authentication
  • Mobile Accessibility Workshop – a hands-on session that applies a mobile perspective to the WCAG 2.1 (Web Content Accessibility Guidelines) standards
  • Mobile Community of Practice – hosted twice monthly, mCOP meetings encourage learning, foster motivation, and opens a wide range of expertise to help with technical challenges to fuel continuous improvement
  • Request a demo or capabilities presentation – email us the details – and an engagement manager will respond within 2 business days

OUR TEAM of mobile app experts include:

  • UI/UX Designers
  • iOS and Android Developers and Principles
  • Build, Release, and Mobile DevOps Engineers
  • Deployment Managers
  • Project, Program, and Portfolio Managers
  • Certified Scrum Masters and Agile / SAFe Consultants

MCoE partnership – Contact us

KAISER PERMANENTE exists to provide high-quality, affordable health care services and to improve the health of our members and the communities we serve.

The MCoE (Mobility Center of Excellence) team exists to deliver complex mobile solutions through enterprise-wide engagements. We design, develop, certify, and deploy mobile apps for KP members, providers, and workforce. Submit an MCoE intake form for access to app services, kits, and advice.

Email to subscribe to our bi-monthly newsletter and ask about our tech-newsletter for developer partner updates.

For more information, visit:

Leave a Reply