FLOWCON 2022

Les équipes techniques sont tiraillées en permanence entre deux objectifs apparemment incompatibles : livrer rapidement les nouvelles fonctionnalités, et construire une base de code propre et robuste. C'est en réalité une fausse dichotomie car il existe un paramètre qui peut changer la dynamique du jeu : pour livrer plus rapidement un meilleur code, il suffit d'être plus forts ! Au cours de cette session, Regis expliquera comment les principes lean qui sous-tendent le Thinking People System peuvent aider les CTO et les responsables techniques à accélérer drastiquement le niveau de compétences de leurs équipes.

Mob programming is when the whole development team works on the same thing, at the same time, in the same space and with one shared computer, screen and keyboard. I've been working as a software engineer in a development team where we've been mob programming for well over a year, every day, without exceptions. We've noticed an enormous boost in productivity and we really feel that we make the most use of the team's overall brain capacity to solve problems and to ship high quality software to our users. But it's not always that easy. We've learned to master this way of working the hard way, by continuously improving on our processes. In this presentation I will give an introduction to mob programming, the effects we've seen, why you should consider this way of working and some tips and tricks that we've learned along the way.

Data is the lifeblood of any Data-Driven organisation. High-value Data products, AI/ML pipelines and business decisions are made based on data.
Therefore, it is highly imperative that this data is of the highest quality and continues to stay high quality. Consequently, there is a need to do this centrally to provide standardisation and promote transparency and trust on the data quality metrics calculated and used to measure quality.
Data Mesh is a Data Architecture pattern that has emerged recently. It advocates for centralized capabilities for that constitutes data platform and federated governance across all data products which themselves are domain specific.

This talk is about the practical application of Data Mesh principle in the Data Quality space, the challenges of implementing such capability at scale and of course the opportunities it has unlocked within the organisation in turn.

Why?
Data pretty much rules the majority of customer experience and journeys, which in turn drive the P&L for businesses. This data is captured and sourced via many data pipelines. The quality of data has a direct impact on the quality of the ML model output, accuracy and relevance. It also has a proportional impact on the cost of running data engineering pipelines be it stream or batch data processing.

What is this really about?
This talk is about the practical application of Data Mesh principle. There are not many examples of this out there but there is tremendous interest for this. This talk takes Data Quality as an example of how you can apply this in reality, the challenges of implementing such capability at scale and of course the opportunities it has unlocked within the organisation in turn

What does the talk covers?
Following the DataMesh pattern to building platform capabilities that powers decentralised data products, I want to layout an approach to implementing Data Quality at scale, the key steps in providing confidence and trust in the data being produced & consumed by the data product teams. In this talk, I will talk about
- Data Quality challenges in modern day data-driven enterprises from both Stream and Batch perspective
- Dimensions & metrics of Data Quality, subjective vs objective lens when looking at Data Quality and the resulting challenges in implementing for it
- Key parts and approach to build a Data Quality platform at scale to provide near-realtime visibility to DQ issues
- Fitting this capability around data eco-system including triggering remediation actions such as stopping a data pipeline

There has been a focus on autonomy in information technology; From autonomy in code, to autonomy while coding, autonomous systems with microservices to autonomous high-performing teams. When you read Daniel Pink’s research in the book Drive, it makes sense; autonomy is one of the three things that motivate us; it is the ability of the person to make his or her own decisions. However, often autonomy can lead to isolation and disconnect from the rest of the code, team, or organisation. So how can we balance the individual needs while staying connected to the team/organisation to stay autonomous?

In this talk, we will go through all the levels we deal with in IT, from code to organisation collaboration. We will go into autonomy at each level and explain how we often confuse autonomy with individual needs. These individual needs can turn into isolation and disconnect from the code, team and organisation. Through examples, we will show how our compulsiveness towards autonomy gives us both downsides of being isolated and coupled in the code, within the team and organisation. You will leave the talk knowing how polarity management can help you manage this paradox between the individual and the team/organisation and get the benefits from the whole and the individual to be balanced.

Pour toujours plus de valeur métier, sortez des sentiers battus avec la composition d’ateliers collectifs.
Fan de longue date des ateliers de découverte, comme l’Event Storming, l’Example Mapping, le User Story Mapping, mais aussi le CRC Cards ; je vous proposerai plusieurs compositions d’ateliers que j’utilise régulièrement.
Puis je vous offrirai les clefs pour créer vos propres ateliers composites afin de créer vos propres compositions afin de comprendre collectivement le métier finement.

How do you move an organisation of 15 teams and their single shared monolith from bi-annual releases to fortnightly releases in under four months? How do you reduce release pain and cost? Because of the monolith, we could not start with one team. We had to apply changes to all 15 teams at once. Four months later the organisation released every two weeks like clockwork and got faster feedback.

How do you know where to start, when technological and organisational challenges surround you?

To introduce change at scale, we used: the Improvement Kata as a continuous improvement framework to execute and measure organisational change, Value Stream Mapping to analyse the current delivery process, and the Theory Of Constraints to choose which changes to apply first and start off the organisational changes we needed to improve quality and drive down lead times. Four months later the organisation eventually reached a state of Continuous Delivery.

Six months after achieving Continuous Delivery, I realised it was not the plan that helped the organisation. Instead, Fear Conversations guided us. They allowed us to uncover, locate and understand the stakeholders’ fears. To then mitigate these fears and navigate the difficult conversations we had to have.

If you thought Continuous Delivery was just for the happy few having trendy microservices, think again!

Il y a du chemin... Là où dans l'industrie les défauts se comptent en défaut par million de pièce produite, un développeur introduit en moyenne 70 bugs pour 1000 lignes de code produite. Nous nous sommes plongés dans les expérimentations de Sadao Nomura, qui a lancé dans des usines Toyota le Dantotsu, "Better than the best" un programme sur 3 ans capable de réduire de 85% les défauts.

Nous nous sommes inspirés dans la tech des pratiques, management visuels et outils du Dantotsu pour :
- Éradiquer les causes profondes d'un bug en 24h après sa détection
- Identifier les "weak points", problèmes types qui nécessitent de muscler le système de formation
- Créer une culture de la qualité où chacun partage ses bugs résolus