No motivation for Scrum events
Hi all,
I am a software developer working in a team who adopted Scrum a little bit over one year ago.
Two weeks ago I attended a Scrum Master course and successfully completed PSM I. I am now officially the Scrum Master for our team. Before, we used to rotate that role between the devs.
I started thinking about the process and what we do right and wrong. One of the big issues I am facing is the lack of motivation in some team members, regarding the Scrum events.
Every time I sent outlook invites for a Sprint Planning or Retrospective I have to deal with people complaining about the time we spend on those meetings.
Our Planning's time box is set to one hour, which is absolutely not enough. As a start, and to avoid going in too hard, I set it to two hours. Some minutes later our Product Owner requested a talk with me and complained about a( the Planning being just too long and b) the Retrospective being both needless but also too long.
We have 3 week sprints and 2h Retrospectives and in his eyes, spending 2h every three weeks is wasted time we could better spend working instead.
Have you ever had to deal with people (or even Product Owners) who did not want to have a Retrospective or other Scrum events? What did you do? What could you recommend as an action?
Thanks,
Dave
> Our Planning's time box is set to one hour, which is absolutely not enough
You're probably right, but what evidence do you have that it isn't enough?
The acid test is the team's ability to plan and meet a meaningful Sprint Goal, and to deliver an increment of release quality each and every sprint. Can they prove they are doing this?
If they can't, then they have not yet mastered their implementation of Scrum, and hardly seem to be in a position to cut short any of the Scrum events.
We have 3 week sprints and 2h Retrospectives and in his eyes, spending 2h every three weeks is wasted time we could better spend working instead.
Does he have an alternate proposal to review what is going well, what isn't going well, and ways to continually experiment and improve the way that the team and the business work together?
Continuous Improvement is a sign of a healthy Agile organization, and it simply doesn't occur in a vacuum. Allocating a few hours every 3 weeks for the effort seems very small, compared to the potential increase in efficiencies, reduction of waste, and improved communication and collaboration that such discussions may produce.
Regarding the Sprint Ceremonies, now that you are the designated Scrum Master for your team, you need to schedule these Scrum events on a recurring basis. Do not wait for the end of the sprint to send out a new set of meeting invites. A key to Scrum is around developing the "heartbeat" of a sprint. Predictability around the time/day for sprint ceremonies creates a rhythm for the team and the business and sets expectations.
If you continue to get pushback on the Scrum Events, reiterate the benefits that the meeting is designed to achieve, and ask if there are possible alternatives to reaching those benefits. In my experience, even if the team/business has a discussion on this, they inevitably arrive at something that closely resembles what Scrum has already established.
Sometimes people simply need to feel that they are being heard, and guiding them to similar conclusions is a great way to get buy-in. Good luck.
Thank you both for your replies.
Posted By Ian Mitchell on 05 Dec 2016 07:11 PM
You're probably right, but what evidence do you have that it isn't enough?
The acid test is the team's ability to plan and meet a meaningful Sprint Goal, and to deliver an increment of release quality each and every sprint. Can they prove they are doing this?
If they can't, then they have not yet mastered their implementation of Scrum, and hardly seem to be in a position to cut short any of the Scrum events.
The evidence I have is exactly what you state: we can not define any Sprint Goal, the increment's quality is not good enough because the Sprint Backlog often cannot be completed. So yeah, like you said, they are not ready yet to cut short.
Posted By Timothy Baffa on 05 Dec 2016 08:36 PM
Does he have an alternate proposal to review what is going well, what isn't going well, and ways to continually experiment and improve the way that the team and the business work together?
that's the thing, he doesn't. He just does not want to "waste" time for that when we could be working instead. In his opinion it should just be enough to discuss personal matters during coffee breaks and that's it.
Posted By Timothy Baffa on 05 Dec 2016 08:36 PM
Continuous Improvement is a sign of a healthy Agile organization, and it simply doesn't occur in a vacuum. Allocating a few hours every 3 weeks for the effort seems very small, compared to the potential increase in efficiencies, reduction of waste, and improved communication and collaboration that such discussions may produce.
That's exactly what I tried to explain to him. However, in his opinion, I don't understand Scrum (he has not had a single hour of training).
Posted By Timothy Baffa on 05 Dec 2016 08:36 PM
Regarding the Sprint Ceremonies, now that you are the designated Scrum Master for your team, you need to schedule these Scrum events on a recurring basis. Do not wait for the end of the sprint to send out a new set of meeting invites. A key to Scrum is around developing the "heartbeat" of a sprint. Predictability around the time/day for sprint ceremonies creates a rhythm for the team and the business and sets expectations.
That's what I did. Our recurring events were coming to an end due to exchange calendar settings, so I had to schedule new ones, and while at it, I prolonged the Sprint Planning and kept the Retrospective at the same length. That was the trigger for all the discussions.
Posted By Timothy Baffa on 05 Dec 2016 08:36 PM
If you continue to get pushback on the Scrum Events, reiterate the benefits that the meeting is designed to achieve, and ask if there are possible alternatives to reaching those benefits. In my experience, even if the team/business has a discussion on this, they inevitably arrive at something that closely resembles what Scrum has already established.
Sometimes people simply need to feel that they are being heard, and guiding them to similar conclusions is a great way to get buy-in. Good luck.
Thank you. I will do that in the next Retrospective tomorrow. I want to discuss it with the team, gather their opinions on the Scrum Events and explain to them why they are important and not at all wasted time.
just a few ideas:
- team needs to know, even better feel, that the retro is useful. try http://plans-for-retrospectives.com/?id=46 or http://plans-for-retrospectives.com/?id=1. ask their expectation first thing in the retro. then at the end ask again if the expectations were met. in this way you can hopefully engage the team members to design the way they want to work?
- structure the meetings, prepare them, send agenda early enough. a clear output (even better outcome) should be seen. help making the meeting worth it
- emphazise, that is is not a meeting, but a conversation! a good opportunity for you all to meet
- make them fun? aks the team how the meetings can be more fun?
- strict timeboxing for discussions.
- sometimes meeting give the impression of wasted time because there are to many pauses. For example scrum master asks the opion of the team members and nobody wants to start. Have ideas for orders ready. when every member is invited to tell what they think, set an order: "The one with the biggest shoe size starts..."
That's exactly what I tried to explain to him. However, in his opinion, I don't understand Scrum (he has not had a single hour of training).
Quite an odd reply, to insinuate that a better understanding of Scrum is the real issue. Given that situation, I would welcome the opportunity for this Product Owner to "educate" me on my Scrum misunderstanding. I'd be willing to wager that such a conversation would eventually cover typical project management topics (like resource optimization), and wouldn't resemble anything close to Scrum.
I'd also be curious why the Product Owner feels that there isn't any room for improvement in your current processes - surely you don't have everything perfect out of the gate (although this is also a symptomatic fallacy used by the traditional management mindset).
It seems that as the Scrum Master, you need to make very clear to everyone the delineation of responsibility under Scrum:
- The Product Owner is responsible for ensuring that the team works on items most critical and of the highest value to the organization. It is their primary responsibility to make the end-user happy.
- The Development Team is responsible for identifying and developing the technical solution that will meet the needs identified by the product owner. The team also must be very candid and honest about their forecast and what they can complete within the sprint time box. (note: the product owner is out of line for suggesting that the team is spending their time in non-value meetings. It is no longer their job to try and "optimize" the team's bandwidth).
- The Scrum Master is responsible for ensuring that Scrum is followed, and to serve both the Product Owner and the Development Team in making all of their lives easier (improvements, impediment removal, etc).
>...we can not define any Sprint Goal, the increment's quality is not good enough...
If the Scrum Team cannot say what the purpose of their Sprint is, then no-one, including the Product Owner, is in a position to say what time is being wasted.
Who actually wants Scrum to be implemented in this organization, and to see valuable increments of release quality delivered every Sprint?
As a manager, I strongly believe that to be able to motivate & engage with your team, I need to invest in them. Invest in knowing them, understanding their aspirations & help them draw a path to reach their goals. This could, at times, exceed the motivation from compensation. I am using a motivation training from leadership speaker Yossi Ghinsberg. The result from the training is excellent. I do not wish to spend money on such an increase in the level of motivation of my staff.
In this situation As a scrum master I would
a) give a presentation to product owner and team members to bring them on same page so they understand the meaning of scrum, it's events the benefits of events,the rule, each role's responsibility and also give them enough time to understand and ask questions. As a scrum master it's our responsibility to understand (in your case you are certified scrum master) and to ensure your team members understand and enact scrum
b) I would give a different presentation to stakeholders so they understand and it's important to get their involvement in Scrum projects.
Once the basic understanding is established at all levels then it takes patience, persistence and emotional intelligence and other soft skills for this transition
Good Luck!