1. Don't let perfect get in the way of good

Perfectionism robs the customer of a solution.

We like to get things out quickly, even if we have to rush fixes out. That's a positive, the bugs demonstrate use and user intent.

So long as the feedback loop is tight and DevOps is good, it's really not that big of a deal to have a bug in production.

2. No Egos

We encourage divergent thinking.

From day 1 on the team, developers are encouraged to challenge the status quo. They also accept that they too will be challenged. Developers are then less married to their idea than finding the right solution.

I love it when the people in the team prove me wrong. I regularly ask for feedback on what we're collectively doing wrong, and what I'm individually doing wrong.

3. "Why Not" bias

We're "Why Not" people, not "Why" people.

Because we're not egotists, we welcome failure as an opportunity to learn.

In that environment, there is no reason not to try new ways of doing things, or explore new ideas.

4. Tight feedback loops

Keeping feedback loops tight means that we waste less time when we get things wrong, and know sooner when we get them right.

Developers are in direct contact with customers.

Developers are plugged into monitoring/operations.

I'm fundamentally accountable for the speed of the feedback loops, as this has the highest multiplier effect on team productivity.

5. Continuous Improvement

Everyone on the team is encouraged to identify their failings and share with the team.

We don't care about getting things right all the time, only about improving when we get them wrong.

We don't chew people out when they stuff up, they own it themselves and we all improve as a result.

6. Leadership by Example

We're still learning how to drive change through documentation and process design.

We currently lead by example. Any practice expected of the team, is demonstrated by the leader and mimicked naturally.

Whether how code review is done, how you test, how you estimate. It's all about leadership. Every developer is a leader. Everyone has to exhibit the right behaviours.

"Agile"

We used to be more agile when running off a kanban board with basic task kick-offs with me for each piece of work.

Now on a 2-week sprint cycle. Demo/Retro/Sprint Planning, async standups in Slack.

Noble Chats

Pioneered by Steven Noble, these chats are a randomised pairing of different developers to go over obstacles from the stand-up and do some pair programming where someone is stuck.

Dev Catchups

On a weekly basis we get together to discuss interesting lessons learnt from the week.

Developers are encouraged to share new ideas with the team. Some become DACIs and eventually new practices for the group.

Tech Debt Fridays

Technical debt is a reality. It must be paid down regularly and in decent amounts or you pay interest.

We occasionally dedicate Fridays to the squashing of bugs and technical debt. More of a challenge since implementing sprints.

Git Workflow

We use a simplified gitflow workflow. We hope to further simplify to eradicate the "develop" branch and go straight to production more regularly.

We do code reviews on small changesets, where the last reviewer merges. Squash into develop, rebase to master.

1. Plan

- use JIRA for backlog/grooming/planning

- use DDD techniques like event storming for big picture work and process modeling

- Spikes and POCs to address hotspots and uncertainty

2. Create

- Use Github to host our code

- Use local environments or development sandboxes for feedback in while coding

- Open PRs for feedback/review

3. Build/Verify

- Use Buildkite for all build orchestration

- CI pipelines apply unit tests, integration tests, static code analysis (including style checks), dependency security audits and finally create a deployment artifact

- Have > 10,000 unit tests right now

4. Deploy

- Use Buildkite for all build orchestration

- CD pipelines take a verified deployment artifact and release them to an environment (production, preproduction, sandbox, depending on configuration)

5. Operate

- We do all our own Ops. No SREs in the team

- Not much to do in this phase, mostly monitoring, which comes next.

- We're looking at implementing canary releases in the future

6. Monitor

- All metrics, logs and traces go into Datadog

- Datadog alerts us around different metrics crossing thresholds we deem unacceptable, or anomalies detected

- Datadog pages us through VictorOps, which is set to escalate for a subset of monitors/alerts

- Rollbar gives us feedback on errors throw in applications and services

7. Feedback

- We take feedback from monitoring, from HEAP analytics and most importantly, direct from users and bring this into our backlog and tech debt register

Evolutionary Architecture

• Tools, technology, techniques are constantly changing
• Needs are constantly changing
• Technical debt and performance degradation accumulate in different areas over time

We look to support constant change, rather than architect nirvana

Context Diagram

Container Diagram

Next Evolution of Arch

Zoom in on RTE architecture

Chaos Engineering

Bug Bounty Program

New Account/Subscription Trust Model