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 pointswe 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 velocityis - 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.
Latest comments (3)
I enjoyed reading your story!
Micromanagement and lack of transparency can get really disgusting in some companies. A lot of companies also misunderstand Agile/Scrum and try to implement it without following its purpose and fundamental principles, so you get Scrum Masters trying to act like Project Managers.
I offer a mix of Scrum with Agile
The thing is one should not be afraid of customizing it! If things work, if people don't feel that there are wasted times (like we had 3 hour long sprint closing sessions, with retro; retros were never followed up, scrum master got nervous when we suggested to tell how he managed the action items on the standups... different story) then it's all good!
One can make scrum very humane and effective if there are no self-esteem/trust issues.