This is the second post in my series on the Trainline way of developing great software products at scale. If you haven’t already done so, you may want to check out the first post which is on Engineering People and Culture.

Our Shared Processes

The Trainline way of developing software emerged as we came to the realisation that we needed a certain level of alignment and a shared set of conventions across our teams in order to continue to function efficiently. We call this concept “aligned autonomy”. What we mean is that, while we value autonomy, it is useful to adopt some shared conventions to facilitate interoperability: a common language and set of norms which bind us all together. One analogy which comes to mind is the science community’s adoption of the metric system of measurement as a standard; while there is nothing inherently wrong with measuring in feet, fluid ounces or Fahrenheit, there is great benefit in a community all using the same measurement. So here are the processes which we share across all teams:

We are Agile

First and foremost, we embrace the spirit and philosophy of Agile. We believe in delivering customer value early and often, we believe in working sustainably to maintain a healthy team and a healthy code base, we believe in collaboration and knowledge share, we believe in excellent craftsmanship, smooth workflows, cutting red tape and in pushing ownership and responsibility down into teams.

We do Scrum

When we were smaller, we were more agnostic about which particular Agile methodology teams should adopt. But what we found was that with new teams springing up, new people joining and new initiatives leaping to the top of the priority list, the agnostic approach led to far too much vagueness and uncertainty which became an impediment to getting teams up and running fast and getting people working together quickly from the get-go. Based on feedback from team members, particularly new joiners, adopting the common lingua franca of Scrum provided much needed clarity and helped teams settle down much faster.

Scrum is a well-known industry standard which provides a simple framework for teams and newcomers to get up and running quickly and to maintain a sustainable cadence to all of their activities. By working in fixed time cycles, Scrum provides valuable transparency and reporting which is simple to keep in harmony with the regular scheduling of meetings and updates across the organisation. The principle of timeboxing provides a powerful tool for focus, clarity and creativity.

We plan ahead

Let’s be clear: Agile does not mean no planning. Scrum does not mean no planning. Such myths still perpetuate in the industry partly because Agile planning looks very different to Waterfall planning. Agile planning should not be synonymous with burdensome wastefulness.

Our view is that planning happens all the time. Little and often is the mantra. Every sprint starts with a sprint planning. Every day starts with the daily stand-up, which is a planning session for the day ahead. The retrospective is a session to plan how to do things better next time round. And a backlog refinement session also helps us fine-tune our plans.

In addition to the above, determining what is needed for a successful sprint planning, such as an understanding of an appropriate architectural solution or clear acceptance criteria and working backwards from that, we have found that, at scale, it is useful to do the following:

1. Lean Solution Architecture

Lean Solution Architecture is always ahead of the engineering horizon and formally documented. We incorporate architecting & planning in a lean way (just in time) with architectural solutions in place a minimum of 2 sprints ahead of the Engineering Teams.

This activity will be carried out by key members of the team in consultation with our Chief Architect and will happen whenever a significant new piece of work is being undertaken which will require some deep thinking about how to successfully architect the solution in such a way that is in harmony with the rest of the estate and with known future plans.

2. Product Roadmaps

Our Product Owners are asked to define Product Roadmaps as prioritised Epics in JIRA. This documented plan should be kept up-to-date and linked to from the Cluster’s/project’s home page.

3. Estimation

We regularly size our epics with t-shirt sizes and our user stories with relative story points, which map to timescales via velocity. We have found that in our context, using Agile estimation techniques helps with the following:

• Planning roadmaps
• Structuring teams
• Managing workflow and team capacity
• Co-ordination of dependencies
• Prioritisation
• Hiring and investment
• Surfacing complexities early