Managing a Mobile App Development Team

Editor's Notes

• #3: Verve Mobile is the pioneering leader in location-based mobile advertising. Our customers are national brand advertisers who want to engage consumers on their mobile devices with location-aware, data-driven and highly targeted marketing. We also serve premium publishers across the nation, delivering the platforms and services they need to power and monetize their mobile properties. The Verve “location intelligent” technology platform and the proprietary data it generates are revolutionizing mobile media and advertising. It enables consumer and content brands to reach their desired audiences on the go, out and about, and closer to the buying decision than ever before. Nielsen's March 2013 data release, Verve now reaches 115M unique mobile users in the U.S. The US population is about 315M people. – Nielsen Media Report March 2013
• #5: Traditionally we looked for strong PM skills and knowledge of CMS or web technologies. Technical know-how is helpful, but if you are not truly technical, it is still relatively easy to manage a team. Preferred skillsets on the mobile development side: Strong working knowledge of integration technologies Java, J2ME, Objective C and C# Strong knowledge of design patterns You can’t just facilitate the conversation, you have to lead it
• #7: Take newest features and implement them as they are released (retina, xdpi and hdpi), usually within 15 to 20 days after device functionality is released into the marketplace. Challenges presented by this approach include: Unknown requirements until device product launched (WWDC) Scramble to figure out what we need to do Scramble to figure out how to get it done – and sometimes, it is trial and error. When do you call it a failure and back off? Example: we tried to integrate native Disqus commenting within our apps, and have the comments appear without having to be logged in to the actual app. We often rely on “insider” noise about what is coming down the pike, which is a bit of a challenge in instances where you may be outsourcing and this kind of insight isn’t known. In many instances, the US market leads (ex. Samsung Galaxy III release) so you are having to facilitate the discussion with developers who get the device 2 weeks behind you. iOS devices are uniform because they are controlled by Apple. Windows Phone, which is a smaller part of the marketplace, is also consistent due to Microsoft’s control. Android devices are anyone’s guess and can perform differently from device to device. Your job is to understand a lot of the intricacies of the changes, which is a lot to ask of a lead and help often in clarifying the requirements. Also need to make certain the developers are correct in their thinking (ex. Samsung Galaxy 3 versus 4 pixels /(5-inch display with Full HD resolution). Designers need to be kept in the loop as well, which can be a challenge when they need to not only go for good design, but the myriad of different devices and permutations that can be leveraged. YuMe Pre-roll adds Other constraints: EVOLVING AND INHERENT Evolving constraints, such as bandwidth, coverage and security, currently apply to the mobile technology, but are likely to be addressed and possibly resolved in the near future. On the other hand, inherent constraints such as limited screen real estate, reduced data entry capability (due to a limited keypad for example), memory capacity, processing power and limited power reserve, are permanent, at least relative to desktop environments. We are staying ahead of the infrastructure and operations folks often, or at least in tandem. Managing for this is hard.
• #9: The most complicated environment is created when there are white labels, publisher labels, and various cutting-edge capabilities integrated. Especially in the mobile space. We tend to be agile-dominated, with a release every quarter. We understand we are never finished as we are always keeping up with the marketplace. That means: Daily scrum stand up meetings across 3 mobile development teams We independently allow Android and iOS teams to function, but we share lessons learned between them. We don’t mix platform planning meetings so as not to get “tunnel vision” For a PM, you have to get rid of the traditional thinking of initiating, planning, executing, monitoring and controlling and closing. We never close, and you are doing the other 4 all of the time. Often, we are on the cusp of bleeding edge. For example, at the beginning of the year we implemented the new MRAID standard. Only Google had gone ahead of us. Developers struggled and we had to figure out how to test while we were developing. It is a constant challenge.
• #10: For us, it is not just about mobile delivery, it is about mobile delivery in an advertising world. That means that the more details we get on users, the better our performance.
• #11: How we test and release is vastly different in our mobile world environment. No SRS because you know roughly the feature you want, but not how it will function. The use cases tend to be vague and end user focused. So the steps/process to perform an activity is often unknown. Ex. Disqus. Testing is not a simple push of content or a release into staging… We have to build the app (compile) – we use Jenkins We use TestFlight (for some things) Some things we SIMPLY CANNOT TEST Lack of automation unlike the web world. Lots of pair cording to QA in tandem Lots of guiding of our QA team to determine how to test (developer has to figure out the steps and write them out for the testers) We test as we develop – each day we compile code… if it doesn’ t compile our developers loose their bonus Our testers test every day… bugs are thrown back into the hopper If you wait to submit to store (in beta mode) you loose days Our final (final store test) has to be a UAT-quality test (final sign off by the end user) Testing of white label apps is easier. NBC-apps are harder.
• #12: Key take aways: 1) Increase your own mobile knowledge