No matter which company and tech organization I spoke with this year or which problem they initially saw as their pain point, after several days of working together, we concluded that their overall process was the root cause.
Common misconceptions:
- We can change our outcome by optimizing our Ticket boards
- We can change our outcome by switching to XYZ Agile Framework
- We changed our outcome by switching to XYZ tooling, like Jira.
- We will deliver when it’s perfectly complete.
- We need to test it more before we ship it to the client.
Those are just some, but they already provide a good display of what is wrong. None of the mentioned things really tackle the root-cause problem. Even if you do all those points, you will still miss one essential thing: a constant feedback loop.
This article is based on the Live Episode with Bryan Finster and Denis Čahuk“The Three Wrongs of DevOps—Engineering Culture”.
When you miss feedback, you will miss the goal.
We are doing business with humans, and we humans have needs, requirements, and, most importantly, expectations. To meet expectations, the people building feature by feature need to know what those expectations are about, but this is often untrue.
Instead, Software Engineers are often fed with processed tickets in some form of Kanban or “Scrum” board. Tickets that are based on user feedback but already interpreted by at least one other person. Additionally, the tickets don’t seem to loop straight back to the Software Engineers; instead, I often see a temporal decoupling problem there as well–the tickets are gathered for days, sometimes weeks, before being formed as an “update” package handed off to the developers.
❌ Unfortunately, oftentimes, this is done with a tight deadline because much of the time has already been wasted with “ticket” management.
Be aware: Requirements, Needs, and Expectations change quickly.
The temporal gap between the actual feedback of the user and the engineer working on the next iteration is oftentimes huge, blended by an artificially tight deadline in the end for the engineer. This is a recipe for failure.
🍪 The shorter the time between user feedback and the next iteration gets, the more likely you are to hit the goal, meet the expectation, and satisfy the user.
Bryan Finster: About engineering feedback and business feedback.
Continuous delivery is about fast delivery and early feedback.
The key is to establish a delivery culture based on small batches of work, delivered continuously and often with fast feedback.
What solves most of the problems set a tech organization and a tech-driven company have is to solve the delivery method. The key is establishing a delivery culture based on small batches of work, delivered continuously and often with fast feedback.
There are several very important aspects to this idea:
A: The receiving end, like the user or client, will tell you if what you provide meets your expectations early on.
B: The receiving end will see the constant progress early in the process, not when it’s “done,” in the opinion of the developers. Which helps everyone create a great product the users like instead of a mediocre one. This creates trust and bonds. Deadline problems can be mitigated by including your clients in the development cycle.
C: You will know your software is stable due to constant tests, including unfinished features in live builds, using techniques like shadow deployments and feature flags.
And so we want to get feedback as rapidly as possible on the engineering thing. And people tell me there's no value in delivering anything until its feature is complete. No, no, no, I know it's stable. That's very valuable, and then the other part is I want to make sure we're on the right track.- Bryan Finster, Defense Unicorns
Deadlines are the arch-enemy of hitting quality.
I don’t know how it is with you, but when I face a “Deadline” given to me or my teams, it’s often already very late. The deadline tastes bitter and often feels like “deliver or die.” It is not the best foundation for quality development.
This is usually the result of disconnection between clients and developers, and we can solve it by connecting them. That was obvious when reading it, right?
🍪 Making deadlines just iterations is the goal, and this is done by including Software Engineers in the feedback cycle or process.
When I started decades ago, no matter what I did, I communicated directly to the users or clients and received feedback from them. In recent years, everything seems to have changed more to isolation. Often results in a weird form of “complex Git-Flow Isolation attempt.”
Bryan Finster seems to have had the same experience:
I mean, I've been doing this for almost 30 years now. Is that you get requirements. My first job was wonderful because in the early nineties, except for tooling, we were DevOps. I would talk to my customers who wanted modifications to our core system and gather their requirements. It's going to take two or three days to put this together. I demoed it to them after I got it done. I didn't install it. I didn't make all the database changes. It was just, it was just me. And just, I got to deliver fast. It was awesome.- Bryan Finster, Defense Unicorns
When Software Engineers refuse responsibility
Yes, business stakeholders, Product Owners, and Project Managers must understand that Software Engineering must become an integral part of the development cycle. But this doesn’t mean Software Engineers are exempt from any responsibility.
In companies where the problems occur, which I have described initially, developers are often as isolated as there was of work they have implemented themselves.
Yes, developers shape their working environment; seniors do, teams lead, and teams do. The decision to work with something like Git-Flow in isolation is often a decision the developers are involved in and happy with.
Why? That’s contextual, but from what I saw, engineers often feel safe in isolation. There’s this wrong notion that covering up my flaws and mistakes is essential.
❌ This is industrial-age thinking. Engineers do need a mindset change here.
“As a developer, I deliver my part when it’s finished–without mistakes I get blamed for–by merging a branch after several days of “hidden” work.”
What’s wrong with that?
- The developer doesn’t expose himself or herself to the team and, by doing that, refuses to get feedback on his or her progress. Feedback will improve the developer’s habits, skills, and domain expertise.
- The developer works on a business feature in isolation, without feedback from anyone, not even the team. There is no course correction and second thought, missing the idea of agile development at its core.
- Being isolated means not connecting to users, clients, or business stakeholders. It also means no effective communication between tasks, harming the outcome and business. This is not just missing responsibility; it is harmful to business.
- In worst-case scenarios, isolated work becomes obsolete in a branch, not being merged to the trunk, and never shown. Resources and business opportunities are wasted. Yes, wasted.
🍪 Software Engineers must understand themselves as responsible and accountable individuals contributing to expected business outcomes. Doing everything necessary to improve outcomes by understanding the domain they are working in, the needs and requirements of their clients, and the expectations. Those are the traits of Senior Engineers and why they are the cornerstones and role models of teams.
Watch Video
Well, I think every software engineer should be a business expert. I've had people who claim to be senior engineers saying that their job is algorithms and data structures.Yeah, I mean, your entry-level, I'm sorry. I don't care how well you can code your entry level. If we don't understand deeply the business problem we're trying to solve, we're ineffective as software engineers.- Bryan Finster, Defense Unicorns
Conclusion – The Continuous Delivery’s Effect
Most often, when reading about Continuous Delivery, it’s about the technical aspects- how teams implement them, how the pipelines work, or how to branch in Git.
This article shall provide advice based on my experience on why the practice of Continuous Delivery and the Engineering Culture around it significantly impact business outcomes.
The business outcome accumulates user satisfaction, acceptance, and business success. All these factors will decide whether or not the company’s products are successful.
🍪 It’s key to cultivating an Engineering Culture and environment where business stakeholders and Engineers are “Software Developers” pushing to create great products with their clients and users. This is why I prefer CD; this is what solved problems for so many companies.
Have a great Sunday!
Adrian
Looking for a Mentor?
With 24 years of multi-domain experience as a Software Engineer, CTO, and Entrepreneur, 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.
Find me on MentorCruise.com