Our responsibilities as a base

1. Maintaining our services & products
2. Performance improvement
3. Automated tests
4. Investigating new technologies
5. Preparing for missions
6. Knowledge sharing

Question: How much of this does actually happen?

Anwer: We've covered a small fraction of 1, 2 and 6.

We are a base of 4 teams, instead of a single team.

There are currently very visible lines between Sportsbet, AMS, Comms and Bitcasino.

We need to become a single team and forget about the previous setup. We need to start moving people from project to project - instead of keeping people working in silos, working only on the features they already know. 

We need to acknowledge this and just give it time.... setting up a process isn't a solution for this.

Thoughts?

Our missions are way too long and complicated

Some missions take months to complete. 

This causes multiple problems:

• It's hard to transfer multiple months of knowledge over to people in the launchpad
• The longer the project, the more problems it has landing - what has been built isn't exactly what is needed for the business.
• Launching into production takes weeks

Missions are 1 month max

Your mission (including landing it in production) can take up to a month. Does not matter how many people are working on it. If the mission can't be done in a month, it has to be split up. 

The first step of a mission is process

Your new fancy service needs to be be buildable + deployable automatically before you write the actual feature code. This will allow for quick iterations to easily improve this feature.

Think of it differently...

Instead of having the mindset that you have 4 weeks to build a feature, think of it as you have 1 week to build the feature and 3 weeks to improve it 

• Fail fast
• 80/20 principle

Thoughts?

We go on missions alone

A lot of missions are handled alone by a single developer.

This prevents developers from bouncing ideas between each other as everyone else does not know the context of your mission.  

It also creates a silo - only one person knows anything about the specific mission.

Missions require a minimum of 2 developers

Does not matter the scope of a mission, you need 2 people working on it.

Thoughts?

We do not prepare for missions on the launchpad

There is no preparation work for missions being done by the leads of the missions. 

Preparation work is done when the mission is already on-going. 

Preparation for a mission starts in the launchpad

You should work on preparing the mission to fully understand it before you actually start it.  

Thoughts?

Mission leads do not fully understand their role

Currently we're still somewhat operating in the paradigme that what the Project Owner wants, we build.

This is false - the mission lead has the responsibility to deliver the mission. This includes making sure it's delivered as expected as well as making decisions on what gets cut from the mission to make sure it gets delivered on time. (Teamwork with POs)

Mission leads are in control

In a mission, the mission lead is the alpha. They are in charge of making sure everything gets delivered on time and according to needs of the business. 

Leads need to have challenging conversations if something can't be built in the time frame. Missions are a wishlist, you're responsible for making the most out of the time and resources you are given.

Thoughts?

Our business requirements need some refinement

Project Owners know the project in and out. Developers do not. 

This needs to be kept in mind - domain knowledge of a product is not the same in the company. If a PO requests a feature, they may take some things for granted because they know it's needed for the feature. A developer who has no idea that they are needed will not build it - and deliver a mission that can't be launched.

Thoughts?

Moving from project to project is challenging

You need to learn how to build, deploy, run etc all over again.

Automate workflow for all projects

Develop

Master

Any commits builds a new pre-release docker image

Pre-release images are automatically deployed to t2 env

Any commits builds a new release docker image

Release images are automatically deployed to prelive env

Add semantic release (or any other tool that creates either release notes or updates release notes)

Thoughts?