A main idea of scrum is to have a self-organized team which works independently to reach the goals defined for the sprint. So the team should be able to work without control or pressure of a team leader or product owner. As scrum master, project leader or team leader you have to respect this main scrum idea and take care of the way you lead your team.

Why do I write about this topic and why do I have chosen the very controversial title for the article? Because the fact that I have seen the opposite in projects. Sometimes the project leader uses the scrum tools to control the team members. Of course this is incorrect and shows that the project leader did not understand scrum ore moreover did not understand his role as project leader. But on the other hand, even if the project leader does everything right, the scrum team sometimes feel like they are controlled and pushed to reach the goals. This can be especially seen in teams which are new to scrum.

 
Project events vs. project impediments

If the scrum process creates a feeling of pressure and control, the process is used in a wrong way. The goal of the scrum tools and techniques are to provide developers an environment in which they can work independent and efficiently. Scrum is used to see disturbing events and act before they become project issues.

This can be explained by using an event-action approach. At first you have project events. Later on they can result in project impediments. So, to avoid impediments, you have to see such events and act accordingly. But you cannot and will not control you development team all day. You have to go a harder but at the end more efficient way: You need to gain the trust of the team!

If the developers trust you, they will communicate all important project events. This will only work if you do the hard work and solve the impediments which result on these events on your own. Never ever punish the messenger of bad news. Nobody will tell you about issues if, at the end, the messenger itself has to solve the issue.

Let’s look at an example: Someone of you team has to work few days in another high-priority project. As he gets this information from his boss he informs you immediately. But maybe you have a bad day and answer: “At the start of the sprint you have done a commitment for the goals. So if you now want to work on another project you should find a way how you can reach these goals”. So you punish the messenger of bad news and create pressure to let him solve an issue which is not his fault and cannot be solved by him. Maybe, as result, the next time such an event happen nobody will communicate it. And during the review you will hear that some goals are not reached because team members were withdrawn few days for other projects. Of course you don’t want to create such a project setting. Therefore you have to react in another way. If someone tells you such project events which may result in project impediments, you have to try to solve them. Of course you can and should involve your team in such decisions but you cannot expect that the team will itself solve these issues. So maybe you talk with the project leader who needs the developer for the other project if it is possible to move the timelines a little bit. Or you suggest within the next daily to reduce the feature set of the sprint, increase sprint timelines or ask if it would help if you find someone who can help out in the project. In summary, always keep one thing in mind: It is your work to solve projects issues and impediments. Of course you can ask your development team to help you, but a project issue should never result in a team problem.

 
Too much transparency

I have seen another interesting point in some teams, especially if they are new in the scrum process. The transparency of the scrum development process creates a feeling of inspection. Let’s explain this issue with a little example: the burndown chart. If you use the burndown chart in the right way, you will show to everyone that you team is working well and creates continuous results. For example you can have a chart which shows the remaining number of tasks.

On the other hand, if you visualize too many details, you team members can get under pressure. For example if you show a graph with the remaining tasks, the planned number of tasks per day and the resulting final date. In this case you will not only show the work done by the team, you will evaluate it at the same time. Everyone who looks at the task board will immediately see whenever the development team is behind the timeline. This can get even worse: What if you create this chart for every single developer? Then you and everyone who looks at these charts can compare the performance of all team members in an unfair way. It is unfair because the comparison of two lines will not show the real performance of a team member. I have chosen this extreme example because unfortunately I have seen this in a project. And I talked to the people in this project and believe me, they are not happy to work in this project.

In summary you should find the balance between too little and too much transparency. Transparency is important to show the status of the project and also to appreciate the team performance by visualize the progress to everyone. But on the other hand, too much transparency may create pressure or the feeling of external control. Please always respect the following fact: Your team is a team. Show the work and achievements always summarized as team successes. You should not highlight a single person and you should never ever denigrate the work of a single person.

 
Summary

The scrum tools can be used to push and control people. Of course this is not the goal but you should always have in mind that all tools can have negative impacts. And even if something like a burndown chart looks nice to you, it may create a feeling of control in your team. So be careful if you introduce new tools and don’t introduce them on your own. Always speak with your team and decide together which tools you want to use in which way.