5 ms·

> The point of Agile/Scrum is to give the developers total peace from interruptions for a sprint of development. That part can be done without scrum. However,

by ath3nd 2y ago

> The point of Agile/Scrum is to give the developers total peace from interruptions for a sprint of development. That part can be done without scrum. However, you are omitting that scrum also drags: Product Owners, sprint plannings, poker, daily standups, sprint demos. And you know what follows a sprint? Another sprint...And every time you miss that (self imposed, totally arbitrary) deadline, you fail. I simply don't understand why people do this to themselves.

theshrike79 2y ago
If you keep missing "deadlines", you aren't planning properly. You can always take more work for a sprint, don't overcommit. Product Owner is just the one who prioritises the features the team implements, they're the one whose job is to know what the client wants and translate it to more technical terms and individual features. Sprint planning is just... planning what you'll do for the spring? Don't you usually plan your projects or do you just YOLO it? Standups can be just two lines of text in a daily Slack thread, but usually it's handier to just gather around and go through what you did and what you'll be doing. Demos are the best part of Scrum, you get to show what you accomplished to people who understand the client's requirements and you'll get immediate feedback for the next sprint. What kind of project model do you like if Scrum is The Devil Incarnate? Who takes care of customer requirements? Do you plan your time use? How do you teach other people in the company not to bother the team during implementation?
- ath3nd 2y ago
  > Standups can be just two lines of text in a daily Slack thread, but usually it's handier to just gather around and go through what you did and what you'll be doing. Why? So a middle manager can create a report and submit it to their superiors? What if we omit all these reporting steps (and the middle manager) and gather when there is need to gather only? The team knows what they are doing, they can see it in each other's commits and each other's tickets. Who are you trying to inform/report to here? > What kind of project model do you like if Scrum is The Devil Incarnate? Kanban > Who takes care of customer requirements? Developers. You can also implement a feedback form and read it as a team. > Do you plan your time use Roughly. If we knew exactly what each thing entails to plan it in detail, that'd be waterfall. Or scrum, which is mini waterfalls one after another, never ending. That time you spend on planning, better spend it doing, and without a ceremony master. > How do you teach other people in the company not to bother the team during implementation? We told them once. If you have a problem when business types are barging in all the time and bothering your devs, maybe the business types can get a course in patience and basic manners?
  - theshrike79 2y ago
    So you know at all times what everyone in your team does? Do you chat constantly with everyone on your team? Nobody just hunkers down and does stuff for a few days? It's these cases where the standard checkup time (daily standup) comes in handy. It's not for "the middle management", it's for the team to know how everyone is progressing. -- How do you manage releases with Kanban? Do you have a release train and release whatever happens to be complete at the time it leaves the stateion or something else? -- So Developers take the time to arrange a meeting with the customer, talk with them about their problem, write down the features etc? And this is fine, but spending a Monday morning every two weeks planning a sprint is anathema? Nobody in the team is an introvert who considers root canal without anaesthesia more enticing than spending a full day talking with non-technical customers about project requirements? -- You clearly have the cojones and corporate political power to tell business types and middle managers to fuck off. Many MANY other developers do not, if they tell the sales lead to fuck off with his "urgent" requests mid sprint, they'll be looking for a new job the next morning.
jq-r 2y ago
I think it's a management strategy to keep developers under constant pressure with feet close to the fire. There is always something to do, report, meet, discuss in a formalized way, damn everything else. Even if you didn't do much this week you still have to report something. Do this two weeks in a row and your already on the naughty list. Doesn't matter if your tenure was stellar so far. In my experience the only ones loving it are of course management, and highly vocal and relatively young developers who seek refuge in arbitrary procedures and fake structure. As others said, it's also a way to try to treat developers as assembly line workers, which can be replaced at any time. Doctors or lawyers have no such thing. Nor any other engineering profession that I know of. Software development is a realm of snake oil salesman, move fast - break things philosophy, and no unions. So no wonder we get this kind of crap shoved down our throats. And just like with any mass of people, a certain percentage will absolutely adore it.
- ath3nd 2y ago
  > As others said, it's also a way to try to treat developers as assembly line workers Yes, a constant reminder that, even if you are highly paid cog in the machine, you are still a cog that can be replaced at any moment. Because, you know, real decisions about what the product have to be made by a businessy dude, while developers are relegated to playing with their ci/cd and expensive toys. I guess what pisses me off the most is the patronizing attitude. All these methodologies scream: 'I don't trust you, so I will flood you with process where I can micromanage you'.
- theshrike79 2y ago
  And I think it's a good way to communicate how the team works. If you want new features, you talk to the product owner and they'll add it to the backlog - at a priority they choose. You don't barge into the team's area demanding "just this one quick fix", there's a clear process to get your stuff in the queue. If your workplace already works like this, you don't need agile, scrum or any other method with a fancy name. Keep doing what you're doing. Agile is a way to save developers in orgs where it's normal for the sales guy to come in to a team's room and announce that they sold feature X to a client already and it needs to be delivered next Friday.

by ath3nd 2y ago

theshrike79 2y ago

If you keep missing "deadlines", you aren't planning properly. You can always take more work for a sprint, don't overcommit. Product Owner is just the one who prioritises the features the team implements, they're the one whose job is to know what the client wants and translate it to more technical terms and individual features. Sprint planning is just... planning what you'll do for the spring? Don't you usually plan your projects or do you just YOLO it? Standups can be just two lines of text in a daily Slack thread, but usually it's handier to just gather around and go through what you did and what you'll be doing. Demos are the best part of Scrum, you get to show what you accomplished to people who understand the client's requirements and you'll get immediate feedback for the next sprint. What kind of project model do you like if Scrum is The Devil Incarnate? Who takes care of customer requirements? Do you plan your time use? How do you teach other people in the company not to bother the team during implementation?

ath3nd 2y ago
> Standups can be just two lines of text in a daily Slack thread, but usually it's handier to just gather around and go through what you did and what you'll be doing. Why? So a middle manager can create a report and submit it to their superiors? What if we omit all these reporting steps (and the middle manager) and gather when there is need to gather only? The team knows what they are doing, they can see it in each other's commits and each other's tickets. Who are you trying to inform/report to here? > What kind of project model do you like if Scrum is The Devil Incarnate? Kanban > Who takes care of customer requirements? Developers. You can also implement a feedback form and read it as a team. > Do you plan your time use Roughly. If we knew exactly what each thing entails to plan it in detail, that'd be waterfall. Or scrum, which is mini waterfalls one after another, never ending. That time you spend on planning, better spend it doing, and without a ceremony master. > How do you teach other people in the company not to bother the team during implementation? We told them once. If you have a problem when business types are barging in all the time and bothering your devs, maybe the business types can get a course in patience and basic manners?
- theshrike79 2y ago
  So you know at all times what everyone in your team does? Do you chat constantly with everyone on your team? Nobody just hunkers down and does stuff for a few days? It's these cases where the standard checkup time (daily standup) comes in handy. It's not for "the middle management", it's for the team to know how everyone is progressing. -- How do you manage releases with Kanban? Do you have a release train and release whatever happens to be complete at the time it leaves the stateion or something else? -- So Developers take the time to arrange a meeting with the customer, talk with them about their problem, write down the features etc? And this is fine, but spending a Monday morning every two weeks planning a sprint is anathema? Nobody in the team is an introvert who considers root canal without anaesthesia more enticing than spending a full day talking with non-technical customers about project requirements? -- You clearly have the cojones and corporate political power to tell business types and middle managers to fuck off. Many MANY other developers do not, if they tell the sales lead to fuck off with his "urgent" requests mid sprint, they'll be looking for a new job the next morning.

jq-r 2y ago

I think it's a management strategy to keep developers under constant pressure with feet close to the fire. There is always something to do, report, meet, discuss in a formalized way, damn everything else. Even if you didn't do much this week you still have to report something. Do this two weeks in a row and your already on the naughty list. Doesn't matter if your tenure was stellar so far. In my experience the only ones loving it are of course management, and highly vocal and relatively young developers who seek refuge in arbitrary procedures and fake structure. As others said, it's also a way to try to treat developers as assembly line workers, which can be replaced at any time. Doctors or lawyers have no such thing. Nor any other engineering profession that I know of. Software development is a realm of snake oil salesman, move fast - break things philosophy, and no unions. So no wonder we get this kind of crap shoved down our throats. And just like with any mass of people, a certain percentage will absolutely adore it.

ath3nd 2y ago
> As others said, it's also a way to try to treat developers as assembly line workers Yes, a constant reminder that, even if you are highly paid cog in the machine, you are still a cog that can be replaced at any moment. Because, you know, real decisions about what the product have to be made by a businessy dude, while developers are relegated to playing with their ci/cd and expensive toys. I guess what pisses me off the most is the patronizing attitude. All these methodologies scream: 'I don't trust you, so I will flood you with process where I can micromanage you'.
theshrike79 2y ago
And I think it's a good way to communicate how the team works. If you want new features, you talk to the product owner and they'll add it to the backlog - at a priority they choose. You don't barge into the team's area demanding "just this one quick fix", there's a clear process to get your stuff in the queue. If your workplace already works like this, you don't need agile, scrum or any other method with a fancy name. Keep doing what you're doing. Agile is a way to save developers in orgs where it's normal for the sales guy to come in to a team's room and announce that they sold feature X to a client already and it needs to be delivered next Friday.