4 ms·

sigh I mean, I'm not a huge fan of how Scrum gets done (yeah yeah, True Scotsman) and all that, but I have so many issues with this. Problem #1 "Scrum is vague

sigh I mean, I'm not a huge fan of how Scrum gets done (yeah yeah, True Scotsman) and all that, but I have so many issues with this. Problem #1 "Scrum is vague" - no indication why that's a problem. If scrum claims to be agile, it has to be somewhat vague, because it has to leave room for the retro to lead to actionable change. Problem #2 "The Sprint" - Artificial stopping points aren't a problem. As he mentions, good devs may pick up something new, but speaking as a manager...I don't actually care. I trust the devs to figure out the best use of their time at that point; if it's starting something new, okay, and that will affect our future estimates. If it's working on non-functional stuff ("let me add some better tests around that thing that keeps breaking"), also great. If it's training/learning ("I've always wondered what the hubbub around Rust is..."), also great. And if it's taking a break ("Man, I'm mentally exhausted. I just want some time off"), also great. There is literally no outcome that isn't a positive, because we already got the stuff we wanted to get done, done, and I trust my team to actually determine what is going to be the best use of their time. Problem #3 "The Scrum Master" - I generally agree with this. It's a role, not a position. That said, in especially messed up orgs, the position was 100% warranted, and it truly did help me manage upwards. Problem #4 "Estimates" - Op mentions "workload -> time" as the goal of estimates. No. They aren't. Story points are chosen -specifically- to break that connection. Because the temptation, if we correlate to time, is for stakeholders to say "We need this tomorrow! You said it would be 1 point! 1 point is 1 day, I expect it tomorrow!". The temptation is also to bias our estimates; my estimate for a task that we don't need until 6 months from now is going to be quite a bit different from my estimate that you're pressuring me to deliver in two days (in fact, my definition of what the task -is- might change!). By using story points we break all of that. Estimates don't change due to time pressure (because they aren't based on time), and the team can't be held to a certain time for completing them (because they aren't based on time). Nevertheless, we get something we can use at a higher level to determine if a project is going to be late or not.

pelasaco 5y ago
Interesting. I think the author got it wrong but by totally different reasons, LOL. I really don't like SCRUM, but sounds like the Author got it totally wrong. Problem #1 - Scrum Is Vague: Nope, it can be vague, you can create your own dialect from SCRUM, but you can do SCRUM by the book and it's fine Problem #2 - The “Sprint” : The context switch is a problem, however you can build a feature or a set of features iteratively, in 2 weeks block. It is doable and normally I have to admit you move forward with more confidence because you are able to expose your work sooner to the users (i.e as a beta feature) Problem #3 - The Scrum Master: "In addition to all of their development work, the engineers are now interrupted frequently by the scrum master who is asking when the Java code for the React app will be done.": Nope it will never happen. Scrum Master don't do follow-up on the dev team. SCRUM has well defined cerimonies to introspect the development. At least I never saw or heard of this issue. Problem #4 - Estimates: You don't have to over-engineer it. We size cards to make sure that everyone understood the problem. If I card a card as L and the whole team sized it as S, we discuss to make sure that we are all on the same page. It helps us a lot to map all work to be done in one card Beside that I don't think doing SCRUM you spend more money than necessary.. Normally the SCRUM master is one developer and SCRUM actually can be used to reduce the development costs. It's pretty common to have teams with 1 or 2 senior devs and the rest juniors, forcing the seniors to do coaching and micromanagement from the junior devs...
- lostcolony 5y ago
  They're not different by exclusion. I largely agree with a lot of what you say there. Your reasons just aren't the most glaring issues from my perspective (which isn't a judgement call, just a different perspective).
dblohm7 5y ago
> Story points are chosen -specifically- to break that connection. And yet they are then used for measuring "velocity."
- lostcolony 5y ago
  Yep. Because, in aggregate, they will average out to something. A 5 point story may on average take 5 days. Some 5 point stories will take 2 days. Some will take 10. As our team's collective estimation changes, as the team comp changes, as the product changes, that 5 point story average might start taking 4 days, it might start taking 6 days. We can track that average (and, more importantly, the average points we burn down per sprint). Doing so serves multiple purposes; we can divide the amount of remaining work by that average and know whether, to the best of our knowledge, we will hit a certain date or not. We can also use changes to that average as a reflection point on what could have caused them, and let that affect our process (i.e., the new VP started scheduling a buncha status meetings, and oh look, our velocity dropped). But the point is at no point can that 5 point story actually get held up as being doable in 5 days, even if that's what it equates, on average, to. Because it's an average. Whereas if I told a business stakeholder "it'll take 5 days", you can bet they'll be at my desk on day 6 going "where's my feature?"

pelasaco 5y ago

Interesting. I think the author got it wrong but by totally different reasons, LOL. I really don't like SCRUM, but sounds like the Author got it totally wrong. Problem #1 - Scrum Is Vague: Nope, it can be vague, you can create your own dialect from SCRUM, but you can do SCRUM by the book and it's fine Problem #2 - The “Sprint” : The context switch is a problem, however you can build a feature or a set of features iteratively, in 2 weeks block. It is doable and normally I have to admit you move forward with more confidence because you are able to expose your work sooner to the users (i.e as a beta feature) Problem #3 - The Scrum Master: "In addition to all of their development work, the engineers are now interrupted frequently by the scrum master who is asking when the Java code for the React app will be done.": Nope it will never happen. Scrum Master don't do follow-up on the dev team. SCRUM has well defined cerimonies to introspect the development. At least I never saw or heard of this issue. Problem #4 - Estimates: You don't have to over-engineer it. We size cards to make sure that everyone understood the problem. If I card a card as L and the whole team sized it as S, we discuss to make sure that we are all on the same page. It helps us a lot to map all work to be done in one card Beside that I don't think doing SCRUM you spend more money than necessary.. Normally the SCRUM master is one developer and SCRUM actually can be used to reduce the development costs. It's pretty common to have teams with 1 or 2 senior devs and the rest juniors, forcing the seniors to do coaching and micromanagement from the junior devs...

lostcolony 5y ago
They're not different by exclusion. I largely agree with a lot of what you say there. Your reasons just aren't the most glaring issues from my perspective (which isn't a judgement call, just a different perspective).

dblohm7 5y ago

> Story points are chosen -specifically- to break that connection. And yet they are then used for measuring "velocity."

lostcolony 5y ago
Yep. Because, in aggregate, they will average out to something. A 5 point story may on average take 5 days. Some 5 point stories will take 2 days. Some will take 10. As our team's collective estimation changes, as the team comp changes, as the product changes, that 5 point story average might start taking 4 days, it might start taking 6 days. We can track that average (and, more importantly, the average points we burn down per sprint). Doing so serves multiple purposes; we can divide the amount of remaining work by that average and know whether, to the best of our knowledge, we will hit a certain date or not. We can also use changes to that average as a reflection point on what could have caused them, and let that affect our process (i.e., the new VP started scheduling a buncha status meetings, and oh look, our velocity dropped). But the point is at no point can that 5 point story actually get held up as being doable in 5 days, even if that's what it equates, on average, to. Because it's an average. Whereas if I told a business stakeholder "it'll take 5 days", you can bet they'll be at my desk on day 6 going "where's my feature?"