###### tags: `RFC`

# Stand-up time and format RFC

## Issue 1: Stand-up time slot splits the day in half and does not give enough time in the day to react to issues brought up.

We were thinking about moving the stand-up back to a morning time slot. The proposition is 9:15, right after check-in.

The company check-in will be hard-limited by Søren, ensuring we don't conflict which was the original reason for moving it from the morning.

This also has the added benefit, of aligning everyone in the morning on the day's work ahead.

## Issue 2: The format of running through all features and tasks on the board is problematic.

This was brought up a lot on the retrospective, and is posing additional issues too, eg. people not currently working on anything are ignored.

Our proposition would be to move back to a three-question around the table format with a feature-focused twist.

Something along the lines of:
(Working draft)
- What have you done yesterday to contribute to feature X.
- What is the goal today in contributing to feature X.
- Are there any blockers that prevent you from contributing to feature X.
(Added benefit is the ability to prepare for spec sessions better - eg. I can mention that in about half a day my feature will be completed, so people can expect to get an invitation to a spec session and prepare. So you no longer have to wait hours until people are available.)

## Issue 3: WIPs not respected. Backend devs move on from a feature before the feature is complete.

This goes against the way we work, and we need a better alternative. For this, we consider a stricter focus on WIP:

This means, that if you work a feature - you are committed to that and only that feature until it is complete. If there is no more backend or frontend work on it, writing backend tests, cypress tests, quality assuring or ongoingly integrating the frontend and backend, reviewing are among the things that can be done.
Picking up easier cross-discipline tasks (eg. backenders fixing easier frontend bugs or vice versa) OR just as valuable - pair programming cross-disciplines. All the above ensure that the features will be completed as fast as possible and with the best possible quality, which is the top focus.

Further reading if interested in the WIP subject.
* [Management Myth #1: The Myth of 100% Utilization](https://www.agileconnection.com/article/management-myth-1-myth-100-utilization)
* [The Phoenix Project - Gene Kim](https://itrevolution.com/the-phoenix-project/)
* [The Unicorn Project - Gene Kim](https://itrevolution.com/the-unicorn-project/)

Notes:
-Having standup after lunch wont work cuz its too late to react if something comes up.
-Some people cannot get anything done when we have so many meetings.
-We should monitor time on the meetings strictly.
-Having shared responsibility, BE and FE should work in parallel
that not means that BE should wait for FE and vice versa but people are still responsible for that feature, work on other task is fine but consider switching context cuz it makes it harder to go back and forth
-There are too many BE compare to FE developers
-BF could help the FE may be with small tasks or rubber duck?
-Take notes at the end/during the day
-Kanban board will still be revisited
-Take notes at the end/during the day what have you done so then present on the standup.
-Write down even the meetings.