Agenda

1. Review Retro Board (10 mins)

2. Voting (2 mins)

3. Discussion (15 mins)

4. Summary Actions (3 mins)

Participants

• @Claudia Malzer

• @Gill Osguthorpe

• @Jag Goraya

• @John Fereira

• @Kurt Nordstrom

• @md331 (Deactivated)

• @steve.osguthorpe 

Apologies 

• @Benjamin Ahlborn

Retrospective

• More comfortable with project structure and processes

• Happy with the rhythm currently present in the project sprints

  • Nice to see this is being felt outside of development, in the  feature / story preparation stages

• Better understanding of Grails and the project technologies, although at the expense of the first iteration taking longer.

• Code reuse between the 2 UI modules.

• Had time to pick up smaller tasks

• Feedback loop from testing to bugs being raised

• Transition form internal orgs to mod-organization-storage went fairly smoothly

• The management of the dev process seemed to be smoother.

• This project is often at bleeding-edge, and that can cause confusion as to where to find code or process that might be similar to what we want to achieve, to allow for reuse

  • We're doing Phase 3 planning at the moment, including looking at potential (future) module dependencies

  • We intend to flag these dependencies to other teams as soon as we have completed assessing the technical approach we intend to take

  • The Washington meeting (June 2019) is an opportunity to negotiate scheduling early development of potential dependencies

  • Improvements to release management for Stripes/UI modules may help mitigate a bit of the bleeding edge pain during delivery cycles

  • We're also looking at how to accommodate system analysis as part of the onboarding / knowledge share process

• Testing can be problematic when we rely on 3rd party plugins, eg, Find Org

• Onboarding time and learning curve for Grails and related techs we use are often high at the beginning of a developers involvement.

• JIRA is often not updated inline with the projects processes.

  • See discussion notes below

Discussion Notes

JIRA is often not updated inline with the projects processes

• The goal here is to 

  • have accurate current status of progress and obstacles

  • reduce friction of Jira admin for all team members (including developers, testers, PO and scrum master)

• Leaving assignee unchanged helps make it easier to track work that has been 'owned' by a particular person

• This doesn't help identify who has responsibility for an item right now, although a combination of other fields may help

  • Tester Assignee field could be used to identify who is responsible for QA

  • Status of In Code Review should mean it's FAO Component Lead 

  • Status of In QA  should mean it's FAO Tester Assignee 

  • Status of For Review  should mean it's FAO Product Owner (the Jira Project Lead )

  • Status of For Release  should mean it's FAO Lead Dev

• If a PR hasn't passed code review, the Jira issue status is not changed back to Open  or In Progress  - the re-work is managed through Github to-and-fro

• Automating Jira transitions from Gtihub PR status could be done, if the integration has been set up.

  • Needs some verification

  • Automation will only be effective if only one PR is raised against each issue: exceptions would have to be manually handled

• Backlog / Kanban board filters in Jira have been set up to make it easier for leads and testers to identify items that need action based on status, rather than Assignee

  • Checking these should be part of daily routine

Still to consider: 

• Inferring current state of progress based on Jira status still relies on developers picking up and (self-)assigning issues

• Initial issue assignment could be handled in Sprint Planning. 

  • We do currently indicate who might pick up a piece of work in Sprint Planning log, but this isn't always reflected in Jira

  • Some items will inevitably be left in the backlog or arise during the sprint

• A story will often have front-end and back-end work. 

  • These can (and should) be distinguished by separate subtasks 

  • Subtasks can be separately assigned

  • Separate PRs can be raised against each subtask to support automated Jira transition

• But then, who should the story be assigned to? The PO?

Actions