How to misuse Scrum and destroy Trust and Loyalty in your Dev-Team

Trust and loyalty is a difficult and often underestimated topic when it comes to working in an IT team. A common response I get from developers on that topic is “I get paid for coding. Why do we have to talk about trust and loyalty?”

In my experience, the most common reasons for failures in IT projects originate in people, not technology. There are generally many factors that play a role but what I saw in most cases were people who were failing in working together because of missing trust and bad assumptions.

Let me tell you the true story about a manager who killed a trustful relationship in one single blow: I was leading an engineering team and usually it is my policy to let the team decide which agile framework to work in. At one point we decided to switch from Scrum to Kanban because it was a better fit for the defined requirements. I was surprised when my superior approached me and pushed me to move my team back to Scrum. First I was positively surprised about his interest in our agile workflows and was looking forward to discussing the pros and cons of each approach. When he explained to me why he was insisting on Scrum I was deeply shocked.

In Scrum, the development team commits on a set of user stories which they will deliver until the end of the current iteration. The team is responsible for making sure this commitment is fulfilled, whatever it costs. If the team runs into trouble, this could mean that the team decides to do overtime or work on the weekend so that they can still fulfill their commitment which is a decision they take for themselves and it is really amazing if you see a team doing that. My boss had his own interpretation: We must make sure in every single sprint that the team overcommits so that they voluntarily work overtime every day and even feel good about it because it was their own decision. We can’t do that in Kanban so the developers will work less.

This really hit me hard because I never expected to hear something like that from him.  Up to that day, I believed that we were aligned in our values and strived fo the same goals. Of course, this single event did not destroy our whole relationship but starting this day I was questioning decisions and assignments that were coming from him. The general mood changed from trust to suspicion.

The very fundament of working in a self-organized,  agile setup is trust. The management trusts the team to deliver as much value as possible as fast as possible in a constantly self-reflecting and improving manner. The team trusts the management to communicate early, honestly and on basis of results without interfering in the details of the development process.

If you are a manager and you read this, please take my advice: Don’t try to manipulate the developers in order to squeeze overtime out of them. The damage you are causing with this kind of furtiveness is irreparable. You don’t want your employees to question every decision you make and wonder if this is just another attempt to somehow screw them over. In this atmosphere, the developers will not hesitate to leave your team the moment a better opportunity arises. What you want to build up is a team that stays together even though they get better offers from the competition. A team that invests gladly overtime when it is actually necessary. Developers who proactively step forward to bring up ideas to improve business even if this could cause inconveniences for them. But this can only happen if they believe in you as a leader and as someone who they can trust without a doubt. Never underestimate the impact of trust and loyalty on the success or failure of IT teams.