🔴 Software Estimations—Engineering Culture

This week's agenda & recap of last week

👇 Note: 16:00 CEST is now the standard time.

Please set an intention if you don’t want to miss it. Sign up on the LinkedIn event to have it easily pop into your calendar.

It will be recorded, but I suggest you join in live for the chat participation.

Agenda for the Live Stream

• Why estimate?

• Estimations that provide certainty

• Collaborate with stakeholders, rather than arguing

Q&A, live discussion throughout the 90 minutes. Don't be shy!

Check your time: Some countries will start rolling daylight saving changes starting next week. The event local follows Paris/Berlin/Amsterdam time.

Last week’s stream on Trunk-based development

Trunk-based Development Principles and Practices

😈 We discussed the frustration of dealing with conflicts and merging in traditional version control systems. So-called merge hell. You know it well. No one escapes it. This is one of the accidental solutions that trunk-based development (TBD) provides, but is not the primary goal.

🤝 The idea of Continuous Integration through TBD is to empower developers to take ownership of their changes, regardless of their seniority or experience level. This alleviates all other forms of gate-keeping behavior notorious for low-trust environments.

💡 Trunk-based development is not about continuous deployment, but rather about being in a state of being deployable and ensuring everything is functioning properly before pushing changes to the main branch. As Bryan Finster mentioned live in chat: “Knowing it doesn't break anything is valuable. Knowing that any breaks will be tiny is valuable. Reducing inventory risk is valuable.“

💡 TBD is about being able to deploy independently the parts of a project that are done, regardless of the remaining unfinished tasks, allowing for faster and more efficient development.

📈 Giving developers the freedom to use the full potential of the production system can lead to noticeable skill improvement and increased productivity over time.

🔄 Trunk-based Development focuses on merging code first and then testing it, rather than testing it before merging, to avoid the need for multiple rounds of testing and potential bugs. It exposes everything that can be improved to achieve a high standard, making it valuable for those who want to take their work seriously.

💪 TBD or CI provide certainty and boost professionalism in communication, eliminating the need for guessing and vague progress updates.

🤔 Branches are considered an anti-pattern for this culture as they create isolation and hinder progress, making it difficult to guess the overall progress of the project.

Start at your biggest issue

💪 Adrian: "You want to be happy with your work...and what is the foundation of Happiness? It's progress."
The concept of progress is crucial in trunk-based development, as it allows teams to continuously move forward and make improvements, leading to a sense of fulfillment and satisfaction.

💡 Focus on identifying the biggest problem in your team and improving on it, rather than getting overwhelmed by trying to fix everything at once.

🔬 Rather than hard metrics, use team surveys and qualitative assessments to determine where to start improving the pipeline.

💡 Focus on addressing the biggest pain point each week to make continuous small improvements and skyrocket your team's performance.