Ok so let's start rough - big part of the problem is with you - You hear, but you don't listen. Your team is telling you clearly what the problems are. You need to address them instead of blaming your team.
To them, Planning is just a waste of time, because we just move overflow into the new Sprint and don't complete the work anyways, so why bother.
Exactly. If you consistently fail to allocate correct amount of time to tasks, and they are consistently underestimated, it has very negative effects:
- Developers feel like they are constantly under pressure.
- "I can't get anything done in time".
- Since the process does not work, they rightfully see it as a waste of time.
Solution: Fix your estimations using combination of:
- Story Points (as a combination of Time and Risk).
- Do not allow tasks into a sprint that are > 55 SP
- Comparative Estimations
- Evidence Based Scheduling
As a base for this, you absolutely need to track time it actually took to finish previous tasks, this includes testing, writing documentation, writing tests, end user training, integration efforts, deployment. etc.
Once you have a total time for a given task, you can base expected time on those previous tasks.
Ask every member if the task given to them feels more complicated or easier than the selection of previous tasks, adjust number of allocated tasks based on that.
If you haven't used SP before, my advice is to start with 1h of real honest to god work = 5SP as a guideline. Keep in mind that in usual development environment, you'll get maybe 6 of those per day, so 30SP / day max. Never ever allow for a task that takes more than 2 days to get on the board. Ideally, in my experience, you should have 2 tasks per day.
If you don't do Planning correctly, rest of your Scrum activities will look like a waste of time (including Planning).
During Retrospective I can just feel that they want to say "Stop doing Scrum". One person does, but the others are silent and I have to deal with this every time.
Reminds me of
Daily beatings will continue until morale improves! and two of the past jobs. If you don't remove impediments, then they are correct that this is a waste of time.
Again, listen to what people are actually saying. If the complaints raised during the retrospective are not addressed, why bother doing them at all?
- Consider Six Thinking Hats techniques to improve the communication.
- Reduce the time spent on Retrospective, 30 mins maximum.
- Ensure that complaints raised during the Retrospective are addressed before the next one.
Daily Scrum is again just a waste of time for them because none of them bothers to talk and plan the day. They just state "I worked on task X yesterday and will work on that again today." And most of the time they just joke around until I get more stern.
Sounds like you have two problems here: SCRUM meetings are too long, and your planning and task creation sucks.
Both can make sound like a scrum meeting is a waste of time.
For the SCRUM length:
- Try 15 mins maximum.
- Try everyone standing up.
- Fixed formula:
- What have you been doing yesterday.
- What are you planning today.
- What your team members (not you!) should know about the task, how it'll affect them.
- Don't bother with impediments if you're not going to address them.
This is a second evidence that your planning impairs your situation - if you have nothing specific to report, that means usually the task is too big and all you could say was: I was working on it.
- Break tasks down into the bullet points.
- Ensure tasks are small enough to take less than a day. Ideally, IMO, task should last ~3h and be equivalent of around 13 SP, so you can do 2 per day in most conditions.
Dealing with the team
Today the person who's always against me told me to stop saying "They said this is what they committed to for this Sprint" because, in his words, "We never complete a Sprint. We just move in tasks and take in new ones in the next Sprint to fill up a quota. We do KanBan in reality. So stop saying that."
He's right. You are wrong. You are doing bastardized SCRUM and/or variation on Kanban. Not their fault at all.
I understand why he says this, but he doesn't seem to realize that this is how it is because him and everybody else on the team don't care.
I don't think you understand at all. They might be caring less than they used to before, however blaming them not only will not improve anything, it might just make a situation worse. If it was rock bottom, they might actually start digging.
They just do work instead of dealing with impediments.
And here I thought doing work is what their job was all about. I wonder who was supposed to be dealing with impediments.... oh right. A Scrum Master. It's your job. They tell you what's wrong. You fix it. Not the other way around.
This is probably why you have so much problems in the Retrospective.
How can I make them see that joking around and circle jerking during these meetings costs the company a lot of money?
Stop the useless meetings and they'll instead joke around watercooler.
Also see the paragraph about beatings improving morale. If they are using humor as a defense mechanism, you have some serious problems sir!
Get in on a joke - as in work with your team, not against it. (Who the fuuuuuuck cares about the company's money? Are you a shareholder now?)
Your bad planning is making other parts of SCRUM fail, and everyone who participates miserable. They see that nothing changes, nothing is addressed, and their complaints not heard.
Improve your planning, and you'll improve the flow and morale.
Do your job removing impediments and your team will progress faster. Ask them what they feel you should do to help them.
Most importantly: Listen to your people. They already told you (and me) what's the problem.