How do you deal with people that think Scrum is a waste of time
Dear All.
About 2 months I've been named the ScrumMaster of a team of 6 people. I since struggle to find ways to improve the agile process and help my colleagues to better organize their work.
First, they all think that Scrum is nothing that a lost of time. To quote one of my colleagues "We loose time with all these meetings and the code does not write by itself".
We commonly agreed to have a daily standup meeting in the morning. I noticed they feel forced to attend. Even if I told them that the main purpose of the meeting is to inform the rest of the team about the status of the sprint so that we can make adjustments, they see it like a session where they report everything to me.
They think everyone knows exactly what needs to be done and there is no need for any kind of meetings. All my colleagues are seniors (they have over 15 years experience in SW Development). On the other hand, I am 25 and joined the company about 1 year ago, hence the lack of authority (or let's say it professional respect) among them.
Planning sessions? Sprint restrospectives? No way they would agree.
I could "force" them to attend to retrospective meetings as I have the full support of the SW Dev Manager, but what's the point if I would be the only one talking?
What do you advise me to do?
Thanks!
Mark
Two things pop in my head when i read your post.
"Respect has to be earned" and "servant leader to a self organizing team"
As a scrum master you are not required to be at the daily scrum; the scrum master only needs to make sure that it happens. Additionally, the daily scrum is not a status meeting. Figure out what the team finds useful in the dailies and do more of it. Figure out what the team doesnt find useful and do less. In general, the team wants to be more forward looking. So more "Today I will be..." and less "yesterday I".
As a scrum master you should identify when the team is talking to you during the dailies and let them know that they should be instead speaking to the development team. Additionally you may find it helpful to attend but not speak (this could take a lot of self control) and only bring up suggestions for change at the retrospectives or in an email sometime after the daily ends.
> I since struggle to find ways to improve the agile process and help my colleagues to better organize their work.
Identify specific problems and inefficiencies you are trying to improve on. This will make the value of the change more visible to everyone.
Presumably Scrum is being introduced to solve a problem. Are the team producing regular increments of value? If they aren't then you need to do two things:
1) Find out whether or not Product Ownership is clear and is exerting good pull. If Product Ownership is weak, then you or your own managers need to solve that problem first.
2) Next, ask the team for their solution. What is their plan for delivering regular increments of value to the Product Owner, if they aren't intending to follow Scrum?
If these matters are already sorted out, and value is indeed being delivered satisfactorily on an ongoing basis, then the focus should shift to optimization. You need to start gathering metrics, and ask the team how they plan to make further improvements. If they aren't doing Scrum, what other method are they intending to use so they can inspect and adapt?
Hi Mark,
Just wondering how the situation is going for you now, and how you were able to overcome any of the problems. I am advocating for Scrum now but am receiving the same types of responses.
Thanks,
Steve
They are probably right, but can they suggest a better way of dealing with team work? If we are working individually and works get tossed over the fence, we probably do not need to meet that often.
I would probably send the whole team to Professional Scrum Foundations course to get them understand the values behind each of these meetings/events.
It sounds to me that the decision to use Scrum was made by management. That would be the perfect recipe for disaster IMO.
First I would discuss and have the team and stakeholders understand the kind of problems that we want to solve. Are we not delivering enough value, is the product of low quality?
Second, ask the team if they are willing to give Scrum a serious try as a way to help solve these issues. If not, abort.
Third, take a PSF or other agile course as Joshua suggests.
Four, decide working agreement, team collaboration exercises to help build a solid team.
Five, GO!
Hi Mark,
Perhaps the word “scrum” is a bit too confronting for most people. Sometimes I get the feeling that because scrum is so popular, people are trying to find ways to prove that scrum is a waste of time without knowing the underlying value of scrum and what it provides.
I always tell them to forget scrum for a minute and let’s talk purely about software development and management best practices.
- Do we believe in writing unit tests?
- Do we believe in helping each and working together in order to produce better code?
- Do we believe that it’s a waste of time to write detailed documents and eventually build it wrongly and get the blame?
- Do we believe in keeping the communication with our clients short, so that we get feedback earlier and build it correctly?
- Etc. etc.
It’s about the “best practice rules” that are embedded in scrum for us to adapt so that companies are enabled to become more agile.
Cheers, Chee-Hong