I use scrum at work and disagree with some of the points being made here, but I speak entirely from my own experience of about six months working with a team of about ten.
Obsession with points - Nobody on my team cares about points. These are used for the managers to gauge how much work we’ve been getting done, from what I’ve heard. We don’t even really care if it’s 3, 5, 10 points. People pick up what ever seems exciting to them, not by how many points are associated with the story.
Meeting extravaganza - I’ll admit that not everything that everyone else talks about during these meetings are relevant to what I do. I try to keep an open ear in case I hear about something that I can chime in on. These meetings are also only 15 minutes for me, once a day, 4 days a week, with a 1 hour demo and 1 hour planning meeting on Friday. (We do demos and then planning on Friday so that people can dive in immediately on Monday.)
Sprint until your tongue is hanging out - We used to do one week sprints, but we switched to two week sprints. This has been going well for the others, but unwell for me. I tend to get work done within a few days. I don’t know if it’s the fact that the work they’re giving me is trivial or that the others are really slow at getting work done. I suspect a mixture of both.
Oversimplification of development process - To be honest, I think it’s important to Keep It Simple, Stupid.
Creating customer value - I have no thoughts on this since we don’t do it for our scrums.
In short, either my team is doing scrum in a flexible manner and they aren’t taking it too seriously, or this guy is in the absolute worst job surrounded by people who are not using Scrum to their advantage but rather are making it more painful for him to bare.
I think your response highlights one of the issues in basically any post about agile and any of the methodologies within it: they are so poorly defined it’s basically impossible to have a coherent discussion about them. I’ve worked at several places that say they are doing scrum but they seem to pick and choose what they want from scrum. They seem to take any configuration of attributes and bash them together and call it scrum. On top of that, success is so hard to define in software engineering that it’s nearly impossible to have a discussion about what is or is not working.
I agreed with many of the points in this article but I would say the one thing described that I see everywhere I have worked which really grates at me is the “one more thing” problem solving technique. If we just add this one more bit of process we will solve this other problem. It all tends to be very focused and micro-optimized. The source of this, IME, is an organization that thinks itself so agile it doesn’t need process. But then it realizes it actually does need to make sure stuff happens so they add a little process here and there as problems arise rather than stepping back and considering the larger picture. For myself, I try to push OKRs as an alignment tool, how you execute on them I’m completely uninterested in, but based on scoring it will become apparent how well you are doing and you can figure out what needs to happen. When I’m working on a team I’m generally not interested in a lot of the fanfare that comes with scrum or kanban or whatever, but I do think one needs to do some meetings to ensure everyone on the team is aligned.
So, does your team know the principles and believes behind scrum (that is more of a rhetorical question)? It sounds like you’re just doing either whatever is easiest or whatever works (hopefully both) and calling it scrum. To answer your question though, Kanban is an alternative to Scrum. Kanban involves many things, and sometimes people combine them with scrum (generally the visualization aspects), but a strict Kanban approach doesn’t have the roles aspect like Scrum does and there is much less cadenced activities, like sprints. And above all of these is “Agile”, which is also really poorly defined, but hopefully means that you occasionally consider where you are and where you want to go and adjust what you’re doing accordingly. I would say most people are just doing agile with a strong leaning towards scrum with roles like POs and cadenced activities like sprints. But it depends on if you think scrum is a particular thing, like orthodox religions, or if you think it’s just a word that you can pick and choose what you want, like cafeteria Christians. At the very least, scrum started out as a particular thing.
Yep, we are doing both what is easiest and what works. We are flexible like that. We don’t follow things religiously in any way. We switched to two week iterations simply by voting amongst our team - only our manager was involved and he agreed that it would do better for us.
I would say the one thing described that I see everywhere I have worked which really grates at me is the “one more thing” problem solving technique. If we just add this one more bit of process we will solve this other problem.
You’re supposed to prune your process via the retrospective. It’s something I’ve found agile does better than every alternative - at the very least it does attempt to address the issue in a way that alternatives mostly do not.
it realizes it actually does need to make sure stuff happens so they add a little process here and there as problems arise rather than stepping back and considering the larger picture.
I think that’s an accurate characterization of what Agile does. I find it’s a lot more effective than stepping back and considering the larger picture.
I work at a company that (predominantly) uses Scrum to organize development, though some teams have used Kanban. In my experience, Kanban is better for the flow of stories/tickets through the development. However, the sprint rituals around Scrum let other stakeholders (managers, marketing, support, etc.) have a clearer view of what’s going on.
I use scrum at work and disagree with some of the points being made here, but I speak entirely from my own experience of about six months working with a team of about ten.
Obsession with points - Nobody on my team cares about points. These are used for the managers to gauge how much work we’ve been getting done, from what I’ve heard. We don’t even really care if it’s 3, 5, 10 points. People pick up what ever seems exciting to them, not by how many points are associated with the story.
Meeting extravaganza - I’ll admit that not everything that everyone else talks about during these meetings are relevant to what I do. I try to keep an open ear in case I hear about something that I can chime in on. These meetings are also only 15 minutes for me, once a day, 4 days a week, with a 1 hour demo and 1 hour planning meeting on Friday. (We do demos and then planning on Friday so that people can dive in immediately on Monday.)
Sprint until your tongue is hanging out - We used to do one week sprints, but we switched to two week sprints. This has been going well for the others, but unwell for me. I tend to get work done within a few days. I don’t know if it’s the fact that the work they’re giving me is trivial or that the others are really slow at getting work done. I suspect a mixture of both.
Oversimplification of development process - To be honest, I think it’s important to Keep It Simple, Stupid.
Creating customer value - I have no thoughts on this since we don’t do it for our scrums.
In short, either my team is doing scrum in a flexible manner and they aren’t taking it too seriously, or this guy is in the absolute worst job surrounded by people who are not using Scrum to their advantage but rather are making it more painful for him to bare.
I think your response highlights one of the issues in basically any post about agile and any of the methodologies within it: they are so poorly defined it’s basically impossible to have a coherent discussion about them. I’ve worked at several places that say they are doing scrum but they seem to pick and choose what they want from scrum. They seem to take any configuration of attributes and bash them together and call it scrum. On top of that, success is so hard to define in software engineering that it’s nearly impossible to have a discussion about what is or is not working.
I agreed with many of the points in this article but I would say the one thing described that I see everywhere I have worked which really grates at me is the “one more thing” problem solving technique. If we just add this one more bit of process we will solve this other problem. It all tends to be very focused and micro-optimized. The source of this, IME, is an organization that thinks itself so agile it doesn’t need process. But then it realizes it actually does need to make sure stuff happens so they add a little process here and there as problems arise rather than stepping back and considering the larger picture. For myself, I try to push OKRs as an alignment tool, how you execute on them I’m completely uninterested in, but based on scoring it will become apparent how well you are doing and you can figure out what needs to happen. When I’m working on a team I’m generally not interested in a lot of the fanfare that comes with scrum or kanban or whatever, but I do think one needs to do some meetings to ensure everyone on the team is aligned.
That’s exactly what we’re doing.
What alternatives are there to scrum?
So, does your team know the principles and believes behind scrum (that is more of a rhetorical question)? It sounds like you’re just doing either whatever is easiest or whatever works (hopefully both) and calling it scrum. To answer your question though, Kanban is an alternative to Scrum. Kanban involves many things, and sometimes people combine them with scrum (generally the visualization aspects), but a strict Kanban approach doesn’t have the roles aspect like Scrum does and there is much less cadenced activities, like sprints. And above all of these is “Agile”, which is also really poorly defined, but hopefully means that you occasionally consider where you are and where you want to go and adjust what you’re doing accordingly. I would say most people are just doing agile with a strong leaning towards scrum with roles like POs and cadenced activities like sprints. But it depends on if you think scrum is a particular thing, like orthodox religions, or if you think it’s just a word that you can pick and choose what you want, like cafeteria Christians. At the very least, scrum started out as a particular thing.
Yep, we are doing both what is easiest and what works. We are flexible like that. We don’t follow things religiously in any way. We switched to two week iterations simply by voting amongst our team - only our manager was involved and he agreed that it would do better for us.
You’re supposed to prune your process via the retrospective. It’s something I’ve found agile does better than every alternative - at the very least it does attempt to address the issue in a way that alternatives mostly do not.
I think that’s an accurate characterization of what Agile does. I find it’s a lot more effective than stepping back and considering the larger picture.
I work at a company that (predominantly) uses Scrum to organize development, though some teams have used Kanban. In my experience, Kanban is better for the flow of stories/tickets through the development. However, the sprint rituals around Scrum let other stakeholders (managers, marketing, support, etc.) have a clearer view of what’s going on.