Tech stories: The Scrumbags
Tags: watercooler, worklife, devlife
Published: 2021-01-05 23:13:34

As I promised in this series I try to share sad stories from the **corporate IT world** and I would simultaneously add how those situations could have been solved in a humane way.

My goal is to start the discussion on how we live a good chunk of our lives and if the requirements of _taking everything as a robot without emotions_ 😐 can be loosened to fit normal human reactions in.

So I'm going to share the first story about...

# Corporate scrum
Not in general but how in one company it was implemented in. When the transition to scrum started there were a lot of problems at the company:

- **deadlines were constantly missed** (one of my friends said: "I don't get why they are upset about it! It's the date of the deadline plus two months fixing bugs.")
- we had very **infrequent**, big releases
- separate skills were totally **separate teams** not caring about the other's deadlines

So they hired a _consultant team_ to lead the way, let's be agile! Implement scrum!

I will spare you the details of the implementation; in every transition there are hiccups, there are conflicts. Therefore they are not the topic of this article. The interesting story is what some of the management took away from what the consultants said...

## Total surveillance 👀
What I remember mostly from the stand-ups I had in the morning that I had to really carefully concentrate on what will I say about what I have done the day before to sound it was a lot. I missed a lot about what my peers were doing: if I was listening to them I forgot what I wanted to say 😃.

On the other hand what the `product owner` did, or what the `scrum master` was doing - they never told, I never learnt. Middle or top level managers could play **Candy Crush Saga** their entire days and we would not know, because _reporting downwards_ was not a thing... 

But boy they knew every day of mine; there was no chance for experimenting, only "product work".

### 👉 How to fix total surveillance humanely
There are multiple things here:
- Keep stand-ups informal so people are not afraid of them.
- The goal should be informing your peers how they can help you (or you them).
- It should be the norm of managers present to also share their parts in similar details.
- Do not want to know everything! Trust your HR and team leads that they hired and working with the right people!

## By the book 📕
After the initial shock we started to get really productive, features were shipped, stuff got delivered. But we had a secret: 

> It was OK if we did not ship everything on time. We estimated how much `story points` we did and how much is left for the next sprint.

But then a new middle manager came, he said...

> No, no, you can't do that, it's not by the book.

And then we went back to **undercommit** to be on the safe side. Later we figured out again a new way to work it, we loosened some rules again, productivity soared and then another guy came, and we were back at square one...

### 👉 How to fix "by the book" humanely
Well, obviously **don't fix something if it is not broken**. Sometimes I felt `Scrum` was like the **Bible** (or any other similar holy texture): you cherrypick parts based on your beliefs and use it as a club to hit other people with it.

My advice: 

> If the team delivers, the vibe is great, the quality is good... Don't mention the book.

## If you fail two consecutive sprints... 😡
There was a more sinister thing behind not letting `partial stories` go through... And it was a constant source of **fear** and really soured working at the company for many of us. 

> If the team fails two consecutive sprints the middle management would be involved.

In the failed sprints I was involved I never saw them fail because people spent too much time at the #watercooler, or left work way too early. It was usually coming of an _unknown unknown_ or _underestimating_ the size of a task. Also it mostly wasn't a total failure! We shipped 90% of the things!

So what will people do in this case? They commit to much less tasks just to be on the safe side.

### 👉 How to fix failed sprints humanely
Believe me, people are quite embarrassed if they can't deliver what they promised. **No need for drama**. Stop threatening people! And that is without question.

> First you should always try to help and motivate in this case. That is empowering to people.

If a team is repeatedly failing sprints then only investigate causes if you are really ready to spend time on these:
- infrastructure at hand
- potential systemic problems
- state of the codebase
- team dynamics
- team staffing needs (i.e. maybe they are understaffed or they are missing expertise)
- unclear ownership

Again: _no need for drama_, everyone wants to deliver the product and cash in glory and bonuses. Threats like this are counterproductive.

## Hyperproductivity - not a perk but requirement
Okay, so we have learnt how to trick the system so we are super not likely to fail the sprints - we might fail one, but not the other, therefore no investigation needed.

But there was one thing that the consultants promised, and that was **hyperproductivity**: after awhile a team will start delivering more and more story points, showing a constant uphill.

So when things went back to comfortable we were told again:

> Management will be involved if the story points won't increase.

Our stomachs were collectively grabbed by an icy grip: "Did they _really believe_ the marketing trick?". When the ad says the robot toy can speak people don't expect it to hold conversations...

> In the **age of burnout** where everyone constantly has to learn and juggle work-life balance battling performance anxiety or the impostor syndrome the last thing you need is someone non-consensually promising _hyperproductivity_.

So what can you do besides a lasting anxiety? You are still not a fortune-teller to know if there won't be issues along the road, nor you can magically find more time and energy...

Or... You can bloat the stories a bit, so you estimate them with _higher story points_ and deliver more _on paper_...

Everyone "wins" and you get the `Chameleon of Corporation` badge (and pretty little burnout) at the end of the year.

_Actually_, in reality we never faced backlash over this, because of a couple of reasons:
- when you have a new team it requires time to figure out their `average velocity` is
- by the time you figured it months already passed
- and in that long period of time people might left the team, new people might have been hired or the entire team was scrapped and moved to another project, calculating the average impossible

But this does not mean we did not have a totally avoidable unproductive stress over it.

### 👉 How to fix hyperproductivity humanely
Well, you can't require an extra. If it happens, it happens and be happy about it. If you ever spoke with a sport or team psychologist, they would instead ask you: did _you_ facilitate the environment in where talent can reach its potential?

## The root cause of it all
Was **trust issues**. 

Which was quite ironic. 

The main management was in a totally other country, while we were in Eastern Europe. We seemed smart enough to bring in millions of dollars of income for at least quarter of the price of an LA engineer but we were not deemed smart enough to _make our own decisions_ and also not trustworthy enough _not to be watched_.

I think the take-away is **total control is super inefficient**. Take a look at North Korea to see it.