Summary

We have discovered that the dialer team could use some improvements in the areas of organization and planning. In the past, we have mostly worked ad-hoc, with little planning besides a very relaxed sprint planning session.

Please contribute to this as much as you feel/want! We can't fix this problem without you.

Good/Problem Areas

Good Areas

• Wasting very little time in meetings
• Very nimble and able to switch gears to get things done when needed
• Anthony is very vocal about UX and is a great liaison for us there

Problem Areas

• Not anticipating problems
• No clear vision for future
• Not enough planning, documentation, updates
• Little accountability when things go wrong, not much formal retrospective or discussion about processes
• Not capable of effectively expanding to include more team members

Interviews

I (Doug) spoke with people on other teams and got some useful information about what they're doing and what's working well for them. I really wanted to talk with Julien, but unfortunately he's on PTO.

Contacts

In general, the contacts team is in the middle-ground between the dialer and messages teams. It seems that Francisco always has a pretty good idea of what everyone is doing and is able to organize things in his head without as much on-paper planning as Julien uses. This seems to work well for them, and they're experimenting with new approaches.

Everyone in the contacts team is in Europe, so they don't have as many scheduling conflicts for meetings and random chats.

Francisco (Lead)

• Daily meetings
  • This is the time to say "I have problems here" and have others help you
  • Takes less than 10 minutes
  • Helpful to know what everyone else is doing (sometimes there's overlap between work and useful tidbits)
• Starting to do estimations
  • Being relaxed on it
  • Leave some free time for important things that come up during the sprint
  • Commit to at least a specific minimum amount of work done
  • It's very motivating to look at a list of bugs and watch them fall
• Wiki articles
  • Helpful for going into the comms meeting (though this will be phased out)
  • List of global things before meet
• Planning (not just sprint)
  • Try to have long-term projects going on on the side
  • Ask people what is not working in contacts (not just retrospective)
    • Example question, "if you were going to rebuild contacts from scratch, what would you improve?"
    • Have a list of tasks to get to one of these
  • Spend time designing, ask other people about architecture decisions
    • Do prototypes, there will be unexpected problems in any big projects
  • Likes this middle-ground of planning
• People organization
  • People should focus on one task
  • Have some people working on blockers, and others workers on future things, have them rotate
• Awareness of big problems
  • Current big problems: performance (DataStore?), design (Haidification)
  • Try to make time to have people work towards these
• UX relations
  • Lets UX do their job, isn't very picky about UX decisions
  • Easier to chat with people in person about UX, liked being able to talk with Vicky when at Telefonica, but still not perfect
  • Was unhappy about VR work that happened without him there (I may have misunderstood what he meant here, so please don't judge him :))
  • Would like to have Vicky on IRC or otherwise quick to contact (Skype, Vidyo, etc)
• Random useful insights
  • "Work is not just about working, it’s also about letting other people know what you’re doing"
  • Planners look at the last time a blocker was updated
• Comms meeting
  • They take turns taking notes and going to the comms meeting to present them
• Takeaways and suggestions for the dialer team
  • Consider having our meeting later in the day (we already do this for sprint planning)
  • Work on integrating Tamara into the team
  • Identify big things that we can be working on to move dialer forward instead of just reacting

Michal

• Daily meetings
  • This is a good to get help from other people
  • They have their own IRC channel, #fxos-contacts
  • 15 minute meeting every half hour before the comms meeting
  • Every day there's someone missing, wishes everyone would attend
• Wiki articles
  • History of daily standups, who worked on what, when
  • Videos with demos of what we achieved
  • Don’t need to attend the comms standup
  • Favorite part of this process
  • Makes him feel better and being able to track his progress
• UX relations
  • Not really any relations with UX
    • Mostly Bugzilla comments, patches that need ux-review
    • Contacts refactoring is rebuilding the app from scratch, will change things

Messages

The messages team is very tightly scheduled and has many, more formal, processes to make sure that things get done. The messages team has 2 people in Europe and 1 in Taiwan, so there are significant scheduling difficulties.

Julien (Lead)

on PTO :(

Oleg

Useful links: https://etherpad.mozilla.org/sms-retrospective https://wiki.mozilla.org/Gaia/SMS/Scrum/3 https://wiki.mozilla.org/Gaia/SMS/Scrum https://etherpad.mozilla.org/sms-standup https://etherpad.mozilla.org/messages-datastore https://etherpad.mozilla.org/sms-haida

• Daily meetings
  • Done async over Etherpad: https://etherpad.mozilla.org/sms-standup
  • Doesn't think there's significant overhead to this (takes him about 10 minutes each day)
  • Likes Etherpad format
  • Mention updates in daily standup
• Estimations
  • Velocity of 8 points
  • Sometimes only assigned 1 bug with point value of 1
  • They only estimate bugs that take 1 day or more (lowest point value is 1 point which is 2 days, should be adjusted in the next sprints to be more precise)
• Wiki articles
  • Great way to get summaries
• Sprint planning
  • Every 2 weeks, same day as comms planning
  • They do retrospective first: https://etherpad.mozilla.org/sms-retrospective
  • 2 hours, too much, trying to improve
  • Done over IRC
  • Will try it over Etherpad, as IRC doesn't work well
  • Vidyo more efficient, but hard to schedule
• People
  • Everyone works on whatever
  • Doesn't like specialization on blockers, even just in terms of temporary time specialization
  • One time they tried specialization and it worked well, but he doesn't think it should happen all the time
• Awareness of big problems
  • DataStore, Haidification
  • Split into small bugs that are manageable
  • Not breaking down big bugs was not working
• UX relations
  • Mostly needinfos for UX
  • Would like to have Vicky on IRC
  • Problems with UX organization in general, mockups problems, not much discussion
  • Painful use of time, hard to get good responses
  • Really didn't like visual refresh bugs
• Action items that they've decided on and haven't been able to do
  • Estimating for people on other teams is hard and inaccurate, so invite those people to standups
  • Hard to invite people from other teams, they have own commitments
• Comms team meeting
  • People don't care about little things, focus more on high-level
• Takeaways and suggestions for the dialer team
  • Julien has an Etherpad script for making a wiki article from Etherpad

Steve

• Daily meetings
  • Over Etherpad (all work) + IRC (major work/questions)
  • At first started with IRC only, but they found that there was lots of redundancy
  • This system is working well for them
  • If you have some kind of question or need help, this is a good time, don't need to ping as much (instead ask questions in a batch)
• Wiki articles
  • Mostly helpful for managers, not as much for him (and in his opinion other developers)
  • He sometimes sees them used to track progress on previously fixed bugs
  • Used to track how many people working on bugs, for example when people on PTO
  • When asked directly about burndown charts: the point is not for our developers but for management
• Sprint planning
  • Takes too long (1.5 - 2 hrs), needs to be improved
    • Point estimates are currently taking about half of the time
    • Considering do estimation offline in free time
    • Another idea: have people look at bugs on their own, but still do estimates together
  • Retrospect first
• Planning
  • Long way to go here, for example, no metabug for Haida
  • But there are some clear goals about what next steps to take for long-term projects
  • Not much thought goes into planning
  • Some discussion on Etherpads, for example for Haida and DataStore
  • Need to find some more time to have more detailed discussion here
    • Biggest roadblock is too many branches at the same time
• people
  • When told about how contacts team works: likes it and wants to try rotation system
  • Would like to have long-term work
• Awareness of big problems
  • Haida
  • DataStore
• UX relations
  • Very convenient to chat with Jenny because she sits beside him; no problems here
  • Some concerns about visual, hard to discuss
    • Mostly through Bugzilla
    • Would like to chat on Skype/Vidyo/IRC
• Being remote
  • Because there's some overlap between timezones, there's still some time for communication, but not much
  • Tries to get all work that needs communication done during this overlap
• Suggestions for dialer
  • Long-term projects
    • Separate communications into different apps
    • Haida
  • Organization
    • Should break down schedule and planning
    • Start working on the wiki pages

Dialer

Etienne (part-time)

• General
  • Agrees there's a problem within dialer
  • Optimistic about these plans in general and that people are looking into ways to restructure
• Daily meetings
  • Ok with coming to daily meetings, not super enthusiastic though
  • Would like for it to be over IRC
  • Worried when he sees people saying standups help them get unblocked
    • Thinks people should be using needinfos/IRC instead
    • Likes having time to think before responding
    • (drs/note) I mentioned that we'll be getting more people soon and not everyone is as familiar with the dialer as him, and he agreed that there's value for us there
• Vision for his role
  • Work mostly on blockers
  • Likes working on stuff he actually uses
  • Feels a bit like dialer is mostly done
  • Always worked on other stuff, didn't just suddenly decide to move out of dialer
  • There was an idea within the comms team of people rotating around inside the team but it never happened, he liked this idea
  • Was owner once most of the features were already done, module ownership came relatively late
• Estimations (bugs)
  • Bugs take constant time for him (cool!) so he doesn't think they're worth estimating
    • Only takes bugs he can repro locally
    • debug/console.log a bit
    • make a dirty fix, make a test, make a clean fix
• Estimations (features)
  • More valuable to do estimations here than for bugs
  • We don’t have a lot of practice
  • No strong opinion
  • Doesn't believe that feature work can be constant time
  • Would support it if we did it
• Wiki articles
  • management likes having this
  • Not sure how he would use them
  • Workflow is very Bugzilla-driven
  • Would start contributing to dialer docs, has wanted to for a while
• Sprint planning
  • Last one went pretty well
  • Not sure about sprints themselves, planned items are not the majority of his work
  • Likes treating blockers differently, likes the way contacts team is run
• Planning
  • Anthony and Etienne talk about the CSS and how to organize it
  • Not much planning on other things
  • The last year, biggest change was DSDS, rushed last minute
  • No strong opinion on this stuff yet (such as anticipating changes)
  • Now is first time we got the opportunity to fix stuff properly
• Long term project ideas
  • Integration testing
    • If we get better integration testing, refactors will be easier
      • ex: if we had tools, we could cover all of CDMA fairly quickly
    • Mulet (b2g desktop on firefox) inject chrome scripts to mock the telephony api
      • Implement RIL daemon in JS
      • Been discouraged on doing this because emulator coming (but waiting a while)
      • Compromise: stub the ril.js
• People
  • No opinion
  • The way the contacts team is working sounds good
• UX relations
  • Getting better
  • Doesn't need to contact UX a lot for his work
  • Progress-based meetings would be good instead of scheduled
    • In system, they have a meeting with UX designer rob where they go through everything they need to talk about
      • Once every 3 weeks during feature dev, once every week during bug fixing
• Comms meeting
  • Getting worse
  • Wasting time
  • Wants to kill it

Anthony

todo

Tamara

• Is a scrum master!
• It would be helpful to know what other people are doing.
• Being mentored by Gabriele to get started.

Gabriele (part-time)

• Daily meetings
  • Too much to have daily meetings, would get distracted from work
  • Talks directly with people when needed
  • Not a lot of overlap with other people's work
  • Works on specific components of dialer that are very self-contained
• Estimations
  • His bug take a long time to investigate, hard to estimate because of that
• Wiki articles
  • Would like to know more about what others are doing
  • Has specific components within the dialer and doesn't really see how they fit into the greater picture
  • Would like to have wiki articles, but raised that they need to be maintained
• Sprint planning
  • Last sprint planning session was his first
  • Thinks it worked ok, good for finding new bugs to work on
  • Hard to find urgent bugs to work on without this
• Planning
  • Doesn't know where the dialer is going
  • The callscreen took him by surprise, bitrotted some stuff he was working on
• Awareness of big problems
  • Would love to participate in fixing big arch problems, long-term projects
  • Sometimes has time for large refactors, but can't land something or uplift, hard to justify risk
• Long-term projects and problems
  • CDMA
    • Unit tests based on feedback from Taiwan
    • Write a patch and have someone in Taiwan test it
    • It worked fairly well but is a bad way to do development
    • It's well documented now in the Telephony WebIDL file
    • The emulator has extensive support for CDMA
    • Also possilble to do development in the emulator
    • No clue how to run emulator in this way, or with 2 SIMs, or anything like that
      • Vicamo Yang, Edgar Chen, Yoshi Huang can help here
  • WAP Push (unrelated to dialer but still nice to know)
    • Delivers special messages over SMS
    • Normally from carrier
    • Can contain links, configuration messages, full text documents with APN, configuration for data connectivity, etc.
    • Handled by Gecko as system messages
    • Originally were going to go into Messages app
    • Now a separate app, closes itself when messages are processed
    • Apps can't close themselves, so hacks needed to work around this
    • Lots of vendor-specific stuff
    • Sent using special software from vendors called NowSMS, we don't have access to this
    • Race: receive and process a message, then signal to close the app, then receive a message before app closed gets into a weird state
  • USSD/MMI
    • Numbers that start with * or #
    • Network replies with some carrier-specific information
      • ex: how much credit left, or data traffic left, enable/disable voicemail
    • Can be transactions
      • Can get a reply, interact with the reply, etc
      • Very hacky
      • Designed for single-SIM
      • UI uses window.postMessage, makes testing difficult, uses setTimeouts
    • Biggest issues: needs multi-SIM support, needs better testing
    • Special function for sending telephony.sendMMI function
      • Should use normal telephony.dial function
    • Hacks depending on the network
    • Whitelist of codes reimplemented on CDMA (normally for GSM) even though it doesn't really have it (we simulate them)
      • Covered well by unit testing
    • Biggest issues:
      • Needs multi-SIM support
      • Needs better testing
      • Replies can be mixed up
        • 1. You send a message
        • 2. Get an event reply on that connection
        • 3. System message (unrelated) triggered when you get a response
          • Juggling both is not easy
          • What we do: ignore the connection events
          • Only set an event handler for system events
          • In there we try to figure out if it was solicited or not
  • DTMF tones
    • Used by answering machines, for example, to see what number was pressed
    • The keypad code is not very nice
      • More than 50 numbers breaks down our logic for example
      • Swiping fingers over the keypad doesn't work very well
    • When user hits a button, we play the sound for that number and send over network at the same time
      • Sound is very glitchy on first play due to WebAudio blugs
      • Was a certification blocker
      • Plastered with workarounds, 2 separate hacks in keypad, should be as simple as playing a sound

Germán (Telefonica)

• General
  • Agrees mostly with Etienne
  • Agrees we need more organization within dialer app
  • Need to refine the way choose bugs and prioritize what's important and what should be delayed
    • This should be coming from product management, not necessarily our responsibility
  • Has some idea what other people are doing, but not in detail, doesn't want to know very specific details, but would like more information
  • Generally doesn't like being put on the spot
• History (I asked because I didn't know, also helpful for scaling to include more partners)
  • Initially in Telefonica they were trying to do something similar to Mozilla
  • They knew about each other's initiatives, started working together
  • He is basically assigned completely to Firefox OS
• Daily meetings
  • Hard to recall what he did the day before
  • Useful to know what other people are doing
  • Wants to have daily meetings
  • When I mentioned the way messages works with Etherpad+IRC: likes it
  • Would help him get unblocked
• Estimations
  • Hard to make
    • Example: facing Travis issues recently which are hard to take into account
  • Not very useful for the work itself
  • Helpful to at least organize each person’s work
  • Would be in favor of trying
• Wiki articles
  • Completely supports it
  • Wanted to find some up to date information about API, looks at MDN, but it's out of date, so contacts Etienne instead
  • Would read other people's entries, likes that he can choose the time
  • Would participate in editing and maintaining wiki articles if others were as well
• Sprint planning
  • Would like to have more involvement from product management for help with prioritizing
  • They're useful, especially the smaller ones before the main one
  • Also useful for knowing what other people will be doing
  • More support tools for sprint planning, for example at Telefonica use JIRA, which provides more information about what they're doing, better organize the work
    • Bugzilla is good, but more specific tools would be helpful
    • Ex: Anthony was working on Kanban dashboard
    • Would like to see, in realtime, what everyone is working on, if bugs are blocked, more detailed status of bugs
• Planning
  • Dialer has been pretty stable, no real new goals
  • Misses having a roadmap
  • Thinks it's a problem that we don't have these high-level goals
  • From "Long-Term Projects" (so far)
    • Was only aware of "Separate communications apps into different apps."
    • Heard of Carrie’s redesign but not much of the rest
• Challenges working for Telefonica with Mozilla people
  • Very proud to work with Mozilla
  • Trying to inherit many of our ways of doing things
    • Not being too formal like Telefonica is
    • Let people do things instead of telling people exactly what to do; trust them
• People
  • Likes the way the contacts team works
  • Having everyone involved in long-term tasks is good, everyone feels ownership
• UX relations
  • Really good, direct connection with Vicky, Pau, Paco (VD)
  • Most of the Telefonica UX/VD team is in Barcelona
  • Likes our relations with UX
• Suggestions for dialer
  • Tools to manage work, for example trello.com (he uses this himself)

Analysis

Differences Between Teams

Similarities

• People don't find the comms meeting useful and want it to be killed.
• Estimations are generally working well, but are experimental on both other teams.
• Every team wants to know what's working well and what isn't for the other teams (people on both teams asked me).
• People generally like to know what others are working on.
• A short, daily standup has gotten very good feedback for usefulness. Nobody who is currently doing it wants to end it or make serious changes.
• Wiki articles helpful for watching progress and retrospectives. Having them makes managers happy. Mixed reports for engineers.
• Only the people who are geographically in the same spot are happy with the process of working with UX or VD right now. It's not the UX/VD people, it's just the timezone differences and lack of availability on IRC. It would also be nice to be able to chat with them periodically over Vidyo.
• Both other teams are happy to experiment with new techniques to organize themselves and do so regularly.

Moving Forward

Long Term Projects

• Carrie's redesign for sheet navigation.
• General redesign and refactors (a la Haidification).
• Testing CDMA in regions that don't use it, perhaps using the emulator.
• Better support for testing emergency calls without accidentally placing them.
• Moving more towards using HTML template fragments for more realistic testing.
• Clean up keypad and DMTF tones code (blocked partially on platform WebAudio work)
• Clean up USSD/MMI code, add multi-SIM support.
• Improve emulator use and documentation.
• Separate communications apps into different apps.

Potential Action Items

• Make a new #fxos-dialer channel on IRC (done).
• Start having daily meetings. I think we can do this over IRC for a start, but be flexible with it. (done)
• Track planning, progress, and discussions on wiki articles. Clean up general docs on dialer. (in progress)
• Start estimating during sprint planning. (in progress)
• Kill the comms meeting (not really in our scope but it's partly our fault that it still happens).
• Begin setting aside time for long-term projects.
• Establish better relations with UX and VD, get specs all in one spot (in progress).

Ideas

• Do video demos of important new features.
• Be more willing to experiment with things that seem like they create overhead. Be willing to kill them if they're not working.
• Discuss vision for the future of the dialer, including the app itself, the team organization, and how we work.
• Do burndown charts and scrum.