Platform FE retrospectives

[kabaros]

This is an ongoing post to document the Platform FE retrospectives, and track the actions taken in each one.

[kabaros]

4th of April, 2023 retro

This was the first retrospective in 5 months, so a lot was covered. The main themes for the topics that the team raised were:

• Requirements and planning: the need to improve our planning, requirements gathering and roadmap process.

• Collaboration: the need to improve on collaboration mainly between Frontend and Backend, but also with other teams such as design, functional design, product etc.. as well as intra-team communication between the team members.

Various other points were raised too, about topics ranging from improving the process (better issue management, more focused meetings, and proactive management of users' requests) to improving the team culture when it comes to taking ownership of tasks, and dealing with conflicts and differences in opinion.

A screenshot of the retro board is available here, and the discussion is covered in more details in the meeting notes here.

Actions

Given the long period covered in this retro, some of the actions are not very concrete but they are still actionable and can help kick off further actions. Future retros will be more regular and we should aim for smarter actions.

Each action has an owner, who is the person accountable for it, but they can choose to share the responsibility with others whenever it makes sense. @stian-sandvold and @kabaros will be responsible for overlooking the general progress on these actions to ensure we are on track, and to evaluate them their state in the next retro.

1. Have regular product updates

Owner: @DavidCKen

Context: Many of the issues raised in the retro fell under the way we do planning, requirements analysis and prioritisation. We understand that - with David joining the team - this is an area that will improve massively in the coming period. We also understand that tackling these issues is a long-term goal and will not be achieved over night, nevertheless, the exercise was good to come up with a wish-list of what we'd like to happen from developers' perspective. In the short term, we would just like to have better visibility about the progress, the challenges and what's coming next.

Key Result: to have a regular (monthly?) update from David about the state of product planning, the state of the roadmap and issues and projects coming in the horizon.

2. Clean up Jira board

Owner: @dhis2/team-platform

Context: Right now, our Jira board is not reflecting what we're working on and we need to improve its state if we were to achieve any progress when it comes to planning or our way of working. So please make sure that Jira reflects what you're working on (even ad-hoc business-as-usual tasks that take more than half-day should be there). As our process matures, we will improve the details of how a ticket ends up in a sprint in the first place (definition of ready), and our issue management cycle (sprints vs kanban etc...) but for now, the goal is just to have some basic visibility over what we're doing as a starting point.

Key Result: the whole team should update the board to reflect what they are doing now, and keep the board up to date.

3. Document our way of working

Owner: @kabaros

Context: Few of the points that were raised fall under our process and way of working, for example, the need to have visibility on current state of projects, highlighting blocked issues, making ownership clearer, tackling scope creep, our definition of ready and done, adjusting issue management mechanism (longer sprints, kanban etc..). A starting point to tackle these is to begin discussions about where we are now and where we want to get.

Key Result: document our current way of working and have a blueprint of where we want to get, as a base for discussions with the team and other stakeholders (QA, Product, UX etc..).

4. Lead discussions about improving FE/BE collaboration

Owner: @stian-sandvold

Context: At this stage, we just want to kick off the discussion about ways of improving the FE/BE collaboration. Some concerns and questions raised are whether the Tuesday meeting format is focused enough, would topic-based discussions be better? How can we ensure that we know as early as possible about upcoming Backend features?

Key Result: kick off discussions with different stakeholders to come up with more concrete actions

5. Become more proactive with CoP requests

Owner: @tomzemp

Context: At this point, this seems to be mostly a one-man (Tom) effort. A starting point is to document what he does right now (which channels, threads he follows for example), how he interacts with the issues that he finds, what categories the requests roughly fall under, how others can help, and how he thinks this work can become part of our regular work stream.

Key Result: a presentation during our weekly meeting, based on which we can take further actions.

6. Get feedback about the platform from external users (Uganda training group)

Owner: @amcgee @Topener

Context: In the theme of becoming more proactive with users' requests, we also want to establish channels with developers who use the platform. The developers' meeting in Uganda is a good chance to gather feedback. We suggested to pass to them the survey that @ismay created before, but regardless of the means, we just want to make sure we get objective feedback from them, and establish communication channels for the future.

Key Result: share a survey with Uganda participants, and share the learnings / results with the team

• Have regular product updates
• Clean up Jira board
• Document our way of working
• Lead discussions about improving the platform meeting to be more focused on FE/BE collaboration
• Become more proactive with CoP requests
• Get feedback about the platform from external users (Uganda training group)

[ghost]

We suggested to pass to them the survey that @ismay created before, but regardless of the means, we just want to make sure we get objective feedback from them, and establish communication channels for the future.

To clarify, this is the link for the new survey https://forms.gle/5YfkgdG9QS4QvbkV6 that can be used for the meeting in Uganda. The old survey is closed so the old links will no longer work.

[Topener]

Updating here to say the form has been sent to the attendees, however, it was sent alongside an event-feedback form. Awaiting results on that one too!

[kabaros]

2nd of October Retro

The sprint retro notes are available here. You can find screenshots of the retro board below.

Actions:

• Discuss stuck PRs in weekly meetings: Rather than having a dedicated meeting as suggested in a previous retro, we will make sure that we ask about stuck PRs in weekly Tuesday meetings then create followup meetings if necessary.
  (everyone responsible)
• Start with one-to-ones: We discussed the need to have 1-1s, and Stian said he will kick them off. We will iron the details of how to do these (and with who) as we go on but we want to start with something. Stian will kickoff this process by scheduling initial 1-1s.
  (@stian-sandvold to lead)
• Tackle bugs better: Tackling bugs seems like an afterthought and not an integral part of our work. We need to do this better. Some short-term actions can be to make sure that the Platform Bugs dashboard from QA is shared and discussed on Tuesday meetings, tag FE tickets to have a sense of what we should be working on, to ensure that bugs are reflected in the sprint's work, and organising a Bugathon to tackle bugs... This is a group responsibility and it should be an ongoing action, but since @tomzemp brought the point (and he's the one most involved with fixing bugs), he can oversee our progress in this regard.
  (@tomzemp to evaluate progress / everyone responsible)
• Plan how to do more Pair Programming: We talked about doing more pair programming as an action to ensure more collaboration between us. We will kick off that effort by learning about how to pair properly especially remotely, talk to people in other teams who adopt the practice and see where we can do it without forcing it in our specific context. This action point for now is to kick off the effort but more concrete action points should follow.
  (@kabaros and @stian-sandvold to lead)
• Restart sprints: We dropped using sprints after the summer break. We will restart that, even if we don't have the full resources to do them properly (to do sprint planning, grooming, estimation for example). This will help with other points brought up in the retro like having an overall team-level sense of goals / timing, triaging and proactively tackling bugs, and improve internal communication and visibility within the team.
  (@kabaros)
• Keep Jira up to date and reflective of the work we are doing: We understand that, for now, we get many tickets to work on at ad-hoc times, we don't need to change that and we trust people to make individual judgments about priorities. The only ask is to ensure transparency of what we're working on by keeping Jira up to date and reflective of what we're doing - this is mainly done by assigning the "sprint" field to a ticket (even bugs) so that we know what we are working on, otherwise tickets are lost in the sea of Jira tickets and project.
  (everyone responsible)

Pending actions from previous retros:

• Document way of working - @kabaros will restart this effort in light of the other conversations going in parallel with QA and other teams

---

[kabaros]

December 2023 retro

two stars and a wish - run by Stian

[kabaros]

Below is a screenshot of the retro board

Actions from previous retros

• Surface team feedback about Samwise and release process to wider organisation - @stian-sandvold
• Improve onboarding process (materials on Jira, formalising onboarding buddy etc...) - @d-rita to overview

Previous actions still ongoing

• Start online social time for the team - @DavidCKen
• Do more Pair Programming - @kabaros to plan
• create a recurring demo/presentation slot for the team - will start with a demo for maintenance by @Birkbjo
• Finish and share way of working doc - @kabaros

[kabaros]

Actions from retro

• Rotate who runs the Tuesday meeting (@tomzemp to start)
• Talk about PRs as part of Tuesday meeting
• Establish pairs during sprint planning and Tuesday meeting

Previous ongoing Actions

• Surface team feedback about Samwise and release process to wider organisation - @stian-sandvold
• Start online social time for the team

Retro Board

Below is a screenshot of the board (and mood chart)

[flaminic]

1st August Retro

Actions from retro

• Move retros to be a monthly event (@kabaros to send invites)
• Share team feedback articles (@flaminic to share)
• Organise a feedback session (@flaminic to roganise)
• Organize 2 blog club meetings to watch this video together and discuss it (@kabaros to organise)

Actions from previous retros

• Rotate who runs the Tuesday meeting (@tomzemp to start)
• Talk about PRs as part of Tuesday meeting
• Establish pairs during sprint planning and Tuesday meeting
• Surface team feedback about Samwise and release process to wider organisation - @stian-sandvold
• Start online social time for the team(@flaminic to organise)

Retro Board

[flaminic]

9th Septeber Retro

Actions from retro

• continue working with more than 2 people on a each project
• keep work more organised with Jra tickets (@flaminic to drive this)

Actions from previous retros

• Establish pairs during sprint planning and Tuesday meeting
• Start online social time for the team(@flaminic to organise)
• Move retros to be a monthly event (@kabaros to send invites)
• Share team feedback articles (@flaminic to share)
• Organise a feedback session (@flaminic to oganise)
• Organize 2 blog club meetings to watch this video together and discuss it (@flaminic to organise)

Retro Board

[flaminic]

30th September Retro

Actions from retro

• Defining the scope of which we (platform) have full autonamy and access to make changes (Calendar, Github, jira, etc) (@stian-sandvold to drive)
• Pre-assign people to facilitate meetings (@flaminic to organize rotation)
• Ask Terje/Magnus about using the Open Source course for working on older apps (@stian-sandvold and @tomzemp to ask)
• Make it easier to maintain apps that are not the main focus for a given release (dependencies, broken api's, etc)(@tomzemp to organise the meeting)
• Create a formal process for accepting, reviewing and assigning bugs (Create/Adapt a platform support channel, public) (@stian-sandvold and @Mohammer5 to driv)
• Try to set up more pair programming on apps people are unfamiliar with (whole team)

Actions from previous retros

• continue working with more than 2 people on a each project
• keep work more organised with Jira tickets (@flaminic to drive this) - In progess
• Establish pairs during sprint planning and Tuesday meeting
• Organise a feedback session (@flaminic to oganise)

Retro Board

[flaminic]

4th November Retro

Actions from retro

• Continue to document and narrow/define the scope of initiatives (Stian & David)
• Do a presentation of android webapps (Milagros)
• Create jira tickets for all bugs and issues devs work on that are not in the sprint (whole team)

Actions from previous retros

• Defining the scope of which we (platform) have full autonamy and access to make changes (Calendar, Github, jira, etc) (@stian-sandvold to drive)
• Ask Terje/Magnus about using the Open Source course for working on older apps (@stian-sandvold and @tomzemp to ask)
• Make it easier to maintain apps that are not the main focus for a given release (dependencies, broken api's, etc)(@tomzemp to organise the meeting)
• Create a formal process for accepting, reviewing and assigning bugs (Create/Adapt a platform support channel, public) (@stian-sandvold and @Mohammer5 to driv)
• Try to set up more pair programming on apps people are unfamiliar with (whole team)

Retro Board

[flaminic]

2nd December Retro

Actions from retro

• plan platform wow meeting: focus of reviews and testing (@flaminic)
• go through initiates and try to scope them to the time we have left before release (@stian-sandvold and David)
• provide a list of the platform apps and send to Ola and Olav to see which are to be maintained (@stian-sandvold )
• create a document where we can maintain a list of specs for the maintenance app. tests will be created according to these specs after the freeze (@flaminic)
• next sprint try to have each person pair on at least one story (@tomzemp to make sure we do this during tomorrow's planning)

Actions from previous retros

• Defining the scope of which we (platform) have full autonamy and access to make changes (Calendar, Github, jira, etc) (@stian-sandvold to drive)
• Ask Terje/Magnus about using the Open Source course for working on older apps (@stian-sandvold and @tomzemp to ask)
• Make it easier to maintain apps that are not the main focus for a given release (dependencies, broken api's, etc)(@tomzemp to organise the meeting)
• Create a formal process for accepting, reviewing and assigning bugs (Create/Adapt a platform support channel, public) (@stian-sandvold and @Mohammer5 to driv)

Retro Board

[flaminic]

13th January Retro

Actions from retro

• Organise section on new jira/product process and get feedback on it from the team(David)
• Ask for thing that the team needs to do for other teams pre 42 now. Double check the prioritizations w Stian and David. After this try to not accept further requests unless absolutely need to (@Birkbjo to ask)
• Organise manual tests for new maintenance app (@flaminic to organise)
• Ask initiative lead to make the final decisions for problems when uncertain (whole team)
• Always take and share meeting notes (for initiative try to use confluence) (whole team)

Actions from previous retros

• Defining the scope of which we (platform) have full autonamy and access to make changes (Calendar, Github, jira, etc) (@stian-sandvold to drive)
• Ask Terje/Magnus about using the Open Source course for working on older apps (@stian-sandvold and @tomzemp to ask)
• Make it easier to maintain apps that are not the main focus for a given release (dependencies, broken api's, etc)(@tomzemp to organise the meeting)
• Create a formal process for accepting, reviewing and assigning bugs (Create/Adapt a platform support channel, public) (@stian-sandvold and @Mohammer5 to driv)
• go through initiates and try to scope them to the time we have left before release (@stian-sandvold and David)
• provide a list of the platform apps and send to Ola and Olav to see which are to be maintained (@stian-sandvold )

Retro Board

[stian-sandvold]

3rd February Retro

Actions from retro

• Integrate the Android apps more into the team. Funnel tickets through Stian/David, and make sure not only Milagros works on them (Whole team)
• During sprint planning, make sure we account for about 5 extra tickets each sprint (Whole team)
• Make sure we have regular meetings in initiatives (And outside) for breaking down, exploring and planning work. (@stian-sandvold and others)
• Improve relationship with the backend team to help mitigate risk when working on unfinished backend changes. (@stian-sandvold and others)
• Set up a Miro board to let the team suggest topics and presentations they would like to see (@flaminic).
• Reach out to relevant people to organise presentations of topics requested (@stian-sandvold )

Actions from previous retros

• Organise section on new jira/product process and get feedback on it from the team(David)
• Ask for thing that the team needs to do for other teams pre 42 now. Double check the prioritizations w Stian and David. After this try to not accept further requests unless absolutely need to (@Birkbjo to ask)
• Organise manual tests for new maintenance app (@flaminic to organise)
• Ask initiative lead to make the final decisions for problems when uncertain (whole team)
• Always take and share meeting notes (for initiative try to use confluence) (whole team)
• Defining the scope of which we (platform) have full autonamy and access to make changes (Calendar, Github, jira, etc) (@stian-sandvold to drive)
• Ask Terje/Magnus about using the Open Source course for working on older apps (@stian-sandvold and @tomzemp to ask)
• Create a formal process for accepting, reviewing and assigning bugs (Create/Adapt a platform support channel, public) (@stian-sandvold and @Mohammer5 to driv)
• go through initiates and try to scope them to the time we have left before release (@stian-sandvold and David)
• provide a list of the platform apps and send to Ola and Olav to see which are to be maintained (@stian-sandvold )

[flaminic]

3rd March Retro

Actions from retro

• Talk with Nancy on the best way forward in managing sprints. (@stian-sandvold & David)
• Start looking at tests for maintenance after bug bush (@flaminic to plan)
• Make sure we plan mor more regular meetings for initiatives w BE person (everyone)
• Talk about communication on changes w BE team for ideas on how to improve during Tuesday meeting (@flaminic to bring up)
• Mid sprint high priorities check (@stian-sandvold as you will be facilitating that meeting)

Actions from previous retros

• Make sure we have regular meetings in initiatives (And outside) for breaking down, exploring and planning work. (@stian-sandvold and others)
• Improve relationship with the backend team to help mitigate risk when working on unfinished backend changes. (@stian-sandvold and others)
• Organise section on new jira/product process and get feedback on it from the team(David)
• Organise manual tests for new maintenance app (@flaminic to organise)
• Defining the scope of which we (platform) have full autonamy and access to make changes (Calendar, Github, jira, etc) (@stian-sandvold to drive)
• Ask Terje/Magnus about using the Open Source course for working on older apps (@stian-sandvold and @tomzemp to ask)

Retro Board

[tomzemp]

31 March 2025

Actions from retro

• For the coming sprint, we will make a note on the sprints' tickets that automated tests should be aded as part of the work. During PR review, reviewer should look for tests. If there are no tests, developer for ticket should explain / open a follow-up ticket to write tests (@tomzemp + @Birkbjo who is leading sprint meeting)
• Initiative meetings should invite at least one FE and BE developer (even when it seems that issue is FE or BE exclusive) (@stian-sandvold )
• Make sure we have regular meetings in initiatives (And outside) for breaking down, exploring and planning work. +Have a check-in at least every 3 months for everyone in initiative* (@stian-sandvold and others)
  * the part marked with + was suggested in sprint, and is being added to a previous action item that relates to initiatives meetings.
• create board with prioritised bug tickets that can be picked up as developers have time outside of sprint's tickets (David)

Actions from previous retros

• Improve relationship with the backend team to help mitigate risk when working on unfinished backend changes. (@stian-sandvold and others)
• Organise section on new jira/product process and get feedback on it from the team(David)
• Organise manual tests for new maintenance app (@flaminic to organise)
• Defining the scope of which we (platform) have full autonamy and access to make changes (Calendar, Github, jira, etc) (@stian-sandvold to drive)
• Ask Terje/Magnus about using the Open Source course for working on older apps (@stian-sandvold and @tomzemp to ask)
• Start looking at tests for maintenance after bug bush (@flaminic to plan)
• Make sure we plan mor more regular meetings for initiatives w BE person (everyone)
• Talk about communication on changes w BE team for ideas on how to improve during Tuesday meeting (@flaminic to bring up)

Retro board

[Sharmyn28]

05 May 2025

Actions from retro

• Integrate android apps workflow: a month of no android webapps and pair programming on at least one ticket per sprint (@Sharmyn28). Specific initiatives, include the whole team.
• Working on verticals/most important part first: break tickets during refinement, check road map priority. (@flaminic)
• Can we include feedback in between our dev cycles?: Should we ask for feedback from design (Joe) and implementation? is it possible? It is possible to ask feedback during sprints through initiatives (linked to implementation), during feedback/review meeting, demo milestones.

Actions from previous retros

• For the coming sprint, we will make a note on the sprints' tickets that automated tests should be aded as part of the work. During PR review, reviewer should look for tests. If there are no tests, developer for ticket should explain / open a follow-up ticket to write tests (@tomzemp + @Birkbjo who is leading sprint meeting)
• Initiative meetings should invite at least one FE and BE developer (even when it seems that issue is FE or BE exclusive) (@stian-sandvold )
• Make sure we have regular meetings in initiatives (And outside) for breaking down, exploring and planning work. +Have a check-in at least every 3 months for everyone in initiative* (@stian-sandvold and others)
• Improve relationship with the backend team to help mitigate risk when working on unfinished backend changes. (@stian-sandvold and others)
• Organise section on new jira/product process and get feedback on it from the team(David)
• Organise manual tests for new maintenance app (@flaminic to organise)
• Defining the scope of which we (platform) have full autonamy and access to make changes (Calendar, Github, jira, etc) (@stian-sandvold to drive)
• Ask Terje/Magnus about using the Open Source course for working on older apps (@stian-sandvold and @tomzemp to ask)
• Start looking at tests for maintenance after bug bush (@flaminic to plan)
• Make sure we plan mor more regular meetings for initiatives w BE person (everyone)
• Talk about communication on changes w BE team for ideas on how to improve during Tuesday meeting (@flaminic to bring up)

Retro board