Ways of working

The team has taken on a lot of new technical knowledge during this project and also a lot of agile ways of working.

TDD is a code writing style. TDD stipulates that you write a test for the function you want code to perform before you write code to perform the function. This test runs every time a change is made to code in the system so, if at any point the code stops doing what it's supposed to, the test will fail and developers can easily see where the failure is.

The project team has taken to writing code in a TDD style to ensure that the work we do is as robust as possible.

Pair programming is a development practise where 2 developers work side by side on a task. This is great for problem solving and knowledge sharing. The project team pair programmes as often as possible because two heads really are better than one.

This is another development practice. It involves a group of 3 or more developers getting together to write code all at once. Think pair programming on steroids.

A 'spike' is a timeboxed investigation into something we're not sure how to solve. Typically a couple of people actually work on the spike as knowledge about it can become quite silo'd and that's not something we want.

We have a 30 minute spike review meeting every week where the team who worked on the spike present what they did, what they found and what they propose to do about it to the whole team. The team then gets involved, asks questions and decides on the solution. No decision is made in isolation, ever.

The project team comment their code but that only goes so far. In order to help any new developers joining the project team, or Hackney, we have a GitHub wiki for all things technical related to the project. There is a wiki per service as well as one for our overall architecture. If you want to take a look, head over to our GitHub and have a look around.

The Hackney team have a development playbook that all work should follow. It covers all kinds of things and aims to be our service standard for anything we develop.

The project team records work that needs to be done in the form of user stories. This is a way of explaining what we expect the result of our work to be and the business benefit that offers. Our user story forms our 'what' and 'why'. It doesn't tell us what the solution is, only what we want to have at the end.

Acceptance criteria give us the detail of the how the user story will be implemented. Finally, our definition of done tells us when we can truly consider the task complete.

We keep all of our stories and acceptance criteria in JIRA (project management software). And example of a story, acceptance criteria and definition of done is below:

"As a developer, I want to be alerted when the API is not performing well so that I can take action and resolve as soon as possible to keep services running"

Acceptance criteria:

• Alert is sent for production environment when it is slow to respond or retrieve data
• Alert is sent for production environment when it does not respond or retrieve data
• Alert is sent for development environment when it is slow to respond or retrieve data
• Alert is sent for development environment when it is does not respond or retrieve data
• Alert is sent for staging environment when it is slow to respond or retrieve data
• Alert is sent for staging environment when it is does not respond or retrieve data

This is done when:

• Work is inline with the Hackney API Playbook
• Documentation has been updated
• Tests have passed

Every 2 weeks, the whole team comes together to prepare the backlog. When we do this, we work through user stories and build out the implementation details in the form of tasks.

Once the whole team understand how the story will be implemented, we will estimate stories using story points. We use PlanningPoker.com to do this.

We also re-prioritise the backlog in this session to make sure the most important work is at the top.

It does what it says on the tin. Every morning we have a quick 15 minute catch up to talk about what we did yesterday, what we plan on doing today and if we have any problems and need help.

We produce a summary of how our week has gone each week. These are our weeknotes. You can watch our video weeknote playlist on YouTube if you like

The project runs in 1 week sprints. The team plans their sprint together and takes into account how much time can be committed to the project over the next five working days. Stories from the top of the backlog are added into the sprint until it's 'full'.

We hold show & tells every 2 weeks. You can see all of our show & tell slide decks to date below

The team have a retrospective every 2 weeks or so. The aim of these sessions to to review the last period of work, identify anything that didn't go so well and come up with some ways to improve that going forwards.