How we work

1. Requirements and Prioritisation

Projects

We expect the bulk of project requirements to come from two sources:

1. Via the business through the Data Science Requirement Form
2. The data science team proactively identifying an area where data science can be used for benefit

Upon starting a project, a Project Initiation Document (PID) should be completed and agreed with the product owner. Projects should be managed on the projects Trello board.

Idea development

Each project begins as an idea that needs to be developed before we can make a informed decision on whether the project should be taken forward at the next prioritisation meeting.

A member of the data science team should take on ideas and work with the product manager (i.e. someone with subject knowledge or interested user) to develop the idea. Consider the discussion points which will be used to select projects.

At a minimum idea Trello cards should have:

• Brief description
• Product manager
• Due date
• Data available

Quarterly Prioritisation

One a quarter (minimum) we meet to decide which projects will be taken forward. We assess the work against four criteria:

• Impact ➡ the project has tangible impact on the work DfT
• Feasibility ➡ the technical likelihood the project will be a success. This often hinges on the availability of appropriate data sources and technical experience.
• Profile ➡ projects that raise the profile of DfT as a data science driven department or the profile of the Data Science Team within DfT.
• Development ➡the project will allow a team-member to learning new skills

Work that isn't selected for the quarter but still meets the criteria will be reassessed in the next work-cycle.

Discussion points

1. What do we know about this requirement?

The ideas development phase should aim to answer these questions.

• Who is the product owner?
• What area is it for?
• What's the requirement?
• Is there a present solution?
• What's the user need here?
• What data do we have available?
• Is there any other background that's relevant?

2. Why should we do this? (Optimism)

• What's the positive impact (monetary / time)?
• Reputation?
• Building relationships?
• Could this product scale further?

• Learning / doing something new or innovative?

• Why shouldn't we do this? (Criticism)

• What's the negative impact?

• Does the user know what they want?

• What's the opportunity cost?

• Is there a monetary cost to this?

• What's the process for completing it? (Logical)

• How long will this take us?

• Do we have the tools, data and skills to deliver?

• What issues & barriers might come up along the way?

• What happens after delivery?

• Can we hand maintaining this off to another area?

• What other alternatives and possibilities are there? (Creative)

• If we don't do this, who will?

• Is it possible to accomplish this requirement a different way?

• Can we help or enable this requirement in some way?

• How do we feel about this requirement? (Intuition)

• Based upon the discussion thus far, how do we feel about the requirement?
• Do we have any past experiences that might be relevant?

2. Development

Preparation

Before development starts meet with the project owner and refine the user need. It to refine the scope of the project, what will be delivered, the timescales, and minimum viable product (MVP). Consider agreeing a regular catchup with the project manager to discuss progress and refine/review the requirement. Think about the data and infrastructure required to complete the project.

Development

We employ an agile way of working:

• All projects should have a GitHub repo (use the ds- prefix to signify that the repo is a data science project). Follow the recommendations for working with git and ensuring branches are code reviewed.
• Work in sprints, reduce the tasks to a checklist, and track them on the Trello ticket.
• Plan the weeks work on a Monday during an extended team scrum. Also discuss any work required to develop new project tickets before the next quarterly planning session.
• At daily scrums review progress against the sprint plan and consider any blockers. Always fail fast if a project ceases to become viable.
• Gather feedback: meet regularly with the project manager and/or stakeholders to review progress, demo what you have made, and refine the project requirement.

Handover process (TBA)

To be agreed. However, initial thoughts that handover process should be part of the planning and development phases. How a project is developed should have the long term handover in mind.

3. Post-development

Dissemination

• Show-the-thing: present your work to the team (with a focus on technology used any interesting packages/libraries/technologies you used) and wider stakeholders (with a focus on engagement).
• Peer learning: consider if any skills you've learned could be shared with the team in a peer learning session.
• Document: ensure both technical and non-technical documentation is written for the project. At a minimum provide a background on what the project does and how the code can be run. This should be in the form project readme. In some situations a paired documentation site or package documentation framework (such as Python Sphinx or R pkgdown).

Retrospectives

• Reflect on the project at the next retrospective session - consider what went well, what did not go well, actions that can be taken forward for the next project/sprint and puzzles that remain to be solved.
• Rather than doing a retrospective after each project, we will review projects on mass at a minimum of once per quarter.

Final project review

• Quality assurance: Each sprint will likely feature multiple code reviews - but the final review should particularly focus on the documentation and consider any loose ends.
• Github
  • Log any known issues/features that are known to be needed by users as GitHub issues. If work has started on resolving any of these issues, reference the branch and summaries progress on the ticket.
  • Clean up the source tree. If there are branches that are no longer in use and have been merged into master then delete them.
• Trello: Check the Trello card is up to date
  • What you did should be evident from pull requests and what has not been completed should be referenced as an issue on GitHub. Either reference these on the Trello card or write a short summary.
  • Write a project summary on the Trello Card if the README on GitHub does not cover it already. Also consider writing an external facing line, that summarises the project.
• Feedback form: Send the project feedback from to the relevant stakeholders.