2

Here is the scenario:

  • I have a mobile app that should be developed for Android/iOS/Windows.
  • The app has similar features but with different design per OS.
  • It also needs backend/web development as well to provide some APIs.
  • Those APIs are almost identical.

What is the best practice here to form the team using Scrum platform?

  1. Should I make separated projects for each of the backend APIs, iOS, Android and Windows apps and make them work on parallel?
    • If so, how to manage the dependencies per app and the backend?
    • Should the backend guy attend the daily scrum meetings for the iOS, Android and Windows apps as well?
  2. Or I make them one project and with the aim that each feature takes the same time to be developed in the sprint on each OS?
Improve this question

3 Answers 3

Reset to default
6

Scrum framework asks for:

  1. Cross functional team which can self-organize itself
  2. Building the product after breaking the required system in vertical slices

So in your case, a cross functional team will have to include developers from different platforms and also testers. Vertical slices of the system will consist of all the sub-parts of a feature from the frontend, backend api, database etc.

This way the team can self-organize the work, for example, if the sprint goal is to allow the user to login and view the dashboard then the team will decide that login API is required, what will be its input/output and in which format (json, xml, etc.), frontend developers can provide their suggestions about the API usage/requirement and everyone knows the progress and impediments. Otherwise everyone will be working in their silos following their own plan/schedule which is highly discouraged by Scrum. Once a vertical slice is completed (end-to-end) then the team focuses on another vertical slice to build and so on. There could be some slack where individual team members have some spare time, which is fine, as Scrum focuses on work optimization and not 100% utilization.

Improve this answer
2

My recommendations would be the same for regardless of the frameworks involved (Scrum, waterfall, hybrid, etc.) - break it up.

  • As you say, several parts of the work can happen independently but they need to be coordinate at the API level.
  • So, have the architect/big-picture/astronaut types get together at the start of project and have them start to work on the API specs.
  • The backend teams and the individual app teams can probably get started right after the first draft is published
  • The API team needs to meet, discuss, and publish changes in the API regularly as the project moves forward because their functional specifications will guide the other teams.

You can call this something like "build the framework first", I suppose, but I always imagine it as building a contract between different groups. For example, "per my spec, the back-end groups agrees that when I ask for DataXYZ type data, I get it in UTF-8 format with date time stamps of YYYYMMDD in GMT time and ..." and the reverse "When I submit a new DataXYZ, it will be in UTF-8..." This allows things to mesh later. Defining these kinds of things up front saves rework.

However, is should not all be defined up-front. Defining these contracts between groups should happen iteratively and have regular revisions. You may not get the results you want if you held up the whole project waiting for a massively detailed specification.

This is based of two of my regular influences: Painless Functional Specifications by Joel Spolsky and the book Business @ the Speed of Stupid. In fact, one of the case studies in the book closely matches your situation. Unfortunately, I can't find much in the PMBoK or other guides that would backup my approach. It has worked for me, though.

Improve this answer
2

Whenever I have multiple teams with concurrent development that need to release synchronously, I leverage the Scaled Agile Framework (http://scaledagileframework.com) model.

  1. Your program level team is your API team
  2. iOS and Android teams are feature teams

Utlizes same framework as other Agile practices with more emphasis on roadmap and architectural considerations.

Check out Dean Leffingwell's book on this topic.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.