When developing the same app for multiple platforms how do you keep the implementation aligned

Question

We have an Android native app and now want to build an iOS native version. We work scrum / kanban process. How best can we ensure that the Features / User Stories implementation on both versions align? We use webservices so they will share that as their common backend which is good.

How do you keep the iOS and Android developers on the same page? What other practices help you ensure that a feature / user story is being implemented the same way on both apps? What are standard practices? e.g. Do you duplicate the post-its for a user story and mark one post-it as android and the other as iOS? or what?

p.s. the android and iOS developers will be different individuals

Answer 1

From a PM point of view it is two separate projects. If the same developers work on both Android and iOS client, you could however run it as one project. You could achieve a reasonable feature alignment, by having two versions of the user stories (iOS / Android) and prioritize them one after the other.

However, if it's two different teams you can't and shouldn't attempt to align functionality development across the two projects. You can of course give the same user story prioritization in the two versions, but don't make dependencies from one project to the other. This will inevitably cause delays in one team, as the same story might vary widely in time required across the two platforms. In this situation you're better off by running it as two different development processes with separate kanban boards etc.

If you do Scrum, you'd run two different Scrum processes simultaneously, and then make a daily or weekly "scrum of scrums" where leads from each team meet and discuss progress.

Answer 2

There shouldn't be any difference in the user stories or acceptance tasks\tests because both are explaining functionality, which will be the same for both apps.

Having said that, it's recommended to create tasks for each platform (even if they are the same)as it will be easier to track the progress for each version because of the following reasons:

1.Time estimation may differ

2.Different Assignee

3.Give each team the flexibility to manage their tasks, maybe iPhone team would like to start working on task #4 then #3 given that they're not dependent on any other tasks of course, but Android team will start working on task #3 then #4.

You can use color coding (e.g. Red post-its for Android, Yellow post-its for iPhone)

Let's take the login screen for an example.

User Story: As a user I want to enter my credentials to view my profile.

Acceptance tests:

• use valid credentials, the user should login to his/her profile.
• use invalid credentials, a message "Wrong user name or password" will appear to the user.
• Click Submit without entering data, a required field message will appear.

Tasks (the post-its)

1. iPhone visual design
2. Android visual design

and so on.

Hope it helps.

Answer 3

In order of your questions..

How do you keep the iOS and Android developers on the same page?

They are building different clients for the same product. I would treat this a single project.

1. This is a scenario where you have to have a bit of union & separation at the same time
2. Both iOS & Android Developers should belong to one scrum team ( Other wise communication gaps are inevitable , they will attend the same scrum ceremonies making communication effective & seamless)
3. This way you will be able to keep both iOS & Android teams on the same page on product vision, expectations on timeline, stakeholder concerns & general communications

What other practices help you ensure that a feature / user story is being implemented the same way on both apps? What are standard practices?

This is what I have done..

1. Development/ QA / Design tasks are separate as these tasks need to be separately executed for each platform, so yes you will have one product backlog but duplicate tasks for each platform
2. Considering implementation of feature A, there will be a post it for Android and another post it for iOS with most probably different estimates
3. In your case different developers will commit to implementation if feature A in iOS and Android so it makes more sense to have different tasks
4. You could also use one burn down chart (Cause as far as product owners are concerned in a given iteration selected backlog items should be released for both iOS and Android together)

So like I pointed above, for all communications related to features, requirements,sprint planing, UI design team members working on both platforms need to come together, as they demand a certain amount of synchronization

During implementation,QA & Release team members working on each platform will have platform specific tasks

Answer 4

In general:

• A well-designed app could be different implementation according with the platform. An example: The iOS app navigate from one screen to another and the back botton is in the navigation bar at the top left. The back botton for Android app is physical button in the bottom on the phone not in the application.
• A well-designed app follows the guidelines proposed by each company (Apple or Google), seeks to provide the best user experience, and try to avoid making things that do not exist on a platform.
• So, the implementation of each of the features / user stories could be different according to each platform.

Scrum:

• You will have two Scrum process in parallel, and you will have all the user story duplicated.
• According to the business rules, each app could have the same amount of Features / User Stories, or not.

Data:

• For applications with persist data, it is possible to use a shared data repository or a webservice to share data models.

Best practices:

• To ensure the behavior for each features between apps (despite of possible differences on how to perform an action depending on the device) you need to have a team of QA and QC, with very clear test cases and agnostic to the platform.
• If after running (manually or automated) all test cases, the results are all valid, you will have 2 applications with the same functionalities and possible different implementations.

Answer 5

please view it as a two different projects because.

The issues that crop up while dealing with creating user interfaces for different mobile phones or smartphones are not merely restricted to the way the designed content appears on the screen. For instance, designing a UI for non-touchscreen phones is very different from that of designing for touchscreen phones. One interface type does not necessarily suit the technical requirements of all devices.

Answer 6

I think multiple people have said that you need to treat it as two separate projects.

I think you need to treat it as a program - a suite of projects managed with similar methodology and with a coherent aim in mind.

How do you keep the two projects aligned? Align the projects. Ensure that:

• The scope statements match
• The KPI match - how you measure performance and effectiveness has to match
• Risks match (or at least every risk is examined to see if it has implications for the other project).
• Change control/Change management are aligned. Any change to either project should be examined to see if it has implications for the other project.
• Final Operational Acceptance testing matches.

Where the two don't match, make sure there is a reason why. If you do your part in setting this up, you'll also clearly identify what part of the work is the core of your project, and what parts are platform specific.

If this is something you're going to do regularly, it may be useful to treat this as three projects

• A project to produce a new product - emphasis on architecture, functionality, etc. Once the architecture and functionality are determined, all the work is outsourced to one of the other two teams, who are treated as subcontractors.

  • A project to implement the product on Android.

  • A project to implement the product on Apple.

Although there is much more overhead in setting it up that way, I think it is possible that in the long run, everyone on the team will understand what they're doing. "I'm developing the architecture for product X". "I'm implementing the product X User Interface on Apple." etc.