Skip to main content

More than just a build/release pipeline

You've setup your build server, have continuous integration/delivery. Setup your release service, have continuous deployment. Your team are following proper branching strategy. Good yeah?

However...
Code PRs are carelessly merged, builds are always broken and you're 3 sprints behind.

What's the problem?

An initial examination will show that your team are following all the rules. However, further examination will show that they aren't being professional in other things. Many leads will simply suggest adding more rules. However, many rules should be the trigger that something is not going right in the first place.

So, what is it that we can do to rectify some of the above issues.

Explain 'why?'

Explain to your developers, why you actually have these things in place. For example:

Continuous Integration: To ensure that you haven't broken the build or tests. As a broken build or test hinders other developer's work. In addition, the longer a tests fail, the harder they are to fix, meaning a higher chance of bugs appearing in your product or even the software product not doing what it's supposed to do.

Continuous Delivery: To ensure that the build is always able to be deployed. So we don't have to waste time at the end of the sprint patching together the build.

Continuous Deployment: To provide a mechanism to request quick feedback to testers and stakeholders.

Speak to individual members

The above problems often revolve either around a maturing culture. Or even worse, a bad culture. It often only takes one or two people to build a good culture, at the same time, it can take one or two people to destroy a culture. 

So it's important to identify key individuals. Both the good-culture building individuals as well as the destroyers. Encourage those who are positive, and talk to those who are negative to see what's wrong. Be sure to practice empathy to ensure that you can help individuals that are in need of it.

Finally...

Be patient. Positive cultural changes involve slow change of bad habits. Focus on one of these habits first, when your team see the difference one small positive change can make, the next change will be easier.

these include:
  • Proper value given to code reviews.
  • Proper respect given to the build status.
  • Proper response to feedback.

Comments

Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.


Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?