5 ms·

My main issue is with Scrum. The problem is that there is no balance. Scrum started off as a way for software consultancies to make sure that the their clients

My main issue is with Scrum. The problem is that there is no balance. Scrum started off as a way for software consultancies to make sure that the their clients could not ask for new features without repercussions. In other words, story points helped to make sure that if they wanted changes, and more stuff, then they would need to pay for it. You do not have this balance within a company, because there is constant pressure to increase velocity. This is why there is so much burnout within the industry. There is constant pressure to do more and to do it faster. To the OP's point, there are so many scam Agile coaches out there, who can't write a fizzbuzz function. I've met many of them. You know what the worst part is? They think they're adding value by just pushing people constantly.

deleted 6y ago
[deleted]
tharkun__ 6y ago
Not really no. In fact consulting companies struggle with agile and story points because virtually no client wants to pay for a number of story points. They will pay for 'man hours' though. As for the pressure to deliver more. That is not new either. Before Story points and velocity they would pressure teams and individuals into estimating lower. "come on that can't take 100 man hours to do. The other team is doing something very similar and thhey say they can do it in 50". That is actually worse if you ask me that story points which are not absolute time units and instead relative sizes. So if one team says the story has 8 SP and another says 5 SP but one team's velocity is 16 while the other team has a velocity of 10 then both teams are saying it takes half the sprint. And the above is exactly what you are saying about bad agile coaches and people finding ways to abuse Agile (which they will probably do with any methodoly you invent even if you do make it less bad than what came before). Case in point about Story points actually being better than man hour estimates. But people still try to abuse them. Now the good part about it is with story points, if you as the Scrum Master fail to convince upper management that no you can't increase velocity into infinity you can simple increase your estimates and your velocity magically goes up. But nobody can come in and say anything against it as long as you still actually deliver because you didn't increase an absolute estimate in hours. You just suddenly have a velocity of 16 like the other team instead of 10 but you still delivered the same actual output.
- Viliam1234 6y ago
  > The other team is doing something very similar and they say they can do it in 50. "And my teenage nephew could do the same thing in PHP in a weekend." (But for some mysterious reason they never fire their developer team and hire the nephew instead.)
lumost 6y ago
You've described the Technical Program Manager role at many companies, and its rebranded "agile coach" form. In my experience, this role has a lot of value in companies with extremely large projects which require tons of cross team co-ordination and priority discussion. The sweet spot is a project/program spanning 5 teams or more. Where sitting in each teams planning meeting is a full-time job and if someone doesn't do it then some critical but small component will be de-prioritized and the whole project will be delayed for a year. Think Rockets, Cars, large hardware projects, large software projects where a dozen teams are required to implement GDPR for their services etc. When this role is placed in a small team of 8-20 engineers it just adds more status update burden to the team, the engineers can more effectively communicate with each other than through a TPM and so the only role the TPM can fill is "pushing". If one can assume that engineers don't choose to slack off whenever someone isn't looking - then pushing just means extra hours, burnout, and missed dates.
Viliam1234 6y ago
> They think they're adding value by just pushing people constantly. Isn't this what traditionally most managers were doing? I remember my first job, decades ago, before agile was a thing, when I had this interaction with my boss constantly: "How long is this new feature going to take?" "Not sure, probably three weeks." "Are you absolutely sure it can't be done in two weeks?" "Well, I guess in the lucky case it might be possible, but..." "Great, so two weeks it is." Then complaining about how I said two weeks and broke my promise, when it actually took two weeks and a half. The only difference is that now you can do it with numbers, so it seems more "scientific", even if all numbers are ultimately just guesses.

deleted 6y ago

[deleted]

tharkun__ 6y ago

Not really no. In fact consulting companies struggle with agile and story points because virtually no client wants to pay for a number of story points. They will pay for 'man hours' though. As for the pressure to deliver more. That is not new either. Before Story points and velocity they would pressure teams and individuals into estimating lower. "come on that can't take 100 man hours to do. The other team is doing something very similar and thhey say they can do it in 50". That is actually worse if you ask me that story points which are not absolute time units and instead relative sizes. So if one team says the story has 8 SP and another says 5 SP but one team's velocity is 16 while the other team has a velocity of 10 then both teams are saying it takes half the sprint. And the above is exactly what you are saying about bad agile coaches and people finding ways to abuse Agile (which they will probably do with any methodoly you invent even if you do make it less bad than what came before). Case in point about Story points actually being better than man hour estimates. But people still try to abuse them. Now the good part about it is with story points, if you as the Scrum Master fail to convince upper management that no you can't increase velocity into infinity you can simple increase your estimates and your velocity magically goes up. But nobody can come in and say anything against it as long as you still actually deliver because you didn't increase an absolute estimate in hours. You just suddenly have a velocity of 16 like the other team instead of 10 but you still delivered the same actual output.

Viliam1234 6y ago
> The other team is doing something very similar and they say they can do it in 50. "And my teenage nephew could do the same thing in PHP in a weekend." (But for some mysterious reason they never fire their developer team and hire the nephew instead.)

lumost 6y ago

You've described the Technical Program Manager role at many companies, and its rebranded "agile coach" form. In my experience, this role has a lot of value in companies with extremely large projects which require tons of cross team co-ordination and priority discussion. The sweet spot is a project/program spanning 5 teams or more. Where sitting in each teams planning meeting is a full-time job and if someone doesn't do it then some critical but small component will be de-prioritized and the whole project will be delayed for a year. Think Rockets, Cars, large hardware projects, large software projects where a dozen teams are required to implement GDPR for their services etc. When this role is placed in a small team of 8-20 engineers it just adds more status update burden to the team, the engineers can more effectively communicate with each other than through a TPM and so the only role the TPM can fill is "pushing". If one can assume that engineers don't choose to slack off whenever someone isn't looking - then pushing just means extra hours, burnout, and missed dates.

Viliam1234 6y ago

> They think they're adding value by just pushing people constantly. Isn't this what traditionally most managers were doing? I remember my first job, decades ago, before agile was a thing, when I had this interaction with my boss constantly: "How long is this new feature going to take?" "Not sure, probably three weeks." "Are you absolutely sure it can't be done in two weeks?" "Well, I guess in the lucky case it might be possible, but..." "Great, so two weeks it is." Then complaining about how I said two weeks and broke my promise, when it actually took two weeks and a half. The only difference is that now you can do it with numbers, so it seems more "scientific", even if all numbers are ultimately just guesses.