My previous post explained how we started a small transformation of a development team using Trunk based development. The post triggered some people around me to explain more about how they can apply that on their own team.

A Bit of My History with Software Development

I remember my first days as a developer building a website/application in a team with 6, with no sort of version control system, just changing the files directly into the production server via Dreamweaver. There were no tests or any quality control. What a time.

Because of that, we introduced a lot of problems which disrupted the daily work of many people that depended on that software to do their work.

Our manager grew worried about all that, his job was on the line and he did what a lot of us would do. At least considered doing it.

  1. Hired a tester to make sure this problem would not happen again.
  2. All the code needed approval by Quality Assurance before going live.

That is a logical decision for that kind of problem. The wrong one, though.

Why Might that Be the Wrong Approach?

It is very hard to foresee the meaningful impact of this change. As our environment has changed, our behavior changed slowly which also shaped our mindset.

The positive side of it. Fewer bugs were reaching production. That is a big win that nobody can deny.

The negative side of it? Glad you asked.

Even though fewer bugs were reaching production, more bugs were reaching the QA. Now we also had a list of bugs (some refer now to a backlog of bugs). Our tester was becoming the bottleneck to bring code to production.

Now think for a second. How would you solve this additional problem? The way we solved, we hired another tester. Because that makes sense!

#devops #digital transformation #release management #ownership #trunk based development

Reclaiming Ownership in The Development Team
1.05 GEEK