4 ms·

OP here: lots of people have written about problems with Scrum (e.g. https://news.ycombinator.com/item?id=16892307 https://news.ycombinator.com/item?id=16892307

OP here: lots of people have written about problems with Scrum (e.g. https://news.ycombinator.com/item?id=16892307 https://news.ycombinator.com/item?id=16892307 ). I'm trying to take a bit more of a systematic, longer, researched and justified view of things, so any feedback is very welcome!

darahayes 8y ago
OP do you work at my company by any chance? This is scarily accurate.
jacques_chester 8y ago
What I've mostly noticed is that when people show up with cynicism or actual anger towards Agile-with-an-A, perhaps nine times in ten, Scrum was involved (edit: though this might be sample bias, as Scrum is by far the most popular methodology). I'm sure it's working really well for some folks. A large fraction of the magic of any agile system is the folks involved and their familiarity and experience with it. I work for Pivotal, our wheelbarrow is XP with Lean trimmings. I've seen it up close for 4 years in both consulting and large product development and -- summarising -- it works. But no small part of it working is the context. Our context is that we hire carefully and that the entire organisation is interested in, and supportive of, the way we work. It is fantastically easier to do agile well in an environment where it is already done well (which is why we ask our clients to come work in our office). If I had to pick the most destructive part of Scrum, it's the sprint commitment. Yes, it's called forecasts now, but folks are held to it anyhow. All it does is create a dynamic which generates either waste or burnout. Software should be releasable at all times, not once every two weeks. New features should be presented to a Product Manager as they are done done, not according to what is an essentially coincidental cadence chosen because two weeks is easy to mark on a calendar. At Pivotal the closest we came to sprints was setting up a quarterly release cycle for our flagship product, PCF. The first few were a mess and we massively overshot our planned dates several times. We switched to something much closer to our normal way of working: release trains. Every quarter we make a release. If a component product has a feature ready at that time, the feature gets shipped. If it doesn't, it doesn't. And that's that. We already have a lot of our customers who've adopted automation to update their PCF platforms for patches on a rolling basis. My fond secret hope is that one day, we'll be able to drop the quarterly release cycle as well and just ship things when they're ready to ship.
- mikekchar 8y ago
  > If I had to pick the most destructive part of Scrum, it's the sprint commitment. I've organised many XP teams that regularly hit our sprint commitments virtually every time. The times when I've found it problematic to hit sprint commitments were due to the following: - Sprint was too small. 1 week sprints are awesome, but they are extremely difficult to hit. I run 2 week sprints if I can manage to get people to agree. It can also significantly reduce planning overhead. - Stories were too big. Stories should have a median delivery time of about 1-2 days for a 2 week sprint. The occurrence of 5+ day stories should be in the 1:100 range. High risk stories should always be arranged first in the sprint so that even a 5 day story doesn't blow the sprint out of the water. -Stories were ill-defined. Goes together with the previous point. If you have a really high variance on your stories, it's probably because of this. You should have a "backlog grooming" session once every 2 weeks. At that meeting, you go over any new stories in the backlog and any stories that might make it into the sprint commitment. All developers should attend the meeting. At the meeting you decide: Do you understand what the story means? Could you start coding the story today? Should the story be broken up? It helps if project managers are not in this meeting -- they just respond to the feedback after the fact. Only stories that get the thumbs up, make it into the sprint commitment. - Stories did not have acceptance criteria. Similar to the above, but more specific. Everybody might feel they understand what to do, but if you can't answer the question "How do I know when it is done?" then it isn't a story. In the above cases, you can fairly easily fix the problems and still have sprint commitments. I have also been in some situations where I think sprint commitments didn't match the team. For a variety of reasons, I really like sprint commitments, but it is a bad idea to stick to it if it's not going to work. Here are some situations where I've had problems: - Developers had many disagreements about how/when to merge code. They would take unpredictable amounts of time to merge code. If pressured to merge in order to hit targets, conflict would eventually erupt in the team. -There was a young team that did not know how to relax when there is a deadline. Sometimes they merged inappropriate code just because they are afraid to be the one on the critical path. Sometimes the cut corners for the same reason. If you can pair program, it can really help with this. In these cases, it's a matter of training the team. It helps if you can keep the team together for a long time and if you have a manager who isolates the team from a certain amount of surrounding politics. But sometimes, for a variety of different reasons, it isn't going to work. It's not bad to reach for something else at that point. Sprint commitments can be really beneficial in my experience, but it's one of those things that is the result of having a high functioning team. It's not necessarily the way to make a high functioning team.
ysavir 8y ago
Here's my one piece of feedback: It's all well and good if you look at places where Scrum has failed, but if you don't look at places where Scrum has succeeded, and offer an analysis there, the research is meaningless. Currently it feels like you're limiting your scope of research to places where Scrum has failed. Is it any surprise, then, that your research has supported your thesis?

darahayes 8y ago

OP do you work at my company by any chance? This is scarily accurate.

jacques_chester 8y ago

What I've mostly noticed is that when people show up with cynicism or actual anger towards Agile-with-an-A, perhaps nine times in ten, Scrum was involved (edit: though this might be sample bias, as Scrum is by far the most popular methodology). I'm sure it's working really well for some folks. A large fraction of the magic of any agile system is the folks involved and their familiarity and experience with it. I work for Pivotal, our wheelbarrow is XP with Lean trimmings. I've seen it up close for 4 years in both consulting and large product development and -- summarising -- it works. But no small part of it working is the context. Our context is that we hire carefully and that the entire organisation is interested in, and supportive of, the way we work. It is fantastically easier to do agile well in an environment where it is already done well (which is why we ask our clients to come work in our office). If I had to pick the most destructive part of Scrum, it's the sprint commitment. Yes, it's called forecasts now, but folks are held to it anyhow. All it does is create a dynamic which generates either waste or burnout. Software should be releasable at all times, not once every two weeks. New features should be presented to a Product Manager as they are done done, not according to what is an essentially coincidental cadence chosen because two weeks is easy to mark on a calendar. At Pivotal the closest we came to sprints was setting up a quarterly release cycle for our flagship product, PCF. The first few were a mess and we massively overshot our planned dates several times. We switched to something much closer to our normal way of working: release trains. Every quarter we make a release. If a component product has a feature ready at that time, the feature gets shipped. If it doesn't, it doesn't. And that's that. We already have a lot of our customers who've adopted automation to update their PCF platforms for patches on a rolling basis. My fond secret hope is that one day, we'll be able to drop the quarterly release cycle as well and just ship things when they're ready to ship.

mikekchar 8y ago
> If I had to pick the most destructive part of Scrum, it's the sprint commitment. I've organised many XP teams that regularly hit our sprint commitments virtually every time. The times when I've found it problematic to hit sprint commitments were due to the following: - Sprint was too small. 1 week sprints are awesome, but they are extremely difficult to hit. I run 2 week sprints if I can manage to get people to agree. It can also significantly reduce planning overhead. - Stories were too big. Stories should have a median delivery time of about 1-2 days for a 2 week sprint. The occurrence of 5+ day stories should be in the 1:100 range. High risk stories should always be arranged first in the sprint so that even a 5 day story doesn't blow the sprint out of the water. -Stories were ill-defined. Goes together with the previous point. If you have a really high variance on your stories, it's probably because of this. You should have a "backlog grooming" session once every 2 weeks. At that meeting, you go over any new stories in the backlog and any stories that might make it into the sprint commitment. All developers should attend the meeting. At the meeting you decide: Do you understand what the story means? Could you start coding the story today? Should the story be broken up? It helps if project managers are not in this meeting -- they just respond to the feedback after the fact. Only stories that get the thumbs up, make it into the sprint commitment. - Stories did not have acceptance criteria. Similar to the above, but more specific. Everybody might feel they understand what to do, but if you can't answer the question "How do I know when it is done?" then it isn't a story. In the above cases, you can fairly easily fix the problems and still have sprint commitments. I have also been in some situations where I think sprint commitments didn't match the team. For a variety of reasons, I really like sprint commitments, but it is a bad idea to stick to it if it's not going to work. Here are some situations where I've had problems: - Developers had many disagreements about how/when to merge code. They would take unpredictable amounts of time to merge code. If pressured to merge in order to hit targets, conflict would eventually erupt in the team. -There was a young team that did not know how to relax when there is a deadline. Sometimes they merged inappropriate code just because they are afraid to be the one on the critical path. Sometimes the cut corners for the same reason. If you can pair program, it can really help with this. In these cases, it's a matter of training the team. It helps if you can keep the team together for a long time and if you have a manager who isolates the team from a certain amount of surrounding politics. But sometimes, for a variety of different reasons, it isn't going to work. It's not bad to reach for something else at that point. Sprint commitments can be really beneficial in my experience, but it's one of those things that is the result of having a high functioning team. It's not necessarily the way to make a high functioning team.

ysavir 8y ago

Here's my one piece of feedback: It's all well and good if you look at places where Scrum has failed, but if you don't look at places where Scrum has succeeded, and offer an analysis there, the research is meaningless. Currently it feels like you're limiting your scope of research to places where Scrum has failed. Is it any surprise, then, that your research has supported your thesis?