I don't agree. For us the scrum master is a fixed position who has as a responsibility to advise the teams on how to fix problems with their processes or to help build these processes in the first place. This works very well for us, because the scrum master is explicitly only an adviser.
Meaning I, as a team lead, do not have to do what the scrum master says, but I always have someone experienced with scrum who I can ask when problems arise or when the team wants to change the processes.
1) While I agree that 20 people seems like too large a team in general, I have a fundamental problem with the idea that scrum can determine what size team is right.
What seems to be happening, it appears to me, is that we have a fair idea of how large a meeting can be before it becomes unwieldy, and scrum has a daily meeting as it's fundamental component, so basically decides that for it's fundamental component to be effective there shouldn't be more than 8 people so therefore teams shouldn't be larger than 8 people.
That seems backwards to me.
2) Almost every scrum training usually has a separate scrum master. I do think the idea of a team member being the scrum master makes a lot of sense and would probably alleviate a lot of the concerns.
3) Scrum story points are supposed to reflect end user benefits. A refacorin's benefit will only show up after several sprints. In the meanwhile you hurt your velocity significantly because your refactoring is likely to be 0 points. Now, this actually makes sense to me, but the issue is that in most places management is carefully monitoring velocity and is gonna hold the drop against the team.
To be fair though, I think this is another issue where the real problem is management converting a measurement metric into a target, which basically negates any use it may have as a metric.
My biggest issues with scrum are: 1) A daily standup is ridiculous. It's highly disruptive and gives me the feeling of someone constantly peeking over my shoulder. A better strategy is a simple email when someone has an update, or a blocker to the rest of the team. Very few of my projects are done in a single day, and it's psychologically stressful to join every meeting saying I worked on story A, will continue working on story A for 3-4 days in a row, while the managerial types rattle off a list of meetings they attended, emails they sent, trainings they completed, etc. 2) Sprints are far too inflexible. Each story should basically define a new Sprint for the people involved in that story, which may or may not be longer than originally expected. I don't see the point of having a fixed 2 week period that applies to everyone. Why not just have a weekly or biweekly meeting where you go over everyone's stuff and see where you stand. It's basically a more flexible version of what sprints try to achieve, without the psychological issues created by having to fit things into a Sprint or alternatively having to carry it over into a whole new Sprint. That same meeting can track how many points were earned since the last meeting and you have your velocity being tracked as well.
Retrospectives are great. But they should be included in the same 2 week catch up meeting.
I find scrum tries to create a lot of artificial deadlines, possibly to encourage people to break things into smaller pieces and make regular progress, but I find that's not how people usually work. In my experience people tend to work more in spurts, delivering a ton of features and bug fixes over a couple of days, and then going relatively quiet for the next few days. Not because they aren't working, but because thats just how things usually pan out since software development is a decidedly non linear process.
That’s not my understanding at all. In our org, that’s the role of backlog priorities. Story points are the cost to get there, and are explicitly a tool to estimate relative amounts of effort involved.
If tech debt is to be incurred, it is expected that engineers negotiate that, and that other estimates will change as a result (and/or other tasks be created to track that debt). But then, nearly 100% of the managers in our org are, themselves, engineers or SMEs in the field they are managing, so they have realistic goals and understanding of the sausage-making process. What you’re describing really does sound more to me like a management problem than a process problem.
Story Points represent effort and uncertainty, not business/customer value - those are Business Value Points. Devs are only committing to X story points per sprint. If refactoring is needed, it's built into the story points, or added as it's own task. And as others have said if the Product Owners don't take engineering input on paying down tech debt/infrastructure/internal tooling, then you have a broken company no matter what process you're following.
Scrum.org states[0] A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements.
[0]: https://www.scrum.org/resources/blog/why-do-we-use-story-poi...
According to Jeff Sutherland himself[1], story points are based on team effort and not end-user benefit: Estimates are estimates for the team to get a story done.
[1]: https://www.scruminc.com/story-points-why-are-they-better-th...
As an example, one could consider the various people working on an individual open source project as part of a team. And most successful O/S projects rarely require everyone to meet together at the same time.
I personally strongly prefer small teams (I find even 8 members too large), but arguably certain projects may need bigger teams, and I think they should still be able to practice Agile with the bigger team, which scrum doesn't allow for.
Effort makes a lot more sense, and I particularly like that it tries to incorporate uncertainty as well (I guess that's why they chose story points, to make it vague, since using hours leads to people treating estimates as deadlines instead).
>These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I need to up my game with how to play it - but I wish I could use something else, perhaps kanban.
Spoiler, your Scrum books aren't going to help you figure things out, unless your org actually wants to change. You have your own unique process, but that you have a unique process isn't an issue. The issue is that your management seems to not respect the input of engineering. No process will work the way you want as long as that is true.
Some thoughts, * Most critical, your team is way to big. Should be half as big
* Scrum master should be a team member and rotated along the team. The process should be a result of constant tuning via the Retrospective. The scrum master here, should lose his job.
* Engnineering owns the implementation of the stories, product owners should not be a part of the conversation on how to do something, they only can say 'what'.
* If you can't decide your own points, then again, you have your own process. If you can, and you need to refactor, you need to add points for that.
If you can't do anything to change, then again reading scrum books isn't going to help. You can say, 'this isn't the way your supposed to do this' as much as you want. processes always reflect the organization. Unless the engineering team is an equal to the product team, it won't matter what process you have.