Hacker News Reader

Hacker News

Comment by franze | Hacker News Reader

Full thread

franze

The Scrum manager way

1. Call in a meeting, early in the morning

2. Tell everybody what a good job they are doing.

3. Tell everybody that there is still a lot to do.

4. Tell everybody that "we" can do it.

5. Remind them of the importance of team work.

6. Go through the tickets.

7. Tell the project manager that a ticket for closing Vim is missing.

8. Write a ticket called "As a user I want to exit Vim!" on your own.

8.1. While reminding everybody that this is not the proper process.

9. Discuss new ticket in group.

10. Reword ticket as "As a user I want to be able to open other applications!"

11. Ask who of the team wants to do this.

12. Postpone decision until the next meeting.

View on HN

There is a step somewhere in there where we waste 30 minutes playing "agile poker" and arguing about the number of story points required to close vim.

The whole thing is followed up with a two hour retrospective where we pat ourselves on the back for increasing velocity (due to assigning story points to closing vim).

Bonus points if you then are asked to map that back to actual hours so we can estimate completely unrelated future tasks while simultaneously remembering that we don't estimate in hours.

It saddens me to say, but this is so familiar. Especially working in a big corporate company where they hire scrum masters who just follow the scrum guide.

Scrum has a built in self destruct method - the retrospective. With a little maneuvering, the team should be able to remove most of the annoying things about scrum by using the retrospective. Obviously you can't go scorched earth and drop all the annoying bits at once. But, if scrum is really being followed (I know this is also part of the problem), the retro should allow the team to change the process over time.

This obviously only works when your scrum master is willing to take feedback on scrum processes. Which, with most scrum masters is not the case, you’re essentially telling them they’re doing a bad job, and it usually hurts their ego.

Something is seriously wrong if the Scrum master doesn't take feedback. That goes against the Agile values and principles.

I honestly haven't met many scrum masters who don't just preach the scrum guide. Even if the team is struggling with the way we do Agile, the scrum master will just continue to force the scrum guide onto the team.

What I currently see is that our scrum master has sold the business on the agile way, so if a developer complains about it, there's something wrong with the developer. It's probably just a bad scrum master, but I've met multiple of those.

I found that, being a special time set aside specifically for team arguments about how many angels can dance on the head of a pin, the retrospective tends to produce a much more literal version of self-destruction.

I showed up long after they implemented it, so I'm not sure how they got there, but the most well-functioning Scrum team I ever participated in had effectively designated the nominal Scrum Master as a BDFL. The retrospective then became a shorter sort of town hall meeting where everyone aired their opinions, but, since we had a BDFL, we had no need to burn energy on consensus-building. Sadly, things quickly went to hell after she left and the team reverted to a more traditional consensus-oriented approach.

You can't remove a professional scrum-master who does nothing else in the retrospective as the scrum-master is running the retrospective.

Exactly, and those scrum-masters are usually good at talking and getting the business on their sides. There's literally no way to change those processes without making yourself look bad.

Disagree: the team owns the retrospective, not the Scrum master. If team members aren't happy with what the Scrum master is doing, that should be addressed in the retrospective.

And this is coming from your own personal experience? I've never been in a scrum team where we as developers had any say in what the scrum master was doing. The most we could do was retrospectives with other developers, and try to improve there. However that's rarely enough to make a business work.

I would not call it self destruct, rather reconstruct or adjust. If the way the team uses Scrum isn't effective, then the retrospective can be used to explore issues and adjust the way of working.

You forgot the conversation on the way back from the retrospective about how velocity is a bullshit indicator of actual productivity and we aren't doing agile correctly at this company.

10.5 create a deadline

13. Ask the team what we can do to make sure we don't have to miss the deadline

14. Move the deadline 2 months in the future.

Don't you need a definition of "done"?

User is able to exit VIM by throwing their laptop out the window and vacationing to Cancun.

Can we also have some sort of a scrumish gathering, ASAP, to declare the correct use of the word "definition", because sometimes it seems we use this word arbitrarily.

Reply on news.ycombinator.com