ANDROID[edit]

October 23, 2015

Previous Retrospective Actions[edit]

Action! Wait a sprint to see if there is progress on HockeyApp blockers. Use default implementation if not. DONE H.A. GOT

Manually handling Android configuration changes did, as expected but not elaborted, introduce complexity but was definitely worthwhile. I think the Google docs should be updated to say "Activities with simple views don't need this. Activities with map or WebView-like complexity do."+
One of our most insidious bugs was fixed (by a volunteer!) +++
Volunteer contributions (mostly). They're a time investment but definitely worthwhile so far.
java-mwapi submodule style was very useful when needed. Made debugging much simpler and less crazy than munging a jar binary repeatedly. The library will be deprecated but I'm going to try to write about this particular (and novel, I believe) aspect of it.

Work flowing through the system+
- Making big changes and upgrades (HockeyApp, intro'ing bugs)
- Bugs are a hiccup in workflow
- Patches stacked up with dependencies can make bottlenecks
- Code reviews weren't getting daily check-ins
- More focus on the service side took dev time away
- DB: Writing less code than usual
Underestimating capacity
- Often waiting for signoff on things
- Self-QA helping
- Estimation is accurate

Not confused, but I have a question: do we want to do more unit testing? Yes +1+
I too have a question: Are we getting the most we can out of our ceremonies (and our Scrum Master)?
Status of testing devices on order+

Action! Let's remember to estimate things
- Use standup for notifying of estimation needs, adhoc hatjitsu
Action! Column to backlog: Design Doing (no more questions for design that aren't in the sprint) [MAX]
Action! Need more sync up/communication w/Reading Web team ("MFE styles break our presentation") [EMAIL, MAX]
Action! Need update on ordered testing devices [ADAM]

October 23, 2015

Action! Test drive Google Drive assets/spec management [TEAM] ONGOING
- iOS 5.0 Specs https://docs.google.com/document/d/1YPsHpgInH6RiUY4vVyyJp9tt5HtvG3u3sIB-gar4YPI/edit#
- Design stuff can live in Phab
- Spec is working well, design assets is rough
Action! Let's ship stuff, not focus too much on perfection/robustness BETTER, TRICKY
Action! IRC norms for Phab communication: Email thread [BRIAN] NOT DONE
Action! Get more regular updates w/design (standups?) [MAX EMAIL THREAD]
- Or post-estimation kick-off?
Action! Set a timeline for when the QA tasks are acted on [BRIAN/JOSH] ONGOING

PM signoff!
Pace of developement is picking up
iOS 5.0 Specs doc
GitHub community for diagnosing and working around DevOps issues (see below)
New designs looking sharp
iOS 9 features looking friggin' sweet
Specs discussions w/ Josh & Elena
- Feeling good about focusing on specs, hope it will clear up lots of ambiguity and make the app better
App is looking good - working well
Feed!!!

Meeting email thread: need teamwide planning and stand-ups
- Tough right now, let's get the whole team more in the loop
- Feels like we need a more cohesive, basic planning meeting
Too much re-litigating/arguing
- Wasting a lot of time discussing things at execution-time
- Working together - or not?d
Design assets migrating to google drive (IMO its fine, lets keep Prod specs on Google and mocks on Phab)
DevOps infrastructure (iTC changes, broke fastlane _and_ CocoaPods)
Not having a 3D-touch-able device (BG)

Action! Gut check on assets managment in pholio, Kaity to use pholio more
Action! IRC norms for Phab communication: Email thread [BRIAN] NOT DONE
Action! Get more regular updates w/design (standups?) [MAX EMAIL THREAD CONT'D]
- Or post-estimation kick-off?
- If no decision made after a few days of the email thread, let's just pick something
Action! Need more regular team-wide buy-in
- Meetings?
Action! Research how other teams do specs (e.g. Reading Web team)
Action! We need a standard QA rigor, engineers to design a QA acceptance criteria for all testing