Don’t be a brick in the wall – Part 2

So – my prediction wasn’t far off…

About three weeks before the world cup started, I posted an observation that footballers know more about teamwork than IT guys. I predicted that the world cup final would be a match between Brazil and Argentina and I imagined what would happen if the Brazilian team acted like a traditional IT team, with different silos for dev, QA and ops/defenders, mid-fielders and strikers. My prediction was not far off, had it not been for Germany (who knocked out Brazil in the semi-final and met Argentina in the final) that line-up might have happened. However, the manner in which I predicted Brazil would be defeated was pretty close to the mark!

Before reading this post you should probably take a look at the original post: Don’t be a brick in the wall

What I would really like to draw attention to is the circumstances under which Brazil were totally annihilated by Germany:


The crippling of the Brazilian team didn’t actually happen because their manager, Scolari, sat them down and dictated an appalling strategy as I imagined in my original post. The Brazilian team failed because of an over-reliance on two outstanding players.

Firstly, and most obviously, their star player, Neymar da Silva Santos Júnior, was injured in their previous match. Neymar scored four goals at the 2014 world cup, twice as many as the next highest goal scorer in the squad. He was also a player who was happy to run back and support other players in other areas of the pitch when required. Brazil relied on Neymar as he was the only player who was able to deploy the ball into the back of the opponents net with any sort of reliability. Neymar was the equivalent of your production DBA – the only guy who really understands all the systems and has the ability to deploy your code successfully. Last month, while at NDC, I learned about the concept of ‘the bus factor’. This is a vivid demonstration of that idea. Do you have a single individual at your organisation, without whom you would struggle to release your code?

Secondly, the Brazilian captain, Thiago Silva, picked up a yellow card in the previous match, earning him a ban from the Germany game. Silva was the Brazilian project manager. He played in central defence, a position from which he could see the whole game in front of him. He was a natural leader and did a great job at organising the other players. He optimised the whole. Without him the captains armband fell to David Luiz, another central defender who is a wonderful footballer, but one who loves running at the ball wherever it landed. Luiz lacked the discipline to see the bigger picture. As a result, the team stopped working as a single deployment pipeline, it stopped working as a team, as a single system. Defensively the team fell to pieces and in the space of six first half minutes they conceded four goals. They were five-nil down within thirty minutes. They ended up losing 7-1.

This was one of the heaviest and most high profile of all world cup defeats in history. I was off-by-one as I predicted it would happen in the final, but the reasons it happened were:

  • Over-reliance on a single finisher – who was suddenly unavailable when needed the most.
  • The loss of a well disciplined team dynamic across functions – resulting in chaos and simple mistakes.

Now think…

Are you over reliant on a single individual at any part in your deployment pipeline?

If so you might want to think about how you can spread the knowledge either through pairing, documentation, standardisation or automation. If you have any other ideas please let me know! 🙂

Are the different functions in your pipeline (dev, QA, ops for example) working well together as a single team, aiming to deliver your business goals?

If not – as I asked in my original ‘Brick in the Wall’ post – what can you do to tear down the wall? What can you personally do to start working with the other functions better? Can you lead by example, by making friends across functional boundaries, introducing people to each other and listening to others concerns?

 

Leave a Reply

Your email address will not be published.