Wikimedia Apps/imported/Retrospective-Apri 2 2015

= Review of Team norms =

https://www.mediawiki.org/wiki/Mobile_web/Team/Team_norms

The team reviewed team norms together with our new tam member, Michael Holloway. A few action items were generated from this discussion:

'''Action! '''split our team norm page from mobile web team norm page [KL]

Action! Revise first team norm to say something like: "If it isn't documented, it didn't happen" in order to separate concerns of documentation from communication (ensure both happen)

Action! socialize and document new team norm (or add this information to existing appropriate team norm): "More ad hoc hangouts in the bat cave"

Action! Can we get Vibha on IRC consistently?

= Previous Retrospective Actions = = Worked Well = = Worked Poorly =
 * Action! Do some sleuthing around the org (see retro notes for some leads) to see what others have done to allow pull requests on Github and what might be feasible for our team [COREY] ONGOING
 * Action! reschedule process review to discuss the range of topics that arose in the retro [KRISTEN] DONE
 * joining of Michael!+1+1
 * onboarding of Michael!
 * green light from Google for featuring (yeah!!!)
 * building production release apks ready to go and test
 * Working with TSG ++
 * unit testing iOS data migration+
 * sharing app data for testing data migration
 * maybe capture some data sets for easy-to-repro sanity checks
 * Android pace ftw! Lots of improvements
 * Extemporaneous hangouts with Corey and Brian - understanding design feedback, level of fidelity that is helpful in prototyping.+1
 * It was AWESOME getting to work with Vibha while she created graphics for iOS record in iTunes Connect
 * I was impressed by how the iOS engineers banded together to get things ready for a final final, maybe final release candidate
 * Honing in more regular process for QA testing of release candidates
 * Got a lot better with communication between engineering and PM - think we better understand product vs engineering concerns.
 * Share a fact: https://upload.wikimedia.org/wikipedia/commons/f/ff/Share-a-Fact_on_the_Official_Wikipedia_Android_app.webm
 * Moiz sharing/retweeting ShareAFact cards
 * Quarterly planning actually gave us a pretty good result despite being a clusterfuck +1
 * Creation of iOS engineering backlog and team "review" meetings
 * Consensus on what we want to work on - reader experience
 * Focusing on things which we didnt have a chance to really do before - play store/ app store screenshots with engg.
 * iOS Pace
 * bug triaging (release blocker almost slipped through, took repeated conversations to re-align) +
 * Quarterly planning +++++++
 * should spread out meetings over a couple of weeks and start much earlier
 * should be seperated into "Brainstorming" and "Planning" meetings Brainstorming should occur at least 2 weeks before planning.
 * Sucks that planning is not structured in a remote friendsly way - remotes got kicked for the 2nd half of the meeting
 * Team health check: would be nice to make it monthly, maybe consolidated with retro+
 * No follow up on Design Process from the process meeting a few weeks ago
 * Making goals to push ourselves! Aim Low!
 * iOS dependency management (lock specific versions?)
 * crash caused by bumping AFNetworking w/o verification
 * lack of process for regularly updating and checking deps
 * Elena has 1 testing device???????????? i'm gonna give her my ios 6, although +1 ++
 * There's only 1 Elena? There's a Rumanna, although unsure if she's mainly on VE +

= Confuses Us =
 * featuring on Play Store...?
 * follow-up on health check actions/improvements (why leads only?)
 * iOS release progress++
 * We're trying to make improvements, but I still feel a lack of focus/urgency about hammering our current release candidate to prep for app store release (https://www.thedash.com/)
 * Whats going on with Q4 planning? Its been silent - what is supposed to be happening during the unstructured sprint?
 * Whats going on with design right now? Are we planning anything?+
 * My intelligent half is sensing that prototypes can *sometimes become about interface fancy* instead of user behavior. Lets nail user behavior, hesitation, mental readiness first. (UX mockups vs high fidelity comps)+
 * planning for everything except for OKR-related tasks, or including non-feature work as part of OKR
 * performance improvements?
 * platform improvements (and other tech backlog items)
 * How we want to move forward with github as a team++++
 * gerrit still sucks
 * how prototyping, iteration, and getting "data" is going to work for meeting Q4 OKRs +
 * are we all aligned on how prototyping is going to work and what the expected outcomes are?

= Top 3 areas for improvement & related actions=
 * Quarterly planning +++++++
 * should spread out meetings over a couple of weeks and start much earlier
 * should be seperated into "Brainstorming" and "Planning" meetings Brainstorming should occur at least 2 weeks before planning.
 * Sucks that planning is not structured in a remote friendsly way - remotes got kicked for the 2nd half of the meeting


 * How we want to move forward with github as a team++++
 * gerrit still sucks
 * Corey got shut down when he tried to figure out github/gerritt integration :-(


 * iOS release progress++ https://www.mediawiki.org/wiki/Talk:Wikimedia_Apps/Team/Release_process, https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Releases , https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BEZ8WZm9mtHmozsk9aQ1s5c7mmjgntkmuBnx8tA1Q_A/edit#gid=685752906 , moar emails?, moar always say in standup?
 * We're trying to make improvements, but I still feel a lack of focus/urgency about hammering our current release candidate to prep for app store release (https://www.thedash.com/)


 * Action! Draft Quarterly planning reformed process and share with team [KL]
 * Action! email to mobile-tech on remote conversation protocols [BG]
 * Action! Corey write up a Github proposal for the team [CF]
 * Action! iOS release progress email [BG]

Proposed but undiscussed:
 * Action? Capture iOS data migration fixtures for easier, more-frequent testing