View source for Firefox OS/Comms/Dialer/Restructure/Proposal

=Executive Summary=
The dialer team is disorganized and is in reactive mode, not thinking ahead or preparing for the future. We can adapt techniques that the other comms teams are using and come up with new ones to counteract this. In particular, I identified that the other teams are having daily meetings, writing wiki articles, documenting their progress, and doing estimations. At the very minimum, we will adopt all of these. All of these items are already in progress or completed.

We will also begin thinking about and planning long-term projects, and laying out a roadmap for where we want the dialer to be in the future. In particular, we will: listen more to team members for their suggestions and pains, plan our time such that we have enough to work on long-term work and have clear steps for these projects, and incorporate the peer rotation system that the contacts team is doing.

=Sources and Outline=
This proposal is based on my findings in the [[FirefoxOS/Comms/Dialer/Restructure]] article, where I did 30-60 minute interviews with:
*From dialer
**Etienne
**Tamara
**Gabriele
**Germán
*From contacts
**Francisco
**Michal
*From messages
**Steve
**Oleg

I really wanted to talk with Anthony and Julien, but both were on PTO. I think their feedback would have been very valuable, though I think I got enough anyways, and the lack of theirs won't seriously impact us for now.

This is also based on my own decisions for what I think would work best for the dialer team. We should always be open to feedback and be flexible with what we're doing.

=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 Summary=

==Differences Between Teams==
{| class="wikitable"
|-
! Category !! Dialer !! Contacts !! Messages
|-
| ''Tactical Planning'' || None. No daily meetings. || Lots. Daily meetings, own IRC channel, lots of back-and-forth. || Some. Daily meetings done async.
|-
| ''Operational Planning'' || Very little. Mostly during sprint planning and ad-hoc. || Some. Notes taken, wiki articles, light estimation. || Lots. Burndown charts, wiki articles, heavy estimation, full scrum.
|-
| ''Strategic Planning'' || Little/some. Most ideas are discussed between Etienne and Anthony and are rarely shared. || Lots. Discussion with every team member about designs, architecture, and lots of prototypes. There are always side projects going on meant for the long-term. || Some. There are long-term pushes but they are mostly broken down into smaller chunks. *Note: This is tainted by not having talked with Julien yet.
|-
| ''People'' || Ad-hoc. People work on whatever they are generally best at, when they can. Most of the team was part-time until recently. || Rotating pushes. One person may work on a long-term push like Haidification for a week, then go to blockers. Another person may be working entirely on blockers during that time. || Ad-hoc. People work on whatever they are generally best at.
|}

==Similarities Between Contacts and Messages==
* People don't find the comms meeting useful and want it to be killed.
* Estimations are generally working well, but are experimental on both teams.
* Both team wants to know what's working well and what isn't for the other teams (people on both teams asked me to share my notes).
* 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.

==Dialer Team==
* Everyone believes that we need more organization.
* Everyone is optimistic about our future.
* Nobody likes the comms meeting.
* Generally want to do a daily standup, some are lukewarm.
* Want more wiki articles, most have said that they would contribute. This remains to be seen.

=Analysis=

==Dialer Team==
I don't believe that we should necessarily take everything that the other teams are doing and use them verbatim. Our team isn't structured the same way (such as different timezones) and has somewhat different people. In particular, I think it would be helpful to define our identity now and my vision for what it will be.

===Our Identity===
The dialer team is made up of interchangeable and focused members. Each member is best at a given set of tasks and in a pinch, can be assigned to work that they're not necessarily best for. There are a few themes to our team that I have seen:
# Most of us work on a lot of other stuff, or just started.
# We don't like meetings and overhead.
# There's not a lot of overlap in our work (at least due to the way we're currently organized).
# We are much more vocal, and perhaps better trained, when it comes to UX, than the other comms (development) teams.

===My Vision===
I see a team that is well organized while not hoisting too much burden onto any team members, so they're able to get work done but the team can scale to include more developers. We don't know how many people will be joining from partners, so we should prepare for many.

I like our background in UX, and I believe that one of our greatest problems is that, due to our lack of organization, we're not able to make use of these skills. We aren't able to push forward long-term projects which would use this part of us. For this reason, I think that we need to free up time to work on these long-term projects.

==Action Items==
Thinking in terms of my vision, I have identified some action items, which I would like to roll out in phases. I think that changing everything all at once will be too difficult and unmanageable. Having said that, I have already begun or completed some of these.

===Directives===
In general, I think we're all on the same page, and are just being organized incorrectly, so we don't need much change in the way we think. But I do believe that we need to keep in mind the following:

# We should be more willing to experiment and accept that there will be costs and wasted time when we make mistakes, but we will learn from them.
# We should think in terms of being open, which is one of the core tenets of Mozilla. We are not being transparent and open enough with our discussion.
# We should be thinking in terms of the future, and not just dealing with what is set out in front of us. I don't think we're actually too busy to do this; we're just wasting cycles.

===Phases===
<onlyinclude>
✔ = done, ? = in progress, - = not started<br>

====Phase 1 (sprint v2.0-S5 / aka "1" until sprint v2.0-S6)====
* ✔ Make and use a new #fxos-dialer channel on IRC.
* ✔ Start having daily meetings. I think we can do this over IRC for a start, but be flexible with it.
* ✔ Improve cross-team communication and sharing of ideas.
** I've spoken with Francisco who is very interested in sharing ideas and talking about ways to organize ourselves, and I will be talking with Julien soon. I have spoken with the other messaging team members in the interim.
* ✔ Get UX and VD specs all in one place.
* ✔ Track planning, progress, and discussions on wiki articles.
** See https://wiki.mozilla.org/FirefoxOS/Comms/Dialer/Sprint/1
* ✔ Clean up general docs on dialer.
** See https://wiki.mozilla.org/FirefoxOS/Comms/Dialer
* ✔ Catalog long-term projects that we can work on, encourage brainstorming and feedback.
** Since we're still in damage-control mode, I don't believe that it's a good idea to put serious thought into implementation of these yet. We have to get ourselves under control, and then start on these when we can.
* ✔ Kill the comms meeting.
** This isn't really in our scope but it's partly our fault that it still happens.
** This isn't done but is effectively out of our hands.
* ✔ Get the UX and VD people on Vidyo/Skype and IRC.
** I've contacted Vicky and she's looking into how to get on IRC with the Telefonica firewall in place (she's going to ask Arnau).

====Phase 2 (sprint v2.0-S6 to sprint v2.1-S1)====
* ✔ Switch to the people rotation system that the contacts team uses. (see "Differences Between Teams" / "Contacts" / "People")
* ✔ Begin setting aside time for long-term projects.
* ✔ Gather feedback from the changes previously implemented, iterate where necessary.
*? Begin cross-collaboration and sharing of ideas with other teams. Ask them for feedback and help where necessary.
*? Decide on which long-term projects we will be prioritizing.
*? Begin actual planning of long-term projects, discussing architecture, designs, etc.
** We will be careful to include every team member in these discussions.
* - Establish better relations with UX and VD, consider setting up progress-based meetings for when we need to discuss many things with them.
* - Continue to improve technical documentation.
* - Start estimating during sprint planning.
** We decided to delay this until next sprint due to lack of features to estimate.

====Phase 3 (sprint v2.1-S1 onward)====
* - Actually set time aside and work on long-term projects.
* - Prepare for new team members from partners.
** This is a very loose objective. I think we should start thinking about this here, but I don't have any specifics.
* - Start doing demos of new features/big fixes.
</onlyinclude>