Achieving Team Agile is Really not as Easy as you Think

Agile Transformation usually includes 3 levels: Team Agile, Product Agile, and Organization Agile. Team Agile is often considered the first and fundamental step in Agile Transformation, however, many scrum masters typically have an unfriendly experience when supporting Team Agile:

• Strong resistance from the team
• No matter how well the team performed when the scrum master is involved, as soon as the scrum master goes away, the team will be thrown into confusion and even go back to its former self

In fact, what can be left in the team when the scrum master goes away is what they really acknowledge.

Source: Freepik

1. The Team Doesn't Think the Scrum Master is Treating Them Like Living Soul

Think about it, was the scrum master ever like a teacher passing on the knowledge of Agile, and asking the "students" must do something and maintain a good formation?

• The Plan Meeting should go like this...
• The estimation should be...
• The Iteration Review Meeting should ...
• The Sprint Retrospective Meeting should be...

However, there is nothing wrong with excellent Agile practices, the problem is how you get team members to adopt them.

You may like to ask everyone to follow your instruction like a robot, or you would like to try the followings:

• Organize a workshop to discuss current issues with the team. The scrum master is responsible for leading the workshop and providing a structured framework for discussion, where ideas are put forward by team members and conclusions are drawn by both sides. If the team meets the bottleneck or needs additional knowledge, the scrum master could provide help and explanation, but always keep in mind, the scrum master's opinion is for reference only and should not be forced. The action plan made this way is co-created by everyone, so the team will buy into it and the executive outcome will be better.
• Tell every team member that no matter what conclusions are drawn, the action plan is just an attempt. Make an appointment and collect everyone's feedback once the time is up, keep going if it's effective, otherwise make some adjustments. In this way, team members will not have too much mental burden and will be more willing to embrace change and be brave enough to try. After all, they are able to make up for regrets.

Source: Freepik

2. One-Sided Solution from the Scrum Master may not be Suitable for Teams

Some teams seem to be insensitive to the "creation", they just tell their scrum master: "Just arrange the schedule, we'll do whatever you want!" Then they will wait passively until some instruction got. They don't want to spend time actively learning and thinking about how Agile methodology is more effective, they'd rather spend their time typing code. So when they meet an arrangement that they don't like, they just muddle through and then do whatever they want. In this way, programmers call themselves "practical schools", and scrum masters properly become "theoretical schools".

Therefore, the scrum master has to let the team know that they are very willing to discuss with every team member, and most importantly, the team also wants to spend time discussing together. Both the scrum master and the team have the same purpose: to enable everyone to work better.

3. The Agile Practice is Disregarded

There are some scenarios about the Agile practice:

• The scrum master says Agile is about delivering more valuable software as soon as possible, but the team says "It's not my business. We just do what the sales department want, the value is their concern ".

So if the development department and the sales department can not form a community of interest and still uphold the community of interest, Agile can't work well.

• The scrum master says the stand meeting is supposed to be held every day for the convenience of identifying obstacles in time and accomplishing the iteration goals. But the team says "That's all up to the leaders, I'm just responsible for keeping myself busy."

If individual performance is not linked to team performance, no one will care about the overall situation.

• The scrum master says to schedule a demo for each iteration to collect feedback from the sales department and make adjustments timely. But the team says "This is not good, right? We have to redone once they offer proposals, which is asking for trouble. I would rather do UAT for the sales department before release so that they won't offer too many proposals due to the pressure of the launch time".

So if the development staffs are not responsible for the sales result of the software in terms of appraisal, how will they be motivated to care if the software is the users really want?

Source: Freepik

4. Teams are Overburdened with Knowledge

There is really a lot of knowledge about Agile practices. Too many changes in one breath will not only overwhelm the team members but also discourage everyone's desire to change.

You may consider making only one or two changes at a time, and encourage or celebrate whenever there is some simple progress to boost everyone's confidence while guiding them to make further changes.

5. Benefit Redistribution

No matter if you admit it or not, Agile's transparency and deep involvement of all employees objectively brings about a redistribution of benefits. As a result, those who used to take advantage of information asymmetry to occupy important positions feel that they are about to be decentralized, and their sense of value and even occupational security will be weakened or threatened. However, they couldn't say it explicitly, so they may resist, obstruct or even challenge the new Agile methodology in all kinds of overt and covert forms.

Therefore, it is very important for scrum masters to properly help the affected partners adapt to the new way of working as soon as possible and solve their worries. This work is full of challenges and it will bring a great deal of emotional reaction most of the time. However, this is a future trend, although he may not be able to figure it out in a short period of time, after all, the mental model of so many years can't be changed easily.

Source: Freepik

6. Conclusion

Agile transformation is a very complex matter, and most companies have varying degrees of historical burden. Agile transformation cannot be achieved by just superficially implementing some proven Agile practices. While it is true that the implementation of Agile practices can bring some effect, in a short period of time, if the scenarios described above are not well addressed, sooner or later it will bounce back.

Therefore, the implementation of the Agile methodology is just the beginning. The Agile methodology can solve some problems immediately, however, the main purpose for it is to expose more issues. Scrum masters need to analyze these issues to find the hidden systemic problems (even organizational problems), and then go to a higher level to promote problem-solving. Next, come back to supervise the team and continue to make adjustments, and so on and so forth.