Associated team working agreements

Who plans and facilitates Retros?

Since Phil W left the team, Andy N has been actively encouraging team members to volunteer to plan and facilitate Retros. This is partly to provide cover, but partly to stimulate team members to think more deeply about the value of Retros, and what insights and improvements the team can gain from them.

On reviewing this approach the team has agreed to continue to volunteer to plan and facilitate Retros.

Notes from the discussion:

• Andy N to be available to step in when there are no volunteers

• where individuals are uncertain about running a Retro, consider pairing up or team up with others to do a joint Retro.

Retro formats

There are loads of ‘formats’ of Retros out there (see Retrospectives page on Confluence for links to a bunch of them: mad, sad, glad; stop, start, continue; team healthchecks; lean coffee; etc). But there is less out there on approaches to conducting Retros, especially remotely (MS Teams calls……?)

Team agreed to experiment more with how we conduct Retros. Some ideas:

• pre-Retro survey / poll / Trello board for the team to contribute to, to focus the Retro itself on discussions of anything contentious, rather than ‘ideation'.
  (historically, we haven’t had great input into pre-Retro calls to action, but we hope as this becomes more normalised, input should improve)

• breakout rooms on the Retro itself, to create smaller sub-groups where involvement in the discussion is more comfortable for everyone

PLEASE ADD FURTHER SUGGESTIONS TO THIS PAGE

How to encourage ourselves to follow through on Retro actions agreed

We are very good at generating ideas, and turning those ideas into actions.

We are less good at then taking those actions iteration to iteration.

We agreed to:

• create Retro actions that are more distinct - measurable even;

• ideally have a team member volunteer to lead on them being actioned in the following iteration; and

• where appropriate ticket them up within Jira, in a dedicated column on the Kanban board (for visibility and as a reminder each stand up)

• where inappropriate to ticket up, add to the Kanban policies page, or add to this page

Broadening out the team knowledge around TIS-ESR and Person Update services

When the ‘Leeerrroooy Jenkins!’ contractors rolled off, Pepe was the only permanent team member left carrying the can.

Whilst entirely reliable, he was all the same a single point of failure, which is undesirable in an Agile team (any team, in fact!).

We have been working hard to encourage others in the team to develop their knowledge and understanding of the ESR services we have to provide cover.

On review, it was felt that the progress we are making is very good. Pepe is no longer a single point of failure, though the team needs to continue to step up to ensure this remains the case.

A victim of our own success, there are so few errors these days for the team to practice on!

• consider developing some controlled chaos testing (deliberately compromising a live service in order to test how the system auto-heals, and/or how the team can manually resolve as quickly as possible)

More involvement in Reval work / support

While there was felt to be less urgency around getting whole-team involvement in Reval (given we have 3 people focusing on it already), it is still important that they have some cover.

The best way to find out if levels of documentation / videos is sufficient is to get someone fresh to try to work on the service with them as a reference - and to highlight if they suffice, and if not where they can be strengthened (acknowledging that all documentation can always be strengthened, but that we need to aim for just enough documentation, just in time).

• Someone largely unfamiliar with Reval to lead on reviewing documentation / videos with the challenge: Ask as many questions as possible!

  Note #1: videos should be focussed on how to support the service, rather than how to use the application. And the preference would be a group of short videos, rather than one long one - so that updating them will be more easily incremented. Long videos around how to use the application will get out of date very quickly.

  Note #2: if documentation / videos aren’t enough for someone fresh to be able to support the service, consider how we approached knowledge sharing on ESR as a template for knowledge sharing on Reval.

How to handle knowledge sharing in general within the team for sync services?

We first need to know what the purpose of knowledge sharing is. Then what knowledge would be most valuable to share? That should then lead into how to share it.

• Focus on diagnosing problems and how to resolve them

• Develop drills / scenario-based investigations / quiz

• develop quick fixes for the most common problems. e.g. :
  - for TIS there’s a dashboard of jobs that show success and enable re-running of the jobs;
  - elsewhere re-running of many of the jobs can be turned into an action that could be performed by almost anyone straight from within Slack - meaning that as soon as anyone spots a problem at any time of day or night, they can also re-run the job, which will often fix the problem;
  - Reval sync (currently triggered through an API gateway and a message to a Rabbit broker) could also be converted to a Slack action to re-trigger the job.

Who’s it for

The TIS Team (the whole TIS team)

• Ensure that the Programme side of the team are encouraged not only to attend, but to input into the All Hands, in order that we get a whole-team perspective on how we are achieving desired user outcomes.

What is it’s purpose

The All Hands meeting historically has been a meeting where we have presented a plethora of stats and charts (often ‘vanity’ metrics) in the hope of finding some useful insights. With a look back and a look forward Quarter to Quarter.

The feeling is that this approach isn’t really working and we need a better focus / structure to the All Hands.

• Focus on metrics directly measuring success - not vanity / back-slapping metrics.

• Focus on measuring 'progress' (against the OKR / towards the completion of the whole Service).

• More focus on what’s next (which is partly where the input from the Programme side of the team would be useful, but also a more ‘planned’ approach to tackling some of our Tech Improvements too).

Best format

1 hour call?
½ day call?
In-person (Birmingham)?
Social aspect as well as Quarterly Review / Retro / Planning?

• From the Catherine Toole review, one action is for all current meetings to be reviewed in light of the more focused direction of travel for the team. This will include a review of the All Hands meeting (along with the Review meeting).

• Remote working has had an effect on the interpersonal relationships within the team (some positives - like engaging more with colleagues we were previously separated from, geographically; but many negatives - see the 8th Agile principle).
  Getting together, even as a one-off, occasionally would be worth doing - or at least experimenting with.