-
Notifications
You must be signed in to change notification settings - Fork 2
Retrospective notes 2022.09.07
| Chair | Timekeeper | Note Taker |
|---|---|---|
| Lilith Cole | Lowri Jenkins | Jack Allen |
Items discussed in the previous retrospective
- KB suggested sprint planning/start for the coming sprint can be be delayed by a week to finish off large volume of items in ready/in progress
- Agreed upon by all
Scrumpy Pros:
- Github tickets are more easily tied into the service
- Asynchronous voting - People can vote in advance if they will be away for planning
Cons:
- You can only be in one room at a time, difficult to do priority / points in parallel. We could use both in a hybrid solution but might create more overhead than utility
We will stick with PlanitPoker for now but keep Scrumpy in mind as an adequate backup if needed.
Are people interested in uniforms (e.g shirts) for representing IBEX on support calls? - retuning to later
- Jack Harper feels that users can be confused about our role sometimes when we turn up on support calls
- Other support teams have specific outfits to clearly identify themselves as qualified support staff
- This does not need to be mandatory, but it might be nice to have the option
- Not everyone likes uniforms, can we have other items to identify ourselves? e.g. hats
- Jack Harper will investigate available ISIS "branding" options and report back at next retrospective
- New label with updated contact information has been printed and displayed in TS1 & TS2 blockhouses. Done!
Coffee attendance is extremely low, should we find an alternative for team building? - tried coffee - attendance better if someone brings cake
- Attendance has fizzled to near zero - perhaps a symptom of more people being back in the office
- Suggestion to steal Weekly Coffee & Cake idea from Mantid instead. People in the room agreed this sounds like an appropriate rhythm.
- We will do this in a conference room to enable people to join remotely. Should be convenient for conference room availability.
- We have picked Friday afternoon as the regular time for this for now. We can consider varying the days of the week this takes place if this otherwise excludes anyone from attending.
- Team generally in favour, (more space, better sound).
- Availability may present an issue
- We will trial it when the room is next free in the morning.
- G06 camera better placed.
- G34 is just nicer!
- Sound quality much better when the room is designed for it!
- Seeing and hearing people in the office much better.
- As some of those working remotely can be hard to hear, one option could be to get people headsets to be more audible.
To make it clearer to users that we are from the experiment controls team and not just random members of the general public who have wandered in and started unplugging things, uniforms were discussed.
- Jack Harper found an online resource for ISIS branded clothing which is used by other groups: Found a place to order clothes from: http://www.artisanshirts.co.uk/ The uniform would be optional as not everyone would necessarily like to wear it.
Tasks left to do on this topic:
- Find out if there is a specific procedure for ordering ISIS branded clothing- maybe ask Jamie.
- Check what they can produce
- If there is a specific piece of clothing that someone would prefer to have, let Kathryn know directly ("I might be convinced to wear a this").
The answer: "Yes, just let the organiser know how long you need"
Could we make the repo_checks jenkins job statuses go to the #Jenkins teams channel rather than #General?
Possible solution discussed:
- We could try and automate builds and stop checks temporarily.
- Jack Allen will place an existing GitHub workflow developed for personal use into a repository to be adapted to work through Jenkins. The main piece of work that will need to be undertaken to do this is setting up an authentication token for the Jenkins user to be able to push to the repository as the GitHub workflow developed relies on a personal access token which is not suitable for use in an organisational repository.
Would it be helpful whilst we are trying something different with planning if I run the next sprint planning meetings as well?
A resounding yes! 👍
Try running only on Wednesdays and Fridays interchangeably to be inclusive of those working remotely on one of the two suggested days.
stand ups have recently been getting longer and longer, we need to keep them short and sweet. Daily stand-up is constructed for people to speak for a short period of time due to getting tired standing up. Those of us working remotely sit down so happy to talk longer. When anything slightly in more depth needs to be discussed it should be broken into a separate meeting.
To resolve this:
- Everyone should be more proactive and aware that you can interrupt someone to move on. ("words, then muting people, then violence as a last resort" 👊 )
- Turn up on time! - We should make a start no later than 10:03am.
- To keep things moving, we should move on from looking through status screens to individual status's by 10:15am no matter what.
Suggestions: Anyone can merge is checkstyle remains the same or decreases - only admins can merge if needed and checkstyle would goes up. Automate checkstyle in GitHub to become part of the review (can't be missed this way). Up to developer discretion to allow merging in if checkstyle would increase, but generally only allow to be merged in if checkstyle remains the same or decreases.
The only complexity mentioned with this is we would need to tell Jenkins which branch to compare against master and that master would need pulling to ensure it is up to date.
Action taken: Jack Allen will create an issue to explore the viability of automating through GitHub and label as tech depth. We will leave checkstyles as they are for now, but be stricter with merging in pull requests and be more concise with updates in stand-up - no harm in saying "can I catch you afterwards" to resolve checkstyle increases.
Currently, it is hard to find appropriate worthwhile issues for new starters and members in the team early in their careers - Can we be more liberal with adding things? -
From the discussion held, there doesn't seem to be enough appropriate tickets at the moment which is why it may be hard to find new developer issues.
Older issues are potentially suitable, but not necessarily documented well enough for new starters to pick up. As people see appropriate tickets, they should update the description if still relevant and add the "new developer" labels to them once checked by Kathryn who is currently going through all tickets.