5 Signs Your Team is Lacking the Agile Mindset
5 Signs Your Team is Lacking the Agile Mindset
When a Scrum Master joins a new team—whether it’s a team new to Scrum or one that has been practicing Scrum for a while—he faces different challenges. Therefore, the duties and focus of the Scrum Master for the first days are different in both cases.
In the first case, where the team is new to Scrum, most of his time and focus is used to teach and coach the team through Scrum. There is often a standard approach to how the team will be introduced to agile then Scrum.
On the other hand, when he joins a team with only some Scrum experience, he needs to act differently. For example, he needs to watch and observe more how the team is acting and how the members are interacting together to see if the agile mindset exists.
Some teams think they are agile by holding the prescribed meetings, but this is not the essence of agile. This type of team needs to be coached to cultivate the agile mindset, regardless of which framework is in practice.
There are many signs that indicate the lack of an agile mindset. Let’s look at some of the common signs that should send a warning signal to the Scrum Master that the team needs to refresh its Scrum and agile knowledge.
1. Knowledge Silos
One of the teams I worked with in the past used to have each developer working on a specific part of the product, and only he knew about it. Whenever a problem happened, they needed to wait for him to fix it.
This can also manifest when certain persons are pre-assigned to specific tasks or user stories during the sprint planning. This behavior prevents the team from working on priorities; rather, each person would work on the part he/she knows without considering the deliverability at the end of the sprint.
Another drawback of such behavior is the lack of team spirit and teamwork, since each one will be working on his/her own island without caring about what happens on the other island.
2. Not Working on Top-Priority User Stories
Teams working on a user story at the bottom or in the middle of the sprint backlog miss the concept of prioritization, and it could also signify a conflict with the product owner or a product owner who is not doing his homework.
Having a prioritized sprint backlog, and of course, a product backlog, is a product owner’s main responsibility to maximize the value delivered each sprint. If a team decides to work on a user story at the bottom, it is either the user stories that are not properly prioritized, or the team needs to understand the importance of picking work based on priority.
3. Separate User Stories for Testing
Having separate user stories only for testing of other user stories, whether these user stories are in the current sprint or a previous one, signifies that the team either doesn’t have a definition of done (DoD) or they don’t understand the meaning of deliverability.
Although it is acceptable to have separate user stories for developing automation tests, it’s a big red flag when you have user stories for “testing” only. In this case, the team needs to be coached to understand what it means to deliver a working product increment at the end of the sprint and to define their Definition of Done.
Without verifying your implementation, you can’t make sure that you are delivering a working software.
4. No Visibility of the Burndown Chart
If the team doesn’t have or doesn’t use the sprint burndown chart, their progress won’t be clear to them. The burndown chart is a tool to show very easily and quickly how focused the team is. The team might feel they are doing a lot of work, but yet they have flat burndown. This means they are not delivering, and they need to regain their focus to deliver more often.
Another misunderstanding that I have experienced with some of the teams is when they ask to have their burndown chart burnt based on tasks finished rather than user stories.
I consider this a bad practice, since it gives them an illusion of achievement, and at the end of the sprint, you might be surprised by having so many tasks finished but not delivered because the whole scope of the user story, including testing it, was not finished.
5. They Estimate Only for the Upcoming Sprint
Although it is one of the basics of agile to a have prioritized, estimated backlog, some teams might estimate only the scope of the upcoming sprint during backlog grooming sessions. Some teams don’t even have these sessions.
Planning only per sprint is dangerous since it doesn’t allow the product owner to anticipate or plan when certain features will be released. In these cases, the Scrum Master will need to teach the team the several levels of agile planning, and the value of having a prioritized estimated backlog for the team and the customer.
These are just some of the signs I have experienced when joining a team that let me know that the team doesn’t yet have an agile mindset, and more education should be the focus. Have you seen signs like this when you’ve joined a team? Do they exist in your current teams?
I would love to get your feedback in the comments below.
Islam Kotb Ismail (PMP, CSM, CSPO) is a senior agile project manager and Scrum Master at Wirecard Technologies GmbH in Munich, Germany.Learn More