After closing 2023, I want to write about some commonalities I experienced when working with other tech organizations as a fellow. At the beginning of 2023, continuous delivery (CD)1 wasn’t as much of a priority to talk about as at the end of the year.
When I started to help others as a fellow in 2022, I had already been practicing CD for years. During the years beforehand, I wasn’t really aware of the terminology; it just felt suitable to practice it, including Trunk-based development. It felt natural, especially for the traditional SMB type of company.
After joining several organizations this year as a fellow and mentor, continuous delivery was the most lacking practice. The longer we dug into root cause analysis, the closer we came to the same conclusion each time:
👉 The engineering wasn’t centered around the idea of delivery.
The following Wrongs were common:
Development and Software Releases were tightly connected (Git Flow)
That was incredibly dominant in cross-platform setups, in which web and native development were done simultaneously. The entire development cycle was centered around complex and more significant feature releases. In theory, that was a good idea for everyone; in practice, it never really worked out.
The reason for that was simple: Find me on MentorCruise.com. The teams never had enough time and capacity to make those giant leaps due to much feedback from the last feature release, which was often about dysfunctions. Instead of working on the current feature, engineers worked on many features in many contexts, which led to the stacking of a second backlog.
In more extended isolation periods, the developers worked independently to fix bugs or somehow ship the current feature set. That resulted in many Git branches having huge differences between platforms.
👉 A very negative side-effect was the toxic culture emerging from that. Instead of openly talking about problems, things were covered up, and finger-pointing was the day-to-day culture. In reality, it was just about losing control.
🍪 Solution: Decouple Development from Feature Releases. Release what you have done this day, get feedback, and iterate on that. Don’t work in long-lived branches; only push to version control when your changes pass tests and are ready to deploy. Consider Feature toggles to “shadow” deploy partly working features to collect technical feedback (Stability) and user feedback (Acceptance) already.
Working with large and complex tickets (Opposite of small batch sizes)
The missing sense of a short development life-cycle is related to the last point. Badly-defined tickets were created without the involvement of the engineers in any way, which contained too many ideas for just one task. This is often the root cause of many quality problems. Quality was never defined, not by the product owner, not by the project manager, or by the engineering department. Even more problematic is that quality is hard to determine for the engineer during development.
A clear sign of dysfunction is when an engineer starts to work on a ticket, there’s an immediate need to clarify things. But we are already in the development phase; the task should be straightforward and single. Otherwise, the engineer won’t determine if the task is done.
When this is the case, you can be sure that the engineering department is disconnected from the feedback cycle of changes made to production. Instead, other people in a “department” gather and process feedback without involving software engineering.
The funny part: Somehow, companies don’t want to understand that software development is about the process of engineering and feedback; it’s what the software engineer is supposed to do. Well, that’s not funny; it’s sad and a root cause of many business problems and toxic cultures.
🍪 Solution: Start to work in smaller batches, at best defined together with the engineers. A single ticket should contain a single task, clearly defining when it is “done.” To clarify, done means ready to deploy to production and collect feedback to iterate. It’s not meant to be feature-ready! Accept Feedback-Cycle as part of the development process, including product owners, engineers, and users.
Waiting for being “Done” before releasing to production.
Imagine you have a more extensive feature, an estimated 3 weeks of work. Now, an engineer has started working on that feature and disappeared for 3 weeks, just reporting here and there some cryptic reports, pretending “we are on track.”
On what track, please?
We are talking about a feature of a minimum of 120 hours of work if a single developer is working on it. How can a poorly written set of tickets and a Figma file represent what the client needs, and how can you ensure the engineer understood the needs and why things were described like that?
Understand: The engineer is still developing the feature. Feedback is necessary during this period!
After three weeks, we realized the estimation was wrong, and we needed two more weeks because of X, Y, and Z problems. Business stakeholders become nervous, the Product Owner puts more pressure on the engineering department to get the feature “done,” and users still haven’t seen anything of value.
Instead, users keep reporting other issues, which the mentioned developer needs to fix while working on the current feature, which is probably the X, Y, or Z problem.
👉 That’s the recipe for failure.
🍪 Solution: Deploy at least at the end of every day as an engineer. Deploy and show the results to stakeholders, PO, and users. Gather and discuss the feedback. By doing that, there is already clarity about the “track” you are on after a week, which is 1/3 of the time. Stakeholders know colleagues know, and users may have provided feedback already. You delivered business value before even releasing the feature.
Great side-effect: You remove a lot of stress-based toxicity from your culture. Stakeholders want to see progress. You show progress daily, not after 2 weeks of overtime.
Delivery and feedback should be the central aspect.
Let’s be honest: the problems or Wrongs mentioned above show that no one cares about delivery and feedback. It’s more about pushing towards an artificial, roughly defined release in the future. That’s the easy route; it is tempting but sure to fail long.
Yes, this is one of the significant commonalities I have faced in different companies of different sizes in the last two years.
Nurturing a continuous delivery culture is a safe way to mitigate these problems to create ongoing value and clarity about which direction we want to go as a company and tech organization. It’s about mitigating unnecessary stress and open communication.
Business stakeholders aren’t bad people; they also have their “stressors”. Help them as engineers to keep them informed daily and haptically about the process you do. Even if you have estimated wrongly, the business will understand and “forgive” if you can honestly explain that by showing the actual process daily.
That’s basic human psychology – no hocus pocus.
Looking for a Mentor?
Find me on MentorCruise.com.
With 24 years of multi-domain experience as a CTO, entrepreneur, and software developer, I am a Fellow-Type mentor dedicated to your professional growth. We'll progressively and continuously work through your challenges through our weekly calls and Slack support.
🍀 My goal is to empower you with the understanding and tools you need to solve these issues yourself.
I'm not here to fix problems for you; I aim to enable you to tackle them independently. Explore my articles and videos to understand who I am and how I can assist you on your journey.
Yours faithfully,
Adrian, the snackableCTO 🍪