Skip to main content

Standing in a Circle Clapping is Not Agile

For many organisations going through an agile or digital transformation, there seems to be a culture of standing around clapping. When this behaviour is regular and habitual for every little achievement, I become sceptical of its value.

Today, I would like to explain to you my scepticism.

Firstly, I think that many organisations that are going through a transformation stand in a circle and clap because they hadn't recognised achievements properly in the past. This previous ignoring of achievements is detrimental to culture, as not recognising and surfacing achievements would send signals to people that they are not required to achieve in the first place.

At the same time, the behaviour of celebrating every single achievement (the polar opposite of the scenario above) may also impede achievements from rising to the surface. If every little achievement is recognised, then nothing is an achievement.

There are genuine achievements that are big wins at organisations going through transformations. For example: a huge win would be the automation of releasing. The first few times the product is released, we should celebrate this achievement by coming together and clapping. However, when we stand in a circle and clap for every single automated release that happens several months after we've put an automated pipeline in place, I don't think this is sincere.

We have to stop celebrating these repeated achievements after a few iterations, because they have to become a habit. Continuing to celebrate achievements that should be habits means that these achievements won't be properly formed into habits. Also, if we continue to recognise achievements that should've been habits, it would be disingenuous, as it would mean we aren't looking for further opportunities for improvement.

Whilst recognising achievements is one of the first things that happen in organisations going through transformation, we have to be careful not to obfuscate real achievement with clapping. Instead we should try to recognise genuine achievements to empower the team to build strong habits. Then try to identify more areas for improvement where progress can be made. Otherwise we're not being completely honest with our achievements and future areas of improvement.


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.

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?

I Don't Know

Many people who come from command and control working environments have a very limited circle of safety. This maybe because their suggestions have been discarded rudely, being treated poorly, or always fearing for their job. They do not suggest improvements and are often too scared to ask for help.