Our ways of working
Annual Leave
We aim to maintain a minimum of two engineers available per sprint.
When arranging leave we try to offer sufficient notice. This will generally be twice the leave period.
EG. When taking two weeks off, this will be arranged and agreed four weeks in advance.
Duty Tech
We currently run a rota on support for the #ask-modernisation-platform channel, offering support during working hours. For more information see the Duty Rota page.
Work and tasks management
GitHub projects are used to manage our workload. We use a scrum board to help us visualise the work delivery progress and we work in two week sprints to deliver milestones.
When a task or story (GitHub issue) is created it will appear in a backlog of the project or in a backlog of a sprint that it was assigned to. While it is OK to create a placeholder task with a minimum description in a backlog, once it is planned in a certain sprint, the information in the task must be populated to meet the Definition of Ready (DoR). Make sure to update a task description before a refinement session or do not assign it to a sprint.
Once the tasks are selected for development in the coming sprint, the board allows a task to be in one of four stages. When a ticket is read to work on, it will be displayed under To Do stage column. When a ticket gets picked up by a team member it gets assigned to that team member and it is moved to the In Progress stage. When a ticket gets implemented and tested, it is further moved to the Done stage.
Occasionally there are situations that work on a ticket gets blocked, the Blocked stage is for such occasions.
As a team we have agreed to do the following for each stage:
To Do
- Tasks are roughly prioritised during a sprint planning session, but we are not obliged to take the one from the top. We have the freedom of picking a task that we want to work on and we do not pre-assign team members to a task prior the start of a sprint.
- Tasks that are selected for a sprint should have all the necessary information in the task description, including a Definition of Done (DoD). If it is not clear what is asked in the task, then it does not meet the DoR and therefore should be taken out of the sprint.
In Progress
- Adding progress notes to a task as we reach a milestone rather than daily updates.
- Including links to PRs, information about tests (if not part of the PR workflow) and other useful references in the task comments.
- When a task takes longer to complete than initially expected it is up to an individual to raise it with a team to get some help or to break down the task.
- We all should take part in reviewing tasks.
Blocked
- If you suspect that a task will be blocked for the whole sprint, take it out of the sprint.
Done
- Tasks can be closed when they have been implemented, tested and reviewed.
- Closing an issue moves a task to Done, where moving an issue to Done does not close it, hence close it, rather than move it.
Working with Git and GitHub
There is a number of things we can do to make collaborating on code seamless. Although we do not want to impose too many rules on our team members, the following list is what we agreed as a team to do as a minimum:
- Keeping a good git hygiene
git fetch/git pullinmainbefore branching out when starting on a new task. Mergingmainregularly into your branch on local and resolving the merge conflicts or rebasing before committing and pushing to remote. - Adding meaningful messages when committing, such as what have you achieved in this step.
- Running tests, verifying if the tests/SCA has passed and that the
terraform planand the pipeline runs clean before creating a PR. - Providing enough information in the PR description so that another team member has enough context to be able to understand the change and to review it. Adding explanation on what is implemented with the PR and why. Adding information on tests if they were run outside of the GitHub actions pipeline and other useful links or references that help to understand the changes (e.g. a link to the issue or a doc).
- Not approving PRs that do not have a good description or commit messages.
- Approving only PRs that you understand (it applies to PRs created within and outside the team), limiting reviews to the platform code only.
- Verifying the pipeline run clean post merge.
- Using
major.minor.patchfor tags/releases.
We also think it is good to:
- use a meaningful branch naming, using prefixes such as
feature/,fix/,docs/etc., including an issue number and making it a summary of what your goal is (e.g.feature/2563-usingOIDC-in-base), - squash commits before committing to remote, so that each commit represents a step in the implementation (combining planned changes with fixes to errors),
- … and/or squash commits when merging a remote branch with the
main.
Spikes
Spikes are used to work out if an idea is feasible and if so how it should be implemented.
When writing issues for spikes, use SPIKE: at the beginning of the issue title.
All spikes should be timeboxed and last no longer than one sprint, the issue should state the timebox for the spike.
The definition of done should include the following:
- details of research / information learned / options should be added to the issue comments
- output and options of the spike should be presented to the team so a decision on how to progress can be made, this decision should be recorded in the issue comments
- if it is decided to continue, issues should be created for the work required (linking back to the original spike)
If the decision (to proceed or not) is of architectural significance an ADR (architectural decision record) should be created.