Why your 'Agile'Team is Struggling (and how to Fix It)

Cartoonish Image of a computer catching fire.
If you follow the basics, you can prevent fires in the office. Image from Midjourney v7

I have worked in the Agile Reformation for over a decade. Along the way, I have had plenty of failures and a few noteworthy successes.  Each opportunity has been different and given me unique challenges, but I have learned plenty of skills along the way, and I am a better leader than when I first began this journey. I returned to work nearly two months ago and am now working with a new team. Like many teams, they think they are being agile, but they are struggling. Today, I am reviewing a few basics that every scrum master or coach must understand to ensure a new team succeeds.

Bruce Tuckman created a useful model for team formation. First, there is the forming stage, where people get to know one another. Next, the team goes through a high-conflict phase known as storming. People are learning where they fit and how they will manage conflict. It is a difficult phase where everyone is jockeying for position. As a leader, you need to be patient because it often looks like unnecessary conflict, and people do not do their jobs. I communicate expectations firmly and tell the team to figure out how to meet them. I also spend plenty of time listening to people, learning their pain points, and figuring out how I can help.

I am also looking for 'glue' people who can help the team get better and become leaders in their own right. Next comes the norming phase, where they learn to have healthy conflict and get work done. The bridge from storming to norming is significant, and some teams never reach it. At this point, it is up to leaders to ask difficult questions and set expectations for what the team wants to accomplish. Finally, there is the performing phase. The team looks like the champions they are. Other teams look to them for guidance, and they will be an adaptable group that executes count on to get things done.

The Tuckman model is a useful way to observe a team's behavior and its maturity. Some teams will never reach the norming or performing stages, but it is incumbent on coaches and scrum masters to get individuals working together to advance along this path.

The next thing teams face is unclear agreements about work. Understanding what finished work looks like can be ambiguous. Standards of quality can vary among people, and often those differences fuel conflict. This is why every team should have a written working agreement. Working agreements define how the team behaves. It includes meeting times, expectations, a clear definition of done, and the team's values. A team agreement also helps the team understand how to navigate the uncertainty of storming and move more toward norming. It can be as vague or detailed as necessary, but it belongs to the team. They make the rules and help guide any necessary changes. I work at a shop that uses SAFe, so I review the working agreement at the start of every PI. If we need something fixed sooner, we can do it during the retrospective. As with an agile project, a working agreement is never finished; it is a living document that the team aims to follow.

Finally, as a coach and scrum master, do not shout orders and expect obedience. Instead, state intentions and then find out if the team can accomplish them. Listen to their concerns and encourage them to share their own leadership styles. Being a manager is the hardest job in business because you are responsible for success, but you must motivate others to accomplish it. A good leader does not guarantee success, but a bad one is a common ingredient for failure. I have spent many years in leadership roles, guiding teams and helping them do their best.

I remember spending five years at an organization attempting to get them to be more agile. I was told by the CIO that I should not try so hard because the executive team was not in a position to change. Six months later, the company destroyed all of its shareholder value and asked to be acquired. I could not change that situation, but I am still proud of the work I did, and it informs me how I can help other teams succeed. The most important thing I have learned since then is that it's never about me. It is always about the success of the people I am serving. If I can do that, my time spent as a professional is worth it.

Until next time.

Edward J Wisniowski

Edward J Wisniowski

Ed Wisniowski is a software development veteran. He specializes in improving organization product ownership, helping developers become better artisans, and attempting to scale agile in organizations.
Sugar Grove, IL