Top 10 Most Common Mistakes Made When Establishing New Agile Teams
Avoid these 10 common mistakes made by leaders starting new agile teams. People accustomed to waterfall will often fall prey to these 10 common mistakes.
I’ve had the opportunity to train or coach over 100 teams since 2008, which has been incredibly fun and interesting. In the process, I have learned a lot about what works and what doesn’t work.
From getting the team size right to establishing proper backlogs to getting motivated people on the team, I have seen a lot of different patterns for success. And I’ve seen a lot of mistakes with agile teams.
In particular when it comes to teams accustomed to working in traditional or waterfall ways, there are some common challenges that these teams face.
These new agile teams frequently try to solve their challenges using traditional thinking, rather than agile ways of working. It is not malicious, it is just what they know. And that is one of the key mistakes made when establishing agile teams.
Below I have included the most common mistakes made with new agile teams as they move from traditional to agile ways of working. And I have invited some of my agile coaching colleagues to also share what they have seen.
Top 10 Mistakes When Establishing New Agile Teams
#1 — Team is Not a Proper Agile Team
The most frequent mistake that I see with new agile teams is that managers form agile teams based on how they have formed traditional teams. That is, they have a really big team that includes a lot of people who have very small roles (and little commitment).
A recent team I was coaching had 20 people on the team, and only a handful were full time. The managers of the team members wanted them “involved” so that they could learn the new technology. The people on the team were involved in that they were all billing the project code, which ran up the cost.
But they were not focused or working effectively together as a team. So the cost to the project was a lot of people in meetings where not much work was completed, yet significant costs were being incurred.
The idea of throwing lots of people at a project to get them exposed runs counter to agile ways of working. During any one meeting, more than half of the “team members” would be missing because they had other responsibilities.
There are also those teams that have key people that know everything about one component or one business area. And they are the only one that knows everything. So any project that touches that component requires that they be involved.
Little work gets done with big teams and ambiguous responsibilities. There is something called the bystander effect where the presence of more people diminishes the likelihood than anyone feels compelled to act.
Recommendation
Get a true agile team that is between three and nine people, who can be full time dedicated to the project. If there is too much work for 9 people, create 2 teams. If you can’t form smaller teams that have all the skills they need for end-to-end delivery, cross-train aggressively to bridge the gap.
#2 — The New Agile Team Doesn’t Get Agile Training
This mistake made when setting up new agile team mistake is really common. We don’t provide training. After all, agile is so simple we don’t need to train people to understand not only WHAT to do but the WHY behind the process.
People are mindlessly following the routines, answering the 3 questions to the daily standup and then quickly tuning back out because as far as they can tell, it’s just a status meeting for the benefit of someone else.
Sometimes the lack of proper agile training is a conscious choice. We don’t have time for training because we need to get something done quickly. Or, we cannot afford to pay for a trainer or to have people offline for two days.
If you dig into each of these, you can see they are based on a mistaken belief or scarcity thinking. It is especially prevalent in organizations that are closely watching the cost of everything.
Ironically, having new teams thrash for 3 or 4 sprints is pretty costly, as is poor quality solutions and missed deadlines. People overlook the long-term cost of the decision in favor of the short time cost of the training.
Recommendation
My fellow coaches and I stood up over 30 agile teams at Northern Trust over the last 5 years. We saw the best results with 3–4 days of training that included a mix of lecture, generous amounts of hands-on exercises, team building, and opportunities to learn from peers that had already adopted agile.
#3 — Poor Scrum Master or No Scrum Master
It is surprising to me how many organizations want to adopt the Scrum Framework, yet unwilling to pay for a skilled Scrum Master to help them.
That is the bottom line — they don’t understand the role, they underestimate the difficulty it can be to adopt Scrum, and they see savings in not having that role.
This usually takes on one of the following flavors:
- We don’t have any Scrum Master. Is it needed?
- We will have our Project Manager do both the project management role and the Scrum Master role.
- We will have the Product Owner also act as the Scrum Master.
- We will have a member of the team act as the Scrum Master for part of their time
I’ve written about the importance of a skillful Scrum Master in other blogs including how difficult it is for project managers to be the Scrum Master and how the Scrum Master is not the Jira Lackey.
There are all kinds of issues that are going to happen when you try to use Scrum without a skillful Scrum Master.
The main outcome is that you probably won’t be using Scrum, it won’t be very agile, and you won’t get any of the business agility benefits you are seeking like flexibility, adaptability, short feedback loops or employee engagement/satisfaction. This particular mistake with agile teams is an easy fix.
Recommendation
If you have a new Scrum Team, I recommend an experienced Scrum Master. I always check to see if the Scrum Master has had training and certification from Scrum.org or Scrum Alliance (PSM or CSM).
I don’t read too much into it if they have it, but it is an easy achievement so I question any practicing Scrum Master who didn’t bother to get that minimum level of training and certification.
Sometimes organizations have a new team and they have a person who has no experience as a Scrum Master who wants to try the role.
I would encourage that approach with a new Scrum Master and a new team so long as 1) that Scrum Master went and got the Scrum Master training and 2) there is an experienced coach there to help them grow into the role.
I would discourage the part time SM or team member who thinks that they can do both.
#4 — The New Agile Team Keeps On Doing Waterfall
Getting people to give up waterfall ways of working is like taking a bone from a dog. This can manifest it in many ways:
- Having Sprints that are essentially waterfall phases — development sprint followed by testing sprint
- Producing Interim (non-software) deliverables like Design documents or testing specifications
- Using Mini-waterfalls within the sprint — We will have 7 days of development followed by 2 days of testing and then a build to move it to the UAT environment for 1 day of testing
It can also be more subtle. One recent team kept bugging me to bring on a business analyst to go gather requirements for them so that they didn’t have to talk to business users.
Or in some organizations, that is the role of the business analyst — they are the go-between. This reinforces those specialist roles and handoffs that are the hallmark of waterfall ways of working.
[See: One More Time What is the Business Analyst Role in Scrum]
Agile Coach Vince Yabut sees this as one of the biggest challenges that new agile teams face:
“Recognizing that the luggage of past practices, behavior, roles, organizational beliefs that were hallmarks and under-currents to traditional SDLC is no longer applicable and transferable when adopting an agile mindset and scrum practice. Shedding that luggage requires courage, faith, patience, and optimism — no small feat.”
Recommendation
The tendency to revert to waterfall ways of thinking and working is strong. I try to draw attention to the differences and especially the ways of thinking.
One technique that I have found helpful is to have the team watch this video and then discuss with each other. The video is “Brief overview of Agile” by Crisp Agile Coach Jimmy Janlen and it contrasts agile with traditional development.
I also use an airplane exercise with the team during training which highlights the challenges with specialization and bottlenecks and helps focus the team on delivering working solutions each sprint.
#5 — Lack of Team Member Commitment and Accountability
One aspect of waterfall ways of working that is particularly difficult for agile teams is the lack of attention to results. In most waterfall teams, tasks are large and ambiguous and they take a long time to complete.
While they are in progress, the team member working on it can make vague statements about progress or give a % complete update.
With agile ways of working, teams work in short cycles, there is clarity and peer pressure to be accountable for results. Teams work together to break big items down into small pieces, they put them into a sprint and then they track them to complete.
Software Development and Agility expert Tom Cagley sees it this way:
“New teams need to adopt the attitude that they need to say what they are going to do and then do it. Breaking work down becomes part of the discipline of getting stories to done and production.”
Recommendation
Help the team make the connection between what they plan in Sprint Planning, and the end of Sprint Review and Retrospective. Help the team to continuously improve my using those meetings to inspect and adapt.
#6 — Managers are Not Trained in Agile
While it may be surprising, there are a lot of managers who want me to ‘go make their teams agile’ yet don’t understand agile and Scrum and aren’t interested in learning.
Or they (mistakenly) believe that they get it. And they usually don’t. Most believe that even if they don’t understand it, agile will somehow magically improve productivity or allow people to get more work done.
Scott Adams brought attention to this nearly 15 years ago in this Dilbert Post.
In one particular team I was asked to coach, everything in the environment was set up the exact opposite of what you would do if you wanted agility.
Every time I spoke with the manager who hired me she said, “I know you are not supposed to do this in agile, but…” After a while it was so comical that I knew what was coming.
“I know you aren’t supposed to do this in agile, but…”
The manager had a team project manager having twice a week status meetings. She was concerned about documentation so she hired a project administrator and that administrator took notes during the daily standup and emailed them out to everyone.
The manager was herself too busy to spend any time helping the team unless there was a crisis. She placed a big focus on everyone being on the project because she wanted everyone in her department to be billable.
Recommendation
It can be a tough sell but managers need to have training. Many times I am told, we can’t spare more than 2 hours for agile training. Which isn’t much time to learn anything. I am also told that the managers already understand agile. Which is often not the case.
I recently took the Professional Agile Leadership course from Scrum.org and that would be a great investment for most managers. The Certified Agile Leadership course from Scrum Alliance would also be great.
#7 — Focus on Resource Utilization Rather Than Satisfying the Customer
The first Agile Principle is to “Satisfy the customer with working software”. You would think organizations seeking agility would find ways to focus on measuring that. Rather, most focus their energy on keeping everyone busy.
In a recent engagement that had a team that was far too big, I could not remove people from the team. It seems that the generous project budget was being used to pay for people who otherwise might be at risk of losing their position.
There was no other project that they could bill their time to. Sigh. So, to keep everyone fully utilized, it was necessary to have an agile team of 13 people.
Though they were fully utilized, that “team” of 13 people were not great at building software that satisfied the customer. In fact, a team of half that size would have easily outperformed this team. [See: Best Agile Team Size for High Performance] This is a big mistake for an agile team.
Recommendation
Get the smallest possible team that can get the job done. Do your best to negotiate a team of 6 or 7, or less, rather than something over 7.
In organizations where keeping everyone busy is the priority, it may make sense to step back and understand what they are optimizing around. My guess that a focus on resource utilization is a way to optimize cost.
#8 Not Addressing Organizational Reporting Lines
Sometimes organizations pull together a true cross functional team with skills such as business analysis, front end development, back-end development and testing. That cross-functional team is expected to self-organize and complete the work of the project.
This all sounds great until you realize that each team member is getting direction and priorities from their department manager.
Department managers feel threatened that you have taken “their resource” and power and control issues are triggered. Managers will sometimes try to influence the team or worse, micromanage their employee.
Recommendation
The best solution to this is to remove organizational silos and have team members for one team have one department manager.
#9 Failure to Address Work Entry Problems
In many organizations, there is a surge of hidden work that gets done by virtue of unseen networks. People find ways of getting their own needs met by working through back channels.
Or in the case of a client that I know, there is a lot of what they call drive-by requests or shoulder tapping.
In fact, shoulder tapping is not only acceptable, the employee is expected to drop everything and address the request behind the shoulder tap immediately. Can you imagine the impact of this practice on team productivity and predictability?
Other organizations find that emergencies and firefighting are rampant. Interruptions are the norm. Team members drop everything to respond to the latest crisis.
In still other organizations, priorities are unclear or they keep changing. Team members learn to respond to whoever shouts the loudest (WSL) or whoever shouted last.
Recommendation
Establish a clear work entry process. If using Scrum, all requests for new work should be prioritized by the Product Owner. Agile Coach Tom Cagley has written extensively about the work entry including this article on the importance of saying no.
#10 Constantly Changing Direction on the Team
I’ve also seen organizations that struggle with decisiveness. They change priorities, they waver between Scrum and Kanban, or they keep shifting direction.
There is no clear strategic direction. Organizational politics come into play and the new agile team bears the brunt of the organizational dysfunction.
Recommendation
Agile and Scrum will often make obvious the weaknesses in the organization. So applying Scrum will make your issues public. It may look like a Scrum Team problem but the reality is that it is an organizational impediment.
It takes courage to those impediments on. As agility expert of Spotify fame Henrik Kniberg once quipped, “If your organization doesn’t like truth and honesty, it probably won’t like agile”.
If your organization doesn’t like truth and honesty, it probably won’t like agile.
— Henrik Kniberg, The Product Owner Role in a Nutshell (video)
Are there other Mistakes made in setting up Agile Teams?
This list of 10 items represents what I have seen. What do you think — have you seen other mistakes made with new agile teams that I have missed? Please weigh in with your comments.
⭐️Thank you for reading. If you enjoyed this article, feel free to hit that clap button 👏 to help others find it.
Let’s connect on Twitter or find me professionally in Linkedin.
Leave a comment below if you have any questions, and subscribe to receive the latest updates in Agile and Scrum.
Anthony Mersino is the founder of Vitality Chicago, an Agile Training and Coaching firm devoted to helping Teams THRIVE and Organizations TRANSFORM. He is also the author of two books, Agile Project Management, and Emotional Intelligence for Project Managers.