Readers/Web/Team/Retrospectives/2014-01-21

Mobile Web Retrospective, 21 January 2015ll

What's been working well?

edit
  • Google code in - Volunteers \o/
  • Juliusz's QA presentation/hangout thing
  • Ton of bugs in the backlog got fixed.
  • Real time collaboration with design
  • More stuff being worked on for desktop
  • Killed Profile work for time being \o/
  • Staying focused (per wise man advice)

What hasn't been working well?

edit
  • Design is done reactively, 2 Week long sprints not working well for design+++++++
  • Sign off extremely slow - developers punished.++++
  • Lightning deploys due to inadequate test coverage++++
  • Losing Max for 2 weeks
  • Lightning deploys for things that don't need lightning deploys
  • CSS regressions
  • Slow response to anonymous editing discussion +
  • Writing QA browser tests is a slow process - e.g. https://gerrit.wikimedia.org/r/105106 still not merged+
  • REOPENING bugzilla wars.
  • Designs changing a lot during an iteration - lots of scope creep for example in tablet - are we being over demanding on our poor designers/bad communication?
  • Lots of time spent on non-mobile work (is it bad?)
  • Getting someone hired for back-end
  • Interviewing people who don't work out is sad.

What still puzzles us?

edit
  • A design process fit for the mobile team
  • How do we improve QA / test coverage

Discussion around what hasn't worked well

edit

Design is done reactively, 2 Week long sprints not working well for design

edit

What's been preventing design from being ahead?

  • More detail on roadmap; vetted by engineers
    • What type of problems the design team needs to solve
  • The approach to VE planning was really helpful
  • Get design involved in card planning prior to story prioritization
  • Meeting to do bigger picture planning? Leads only?
  • Right now, when we do prioritization, we don't have a clear view of what else is coming up - maybe make stories more clear before going into prioritization?

Action

edit

Kenan

  • Prioritization meeting: make sure stories have necessary acceptance and design criteria
  • Review timeline/backlog for the quarter during prioritization
  • Filling out detail for quarterly roadmap - what does this look like? review at next retro

Sign off extremely slow - developers punished

edit
  • Kenan to keep tabs on WIP? Design too?
  • How do we (as developers) show off our work?
  • Have design/product chase down engineers when cards in 'ready for signoff'?
  • Have owner of story (engineering) follow up with design/product when ready for review
  • Acceptance criteria not always clear enough

Action

edit

Arthur

  • Engineer who selects card from 'ready for dev' sees the card all the way through the process - they are responsible for following up with design/product for signoff
  • If a card meets acceptance criteria but has problem, it should be moved to accepted and bugs filed for issues. If card does NOT meet acceptance criteria, it is moved back to ready for dev (and engineer notified)

Lightning deploys due to inadequate test coverage

edit
  • Every time we have a bug/regression, there should be a test written for it
  • Should we audit our codebase to see where tests need to be?
  • Schedule time to work on testing infrastructure - help Chris from QA?
  • Feels like we need someone from our team to be point of contact with QA?

Action

edit
  • When we have to LD, a regression test MUST be written; this is enforced during review. A task card gets added to Mingle in the current iteration [Arthur]
  • Create a spike to document QA infrastructure issues [Juliusz]
  • Lightning deployments should be tracked - calendar? So we can keep track of notable events? [Arthur]