As a mentor of two new Scrum Masters working in teams with little to no knowledge of Scrum, I often face challenging questions. My usual reaction is not to give them a direct answer at first.
During one of the lectures, an Agile coach emphasised having a 2-week Sprint. Perhaps his speech was very effective. Perhaps there are some misunderstandings.
A mentee who had been working in a team that runs a 4-week Sprint asked me whether he should ask the team to change to a 2-week Sprint. I asked him why he wanted to change to a 2-week Sprint.
He thought his team was slow compared with the other teams running a 2-week Sprint. “There are often Product Backlog Items like this one,” he continued, and showed me a Product Backlog Item that contained a title and content with only connectives, with no context inside, making the Product Backlog Item clueless.
“Our Sprint length is long, and the Business Analysts often prepare such a “dummy” Product Backlog Item to occupy the capacity of the Sprint Backlog,” he added.
I finally realised the mentee’s real problem. Then I asked him what would happen if the team changed to a 2-week Sprint. Would those “dummy” Product Backlog Items disappear?
“No,” he replied after a moment of silence. I asked what the developers would do then. He said they would voice out and ask for more information on the Product Backlog Item.
“Does a 2-week Sprint really matter?” I asked. After another moment of silence, he realised the answer.
The timetable of the Scrum Events in a Scrum Team I was working for in 2018.
Under a normal and non-urgent situation, when people face a problem. They first investigate the cause of the problem. Then they find a list of possible solutions and try if they can solve the problem. Finally, they make the decision.
However, in some situations, especially urgent or severe ones, some people are too rushed to find a solution. The first (and quick) solution they come up with is usually wrong. They often forget to consider the root cause of the problem. They may then hastily select a solution, possibly choosing a random approach or the latest method they just learned, without considering the root cause of the problem.
As a mentor, first of all, don’t offer an answer immediately. Be careful not to make the same mistake the mentees might make by assuming that their suggested solution addresses the actual problem. Keep asking them to elaborate more until you’ve realised the actual problem. Don’t offer them a solution directly. As Scrum Masters (-to-be), they should be rational and capable to find the solution themselves. This is also an act of self-managing and empowerment.