Ensure psychological safety
The first step to learn is to allow to make mistakes and ensure an environment for openly admitting to being wrong. This psychological safety in both - the team’s and the whole company’s levels is crucial while creating a space where people feel comfortable, are able to ask anything or level something at with no fear of being derided. When do you know you succeed in building this kind of environment? Well, ironically, when a lot more problems and mistakes show up. It might sound ridiculous but the situation with safety after changes usually look worse than before. It can be very misleading as these difficulties and headaches were probably just hidden. And so now we’ve got a chance to face and solve them, and also maybe learn something from them. This approach is even more significant in a complex environment in which we can find good answers only through the experiments.
How to support building this sense of security? First of all, confirm that the uncertainty of a situation exists and it’s necessary to explore solutions together. This way you’ll show that we all depend on one from another and nobody has all the answers or is infallible. We don’t need to hide our doubts and protect ourselves from the effects of not meeting the expectations. The uncertainty becomes more acceptable but we still need to provide a proper method of dealing with it like the already mentioned ones - constant asking and collaborative looking for answers, sharing opinions, and observations with each other.
Remember that safety on its own is not enough to build an effective Agile team. It leads to a comfort zone where might appear a problem with motivation. We don’t want to stay there forever. We need accountability gained by setting ambitious goals that will stimulate the development and inspire to reach higher and try harder.
Carefully set the sprint goals
The sprint goal is one of the best Scrum tools to support creativity and flexibility in teamwork. But to exploit its full potential we need to use it properly and consider a few subtle but really important issues. Setting right and clear sprint goals and adding tasks corresponding with it is vital if you want to keep the effectiveness of the work so think twice before adding another item to the sprint backlog. Otherwise, you’ll probably end with an inconsistent list of task or you’ll overload it. Assigning too many tasks for one sprint kills the creativity as team members focus on just getting the job done not looking for some alternatives. It also deprives us of the time stock for unexpected situations which is particularly damaging for teams working in a complex environment. It requires preparing for what is possible to predict and leave the safety margin for the unanticipated circumstances.
The next thing about the sprint goal you need to consider is to refer to it within different points of the sprint - not only during the planning and the review stage of the software development process. This way you’ll check if the works go in the right direction. The goal should be worked out together with Product Owner and sometimes it’s even better to set a few of them to gain space for adding extra tasks.
Keep an eye on improvements
Keeping the constant improvement of the way the team works is advantageous for both quick changes and the ones that require more time to implement. The thing you need to really watch out for is freezing this process which negatively results in a team and a product.
There are 3 kinds of improvement blockades:
- Improvement overload. We can’t introduce all of them at once as it would overwhelm the team and the whole work might be stopped. This will discourage people and lead them to give up on changes even these which were unquestionable from the very beginning. Moreover, even if it would be possible to carry out all improvements, we won’t be able to point out which one of them works well and which don’t. The situation will be incomprehensible and it will be harder to draw appropriate conclusions. So it’s better to limit the number of changes made at the same time, ensure that they won’t interact directly and the team is able to implement them.
- Lack of improvements. This situation is dangerous as it means (assuming the team is engaged), the problem is so huge that the people don’t know what to do with it or they are so self-confident that they do not notice something can be done better. You need to react in both cases and consider that solving these problems might take more than one sprint.
- Constraints related to the uneven development of the team and the whole organization. The team wants to implement improvements but the company is not ready for them or doesn’t want to follow this direction. The Scrum Master presence is essential here to support the discussion and moderate searching for solutions.
Support, not rule
According to Scrum Guide, Scrum Master should coach the Development Team in self-organization and cross-functionality. The implication of this responsibility is to support the teams to let them detect and solve the problems on their own. Scrum Master can help to initiate the changes but he shouldn’t be the person who proposes them. The point is to leave a space for the team and its solutions. There’s a reason why two of the most useful tools for Scrum Master are: silence and asking questions. SM should always think “What happens if I will do nothing” because maybe his actions will take away the opportunity to deal with a problem on the team’s own way? Or maybe it is not even worth to solve it? Remember that the sprint goal is the compass. In the end, we all work to achieve business goals. So if the goal meets the criteria and it still blocks the team works maybe you shouldn’t wait for the daily meeting and take care of right away. The proactive approach of the team is always welcomed and proves the good collaboration inside of it.
Manage the conflicts
It might sound like the perfectly obvious that the teams which cooperate effectively and not wait for manuals, orders and task division will achieve better results. Their joint responsibility and collaboration support work optimization. It also increases engagement, motivation, and satisfaction. And so the members of the best teams never perform completely separately but communicate constantly and settle the works together. It doesn’t mean that they can’t have their own opinion - quite the opposite! They should clearly and assertively communicate their point of view and say “no” if it is needed. The power of the team comes from individuals.
The team building is not only about working but also about understanding each other. The ability to empathize with other members, openness, respect - these values help to deal with difficult situations like conflicts and you may believe it or not but every team needs conflicts to perform successfully. Lack of them might mean a lack of trust or psychological safety.
According to the book “Coaching Agile Teams: A Companion for Scrum Masters” there are 5 levels of conflicts:
- Problem-solving
- Disagreement
- Contest
- Crusade
- World war
The first step IT project manager should take is the analysis of the situation and defining the level of conflict. Try to answer the questions like - What’s the problem? What are its consequences and its influence on the work and the team? What are the possible solutions? What should I do?
When it comes to the first level conflicts remember that:
Everything you do for the group is one less thing they know they can do for themselves
So the best reaction of the Scrum Master, in this case, should be just to do nothing, trust the team, and believe that the members can manage to overcome problems on their own. If the conflict reaches a higher level then it’s the time to offer support. On the third level, you should aim at the problem and keep on the facts. If the situation requires the negotiation - focus on the values. In the more advanced conflicts a diplomatic approach will be necessary but reaching the highest level of it is related to irreversible damages and rebuilding the team is probably impossible.
Leave decision making to the group
Another great challenge for Scrum Master is supporting the decision-making process in the team. A proper moderation in this field requires particular knowledge including traps which can remarkably restrict making the right decisions. We can distinguish 6 types of them:
- Anchoring - we attach too much to the first idea and not consider other possibilities.
- Status quo - we favor the decisions that leave the status quo and block the changes.
- Sunk cost - we maintain in the bad decisions because they have already cost us a lot and we don’t want to waste the work that has been done.
- Confirming evidence - we are not looking for the best idea, we just want to confirm that the decision we’ve made is the right one.
- Framing trap - we focus on the way the problem has been shown and so we don’t see the whole range of possibilities.
- Forecasting - we hold to the previous anticipations while making the decision ignoring present realities.
These traps result from the quality of information or the perspective and you can avoid them in a few simple ways. First - remember the decision is not a single event but a constant process within which different possibilities show up. We need to make an effort, consider, and discuss them. During the process, we should think over the assumptions on which we base our decisions and the criteria we consider to judge if the decision was right or not. Last but not least, if we don’t want to lose the team or other people engaged in the works the decisions have to be made in an honest and fairway.