7 ms·

I’ve developed a more nuanced view on Scrum since working as a contractor for a medium sized software company, but adjacent to their normal dev teams. I used t

by mwint 3y ago

I’ve developed a more nuanced view on Scrum since working as a contractor for a medium sized software company, but adjacent to their normal dev teams. I used to have the view that Scrum is a useless batch of meetings, that sucks the life and productivity out of the dev process. Now, after seeing it from an adjacent (but not subjugated under it) perspective, I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them. Most of us here are not in that category. I’d wager a majority of HN readers can’t help but to seek out understanding of the business, where this piece fits, what it interacts with. For us, specifying everything upfront is useless. Estimating stuff is irritating because we need the flexibility to make smart decisions during dev. Retro meetings are lies because we can’t say “stop with all this and let me work”. But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works. I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them. But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision. That’s what scrum is; it feels like micromanagement because it is. It forces junior-performing devs into a productive state - maybe 5% of what you’d get out of a senior-performing dev without scrum, but it’s something non-negative.

beardedwizard 3y ago
I really appreciate this take and the sibling comment. Exactly. See what good is there, move on about the rest.
- lafar6503 3y ago
  But what to do when instead of 6 competent and efficient devs you get 40 people with random mix of skills, no domain knowledge and at moderate programming talent? I dont know Scrum to comment on it, but many management methods converge to 'appear that work is done all the time even if it's just meaningless bureaucracy, make everything slow and inefficient, but manage the expectations - so customer is moderately disappointed all the time but there are no catastrophic failures. And make sure there are no red lights on the dashboard, ever.'
  - keikobadthebad 3y ago
    > But what to do when instead of 6 competent and efficient devs you get 40 people with random mix of skills, no domain knowledge and at moderate programming talent? Leave. That sounds like it's someone's problem, but it doesn't need to be yours.
xyzelement 3y ago
I agree with this. In my experience: these "rituals" are a way to force the conversations that a "senior" - in your terminology - dev would naturally have.
deleted 3y ago
[deleted]
theshrike79 3y ago
> I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them. The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value. You can easily find 40 mid to low level coders and a half-dozen people who know how to run a scrum team. Maybe even some of the coders know how to do that for extra savings. Also in the latter way you can easily have a turnover in the team without any major hassles, you can always find mid-tier coders. But if one of the 6 highly experienced ones leaves, good luck finding a new one quickly. A shitty car analogy: You can get a more efficient and faster car if it's 100% custom made. But if something breaks you need to manufacture the parts. Or you could make do with a less efficient and slower car, built out of highly standardised off the shelf parts.
- wqtz 3y ago
  I have been taking a closer look at project management and product management in the last few months. Coming from the programming side, I thought technical product manager rule the world, and thought everything that is technically led is glorious. Then I had a very personal conversation with hardcore project manager from non-tech side. He told me that, I got the idea of management of all wrong. Project manager is an operator where the engineers are nothing more than machine. Your standard engineer is not interested or even care about business goals. They are doing a job, they like to be told what is expected from them, they like to be told what deliverable is. Senior engineers can give an estimate of delivery date, but most don't. They are essentially cogs in the machine and managers are expected to birth products from them. About those experienced devs: In an manufacturing plant there are things that just works and you don't fiddle with them. Or else, they break and you have to get a brand new thing. Most of these senior engineer with business focus are difficult to manage and they have an expiry date on them. You are lucky to get one, but you have to count the days until they leave for better pay. Moreover, you don't want programmers interested in business side as they get passionate about things that don't concern them which is obviously business side things. So, you need engineers to work but not get ideas. --- He told a bunch of those stories, but it seems these stories are like if you are in the business, you probably know already type things. He really doesn't buy the idea that "software engineers" are special type of engineers, he said, management hasn't change in centuries, people just use different rhetoric that's all.
Foobar8568 3y ago
I would fully agree with your point if I weren't regularly in daily were nobody listen to what being said : e.g. discovering by themselves what was said the previous day/week as it was a new piece of important information to share.
nivertech 3y ago
https://news.ycombinator.com/item?id=37134050 https://news.ycombinator.com/item?id=37134050 > Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups. > If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some micromanaging SDLC like Scrum.
- touisteur 3y ago
  I'm also wondering whether using Scrum somehow makes your team become this dysfunctional COBOL programmer team...
- poulsbohemian 3y ago
  So funny thing... about twenty years ago I was managing a project with Cobol developers on one side, and this web thing on the other. And we had a bunch of business people convinced we were all stupid and lazy, so they wanted to force us to do this scrum thing. We would do things like a daily standup with them in order to go through the motions, and then we'd have the real meetings once they left us alone. Because the problem wasn't that the Cobol programmers were dysfunctional, it was that the business refused to actually listen and understand anything - they just wanted to make edicts, even when they didn't understand the regulations or processes in their own business (this being a highly regulated industry...). I pulled off what was perhaps the first project in that company's history that got delivered on time and met its requirements (and it was a big flipping deal of a project...) and the business people took credit for it and I got overlooked for promotion and life went on.
  - tamimio 3y ago
    > and the business people took credit for it and I got overlooked for promotion and life went on. Story of my life! And I guess it is the case for most competent employees unfortunately.
- thunderbong 3y ago
  The reply to that comment is also valid, IMHO
lowbloodsugar 3y ago
99.9% of “Scrum” you’ll come across in the wild is cargo cult. People performing the ceremonies with no fucking idea why, in the hope that the giant eagles will come from the sky bringing gifts. Scrum was created to help good developers communicate with management. But the problem is that management has all the power and couldn’t give a shit. If the management was qualified to “get it” you probably wouldn’t need it. So yeah, if you’re using Scrum, you’re probably going to fail: whatever the reason that you’re doing scrum? That’s why you’re gonna fail. Scrum is a fantastic canary.
- shortcake27 3y ago
  I once worked at a place that did Scrum for the exact reasons you mentioned. Every user story was the same - “As a business owner, I want users to be able to do x”. Defeats the entire purposes of user stories. But they were told they had to write stories. So they did. We also had our work planned out 6-12 months in advance. It was top-down waterfall disguised as agile, which would have been acceptable if we didn’t also waste 5+ hours a week in daily standups (aka status reports), sprint planning, retros, story breakdowns, all of which were scheduled at the most inconvenient of times to ensure they interrupted your flow.
travisgriggs 3y ago
Ok, this totally resonates. What I want to know is how I find a place to hang out with those 5 other devs. I’ve had that “team of six motivated” come together twice organically during my career. But it never seems to last. People move on, the company gets wind of the success and either normalizes it out, or attempts to try and distribute and harvest. If I could figure out the recipe to reliably locate or create that sort of team, I think I’d be very well off.
andrei_says_ 3y ago
I love https://basecamp.com/shapeup https://basecamp.com/shapeup approach - tiny teams with high independence and sufficient domain knowledge working in six week periods to deliver features. And here’s Dave Thomas (one of the names under the Agile Manifesto) speaking of the Agile/Scrum Industrial Complex https://youtu.be/a-BOSpxYJ9M?si=pwROU4JU9V64A39O https://youtu.be/a-BOSpxYJ9M?si=pwROU4JU9V64A39O
littlestymaar 3y ago
> taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them. Maybe in theory that's the point of it, but it practice it also (and mostly) has the opposite effect: it takes all agency away from capable developers and make them impossible to see the big picture, drastically plummeting developer productivity of otherwise very capable developers. > Most of us here are not in that category. […] For us, […] is useless. It's not just useless, it's actually harmful. > But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision But most of the time it's not how it happens: it's forced top-down by manager who have no idea of how software development work, and who are genuinely convinced that it is how projects should be run. They don't realize that it's a workaround for terrible HR that reduces productivity for everyone, because if they did they'd probably think twice (“How is my HR so poor when I'm not trying to cut on costs there? Oh maybe it's not and I should not use scrum”), they just do it because everybody else does.
PeterStuer 3y ago
It works both ways. Every form of micromanagement will turn every dev team into a bunch of demotivated, junior performing, just here for the paycheck careless bunch of codemonkeys. It is an assured loss for all. Why not the opossite way? Trust people a bit above what they currently warrant, see who rises to the opportunity, and ease out the rest. This will over time elevate to a decent team.
- kelseyfrog 3y ago
  The Netflix Culture deck[1] acknowledges that this strategy requires "top of market compensation." What percentage of organizations have the ability to pay top of market compensation? The answer to that is the reason why the strategy doesn't generalize. 1. https://igormroz.com/documents/netflix_culture.pdf https://igormroz.com/documents/netflix_culture.pdf
  - PeterStuer 3y ago
    I don't see where the document you cite makes this causal link. In my experience this is also not true. You pay enough for money not to be a concern. Then people start to value other things, such as not getting depressed through being micromanaged or killed by process.
poulsbohemian 3y ago
>taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them That's a very charitable view... I think back over my career and it was always cargo-culting and micromanagement. I give you credit for analyzing and finding a way to make scrum work beneficially. The thing is - if you have people who don't (want to) understand the relationship between their work and business value, you've fundamentally got a hiring / personnel problem. And I don't see how scrum (or any other methodology) ever solves that. What you've got at that point is to me the difference between "programmers" and "developers / engineers". People who are more enamored with the technology than with actually accomplishing work. The thing is, some of those people are really good so long as they can be pointed in the right direction. But that's a management thing, not really a methodology thing.
- Shorel 3y ago
  The thing is, IMO, everyone has a hiring problem. It is very easy to hire one bad player, and he takes the team down, and (in most jurisdictions) it is hard to lay them off. The reason is, no one who knows what it is required, wants to do the hiring.
EVa5I7bHFq9mnYK 3y ago
I have been slaving as a cheap outsourced labor in a poor country for a large US software company. The goal of the scrum manager was specifically to prevent code monkeys from asking questions about "business/architecture picture" and to specify the tasks as narrow as possible. Anyone who asked too many questions was seen as a threat, as if they were going to communicate directly with our US masters and break the command chain.
- rightbyte 3y ago
  Ye God I hate "chain of command" places. "Need to know basis" is the most toxic leadership type there is. Since my conscription it instantly makes my blood boil. You always want to be able to sidestep your boss to your boss's boss of you need to. Or talk to end users and customers.
mkl95 3y ago
> I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them. If I'm being onboarded at some project, I expect to be provided that description as early as possible. Compensating for broken communication by enforcing a life-sucking batch of meetings doesn't seem right.
jillesvangurp 3y ago
Been on both sides of the equation as well over the past three decades. Two observations. 1) As you said, when you have a lot of junior developers (which given developer demographics is a given), you need some structure. Scrum provides that. For better or worse, the structure is helpful to people that are still a bit uncertain about how stuff works. I hate stand-ups as much as any other developer. But as a product focused CTO, I love that it gets the day started and my developers out of bed, awake and cafienated and focused on the job. Scrum's other meetings are a necessary evil. You need a platform to get them aligned with business goals. They don't naturally do this by themselves. Most importantly, a lot of developers kind of expect to this structure at this point. Providing structure to a team is important. Scrum is as good as any other structure. Not ideal with remote teams as meetings get more tricky. 2) Most scrum roles are junior management roles. And as such you get typically not very experienced people filling these roles as part of their entry into the corporate rat race. So, you get corporate politics playing out at the micro level with lots of turf fights about stuff that generally is close to irrelevant. Ranging from the right way to run meetings, the best issue tracker, etc. It's this endless friction that is causing a lot of resentment with more senior developers. Particularly in larger organizations this can get ugly in a hurry. My strategy for containing this madness: 1) Keep teams small. Small teams are efficient teams that should not need a lot of (micro) management. And they also don't need a lot of formal roles. 2) No scrum masters. It's a bullshit role that doesn't add a whole lot of value. Especially in smaller teams. Instead I prefer to have tech leads calling the shots on their team or topic and stepping up as a leader. Part of that responsibility is leading the team in a direction that makes sense from a technical and business point of view. And the rest is about coaching people around them. It's something that happens naturally even when you don't want it to. So, I mostly just let this happen and encourage it. 3) Product ownership splits into technical and business ownership. While these can be the same person, it's better to have two equally ranked people shooting for consensus covering both business and tech. That ensures the business and tech is actually aligned. Weed out unrealistic requirements and deadlines; make sure that the technically easy yet valuable work actually gets done; ensure that business value is delivered; ensure that work gets prioritized correctly and that POs don't revert back to waterfall. 4) Management by exception. I like giving people enough room to manage themselves. I step in when that doesn't work. And I use positive re-enforcement to encourage them to do more of the right things. I'm not actually a genius; so I need smart people to tell me what the right way is to do things. Especially when those are things I'm not that good at. People closest to the problems, usually are best positioned to come up with good solutions. So let them. Fix it when that isn't working. 5) Use sprints as a predictable, calendar based umbrella for people to structure their activities around. Short enough cycles that it doesn't turn into waterfall. Long enough that we don't drown in meetings. Day to day management is Kanban based. Just generally remove uncertainty about what needs doing, who is doing it, why we're doing it, what's coming next, etc. Using continuous deployment to release stuff means that guarding quality is a constant and not a once a sprint kind of thing. Sprints are not release deadlines. Using Kanban day to day means that any high priority issues jump to the top of the stack right away. Short feedback cycles are key to keeping quality and morale high. 6) Meetings can be synchronization blocks. Any engineer knows those are bad. Business people seem to never grasp the cost of meetings (as this is all they do). It translates 1 to 1 to how teams function as well. That's why day to day work should not be blocked on meetings. We have issue trackers, slack, and other communication tools to sort out any blocking issues. Also, just talking to a person can be surprisingly effective. Scrum meetings are neatly partitioned to be about things like status updates, prioritization, estimation, and reviews. None of those meetings should be on the critical path to delivering working software. The correct way to resolve issues is direct or asynchronous communication (as is convenient). 7) Try to keep the few meetings we have a bit positive, light and friendly. It's bad enough that we have to sit through those. Conflict is what makes scrum so controversial. The constant bickering about everything and anything is just a mental drain on everyone. I try to keep that out of meetings as much as I can. Having tech leads means that they get a first shot at a decision. So, no need to have a lot of meetings about that. I use one on ones to correct a lot of things when they go wrong in meetings. Meetings are for positive re-enforcement. Call out the things that go well, inspire people to do more of the good stuff, etc.
binary132 3y ago
Most companies want to minimize salary while managers and directors are highly incentivized to maximize headcount. It’s very perverse.
kelnos 3y ago
> But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works. I don't think that's even the case. I've been brought onto teams of junior (in the sense that you talk about) developers to help fix broken, late projects. Those projects had always been managed under some sort of agile process, and they still ended up in trouble. I wouldn't even say the process "sort of" worked before then. I dunno, maybe it would have been even more of a disaster without the process, but I still don't think that lends much praise to the process. I'm lucky that I can pick and choose what sort of projects I work on these days, and I will never work at or for a company where I'd be subject to any kind of agile garbage. Another toplevel commenter farther down mentioned a study that showed that projects managed under the "get to work and let me know when it's done" model outperformed all the others. I've always intuitively believed that model can work (though perhaps not in all situations with all types of developers), and it's nice to see some data to back that up.

by mwint 3y ago

beardedwizard 3y ago

I really appreciate this take and the sibling comment. Exactly. See what good is there, move on about the rest.

lafar6503 3y ago
But what to do when instead of 6 competent and efficient devs you get 40 people with random mix of skills, no domain knowledge and at moderate programming talent? I dont know Scrum to comment on it, but many management methods converge to 'appear that work is done all the time even if it's just meaningless bureaucracy, make everything slow and inefficient, but manage the expectations - so customer is moderately disappointed all the time but there are no catastrophic failures. And make sure there are no red lights on the dashboard, ever.'
- keikobadthebad 3y ago
  > But what to do when instead of 6 competent and efficient devs you get 40 people with random mix of skills, no domain knowledge and at moderate programming talent? Leave. That sounds like it's someone's problem, but it doesn't need to be yours.

xyzelement 3y ago

I agree with this. In my experience: these "rituals" are a way to force the conversations that a "senior" - in your terminology - dev would naturally have.

deleted 3y ago

[deleted]

theshrike79 3y ago

> I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them. The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value. You can easily find 40 mid to low level coders and a half-dozen people who know how to run a scrum team. Maybe even some of the coders know how to do that for extra savings. Also in the latter way you can easily have a turnover in the team without any major hassles, you can always find mid-tier coders. But if one of the 6 highly experienced ones leaves, good luck finding a new one quickly. A shitty car analogy: You can get a more efficient and faster car if it's 100% custom made. But if something breaks you need to manufacture the parts. Or you could make do with a less efficient and slower car, built out of highly standardised off the shelf parts.

wqtz 3y ago
I have been taking a closer look at project management and product management in the last few months. Coming from the programming side, I thought technical product manager rule the world, and thought everything that is technically led is glorious. Then I had a very personal conversation with hardcore project manager from non-tech side. He told me that, I got the idea of management of all wrong. Project manager is an operator where the engineers are nothing more than machine. Your standard engineer is not interested or even care about business goals. They are doing a job, they like to be told what is expected from them, they like to be told what deliverable is. Senior engineers can give an estimate of delivery date, but most don't. They are essentially cogs in the machine and managers are expected to birth products from them. About those experienced devs: In an manufacturing plant there are things that just works and you don't fiddle with them. Or else, they break and you have to get a brand new thing. Most of these senior engineer with business focus are difficult to manage and they have an expiry date on them. You are lucky to get one, but you have to count the days until they leave for better pay. Moreover, you don't want programmers interested in business side as they get passionate about things that don't concern them which is obviously business side things. So, you need engineers to work but not get ideas. --- He told a bunch of those stories, but it seems these stories are like if you are in the business, you probably know already type things. He really doesn't buy the idea that "software engineers" are special type of engineers, he said, management hasn't change in centuries, people just use different rhetoric that's all.

Foobar8568 3y ago

I would fully agree with your point if I weren't regularly in daily were nobody listen to what being said : e.g. discovering by themselves what was said the previous day/week as it was a new piece of important information to share.

nivertech 3y ago

https://news.ycombinator.com/item?id=37134050 https://news.ycombinator.com/item?id=37134050 > Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups. > If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some micromanaging SDLC like Scrum.

touisteur 3y ago
I'm also wondering whether using Scrum somehow makes your team become this dysfunctional COBOL programmer team...
poulsbohemian 3y ago
So funny thing... about twenty years ago I was managing a project with Cobol developers on one side, and this web thing on the other. And we had a bunch of business people convinced we were all stupid and lazy, so they wanted to force us to do this scrum thing. We would do things like a daily standup with them in order to go through the motions, and then we'd have the real meetings once they left us alone. Because the problem wasn't that the Cobol programmers were dysfunctional, it was that the business refused to actually listen and understand anything - they just wanted to make edicts, even when they didn't understand the regulations or processes in their own business (this being a highly regulated industry...). I pulled off what was perhaps the first project in that company's history that got delivered on time and met its requirements (and it was a big flipping deal of a project...) and the business people took credit for it and I got overlooked for promotion and life went on.
- tamimio 3y ago
  > and the business people took credit for it and I got overlooked for promotion and life went on. Story of my life! And I guess it is the case for most competent employees unfortunately.
thunderbong 3y ago
The reply to that comment is also valid, IMHO

lowbloodsugar 3y ago

99.9% of “Scrum” you’ll come across in the wild is cargo cult. People performing the ceremonies with no fucking idea why, in the hope that the giant eagles will come from the sky bringing gifts. Scrum was created to help good developers communicate with management. But the problem is that management has all the power and couldn’t give a shit. If the management was qualified to “get it” you probably wouldn’t need it. So yeah, if you’re using Scrum, you’re probably going to fail: whatever the reason that you’re doing scrum? That’s why you’re gonna fail. Scrum is a fantastic canary.

shortcake27 3y ago
I once worked at a place that did Scrum for the exact reasons you mentioned. Every user story was the same - “As a business owner, I want users to be able to do x”. Defeats the entire purposes of user stories. But they were told they had to write stories. So they did. We also had our work planned out 6-12 months in advance. It was top-down waterfall disguised as agile, which would have been acceptable if we didn’t also waste 5+ hours a week in daily standups (aka status reports), sprint planning, retros, story breakdowns, all of which were scheduled at the most inconvenient of times to ensure they interrupted your flow.

travisgriggs 3y ago

Ok, this totally resonates. What I want to know is how I find a place to hang out with those 5 other devs. I’ve had that “team of six motivated” come together twice organically during my career. But it never seems to last. People move on, the company gets wind of the success and either normalizes it out, or attempts to try and distribute and harvest. If I could figure out the recipe to reliably locate or create that sort of team, I think I’d be very well off.

andrei_says_ 3y ago

I love https://basecamp.com/shapeup https://basecamp.com/shapeup approach - tiny teams with high independence and sufficient domain knowledge working in six week periods to deliver features. And here’s Dave Thomas (one of the names under the Agile Manifesto) speaking of the Agile/Scrum Industrial Complex https://youtu.be/a-BOSpxYJ9M?si=pwROU4JU9V64A39O https://youtu.be/a-BOSpxYJ9M?si=pwROU4JU9V64A39O

littlestymaar 3y ago

> taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them. Maybe in theory that's the point of it, but it practice it also (and mostly) has the opposite effect: it takes all agency away from capable developers and make them impossible to see the big picture, drastically plummeting developer productivity of otherwise very capable developers. > Most of us here are not in that category. […] For us, […] is useless. It's not just useless, it's actually harmful. > But I can also see how a company ends up there - go through a tough hiring year, or even just make a few poor hiring decisions, and now you have people on the team who need handholding and supervision But most of the time it's not how it happens: it's forced top-down by manager who have no idea of how software development work, and who are genuinely convinced that it is how projects should be run. They don't realize that it's a workaround for terrible HR that reduces productivity for everyone, because if they did they'd probably think twice (“How is my HR so poor when I'm not trying to cut on costs there? Oh maybe it's not and I should not use scrum”), they just do it because everybody else does.

PeterStuer 3y ago

It works both ways. Every form of micromanagement will turn every dev team into a bunch of demotivated, junior performing, just here for the paycheck careless bunch of codemonkeys. It is an assured loss for all. Why not the opossite way? Trust people a bit above what they currently warrant, see who rises to the opportunity, and ease out the rest. This will over time elevate to a decent team.

kelseyfrog 3y ago
The Netflix Culture deck[1] acknowledges that this strategy requires "top of market compensation." What percentage of organizations have the ability to pay top of market compensation? The answer to that is the reason why the strategy doesn't generalize. 1. https://igormroz.com/documents/netflix_culture.pdf https://igormroz.com/documents/netflix_culture.pdf
- PeterStuer 3y ago
  I don't see where the document you cite makes this causal link. In my experience this is also not true. You pay enough for money not to be a concern. Then people start to value other things, such as not getting depressed through being micromanaged or killed by process.

poulsbohemian 3y ago

>taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them That's a very charitable view... I think back over my career and it was always cargo-culting and micromanagement. I give you credit for analyzing and finding a way to make scrum work beneficially. The thing is - if you have people who don't (want to) understand the relationship between their work and business value, you've fundamentally got a hiring / personnel problem. And I don't see how scrum (or any other methodology) ever solves that. What you've got at that point is to me the difference between "programmers" and "developers / engineers". People who are more enamored with the technology than with actually accomplishing work. The thing is, some of those people are really good so long as they can be pointed in the right direction. But that's a management thing, not really a methodology thing.

Shorel 3y ago
The thing is, IMO, everyone has a hiring problem. It is very easy to hire one bad player, and he takes the team down, and (in most jurisdictions) it is hard to lay them off. The reason is, no one who knows what it is required, wants to do the hiring.

EVa5I7bHFq9mnYK 3y ago

I have been slaving as a cheap outsourced labor in a poor country for a large US software company. The goal of the scrum manager was specifically to prevent code monkeys from asking questions about "business/architecture picture" and to specify the tasks as narrow as possible. Anyone who asked too many questions was seen as a threat, as if they were going to communicate directly with our US masters and break the command chain.

rightbyte 3y ago
Ye God I hate "chain of command" places. "Need to know basis" is the most toxic leadership type there is. Since my conscription it instantly makes my blood boil. You always want to be able to sidestep your boss to your boss's boss of you need to. Or talk to end users and customers.

mkl95 3y ago

> I think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them. If I'm being onboarded at some project, I expect to be provided that description as early as possible. Compensating for broken communication by enforcing a life-sucking batch of meetings doesn't seem right.

jillesvangurp 3y ago

Been on both sides of the equation as well over the past three decades. Two observations. 1) As you said, when you have a lot of junior developers (which given developer demographics is a given), you need some structure. Scrum provides that. For better or worse, the structure is helpful to people that are still a bit uncertain about how stuff works. I hate stand-ups as much as any other developer. But as a product focused CTO, I love that it gets the day started and my developers out of bed, awake and cafienated and focused on the job. Scrum's other meetings are a necessary evil. You need a platform to get them aligned with business goals. They don't naturally do this by themselves. Most importantly, a lot of developers kind of expect to this structure at this point. Providing structure to a team is important. Scrum is as good as any other structure. Not ideal with remote teams as meetings get more tricky. 2) Most scrum roles are junior management roles. And as such you get typically not very experienced people filling these roles as part of their entry into the corporate rat race. So, you get corporate politics playing out at the micro level with lots of turf fights about stuff that generally is close to irrelevant. Ranging from the right way to run meetings, the best issue tracker, etc. It's this endless friction that is causing a lot of resentment with more senior developers. Particularly in larger organizations this can get ugly in a hurry. My strategy for containing this madness: 1) Keep teams small. Small teams are efficient teams that should not need a lot of (micro) management. And they also don't need a lot of formal roles. 2) No scrum masters. It's a bullshit role that doesn't add a whole lot of value. Especially in smaller teams. Instead I prefer to have tech leads calling the shots on their team or topic and stepping up as a leader. Part of that responsibility is leading the team in a direction that makes sense from a technical and business point of view. And the rest is about coaching people around them. It's something that happens naturally even when you don't want it to. So, I mostly just let this happen and encourage it. 3) Product ownership splits into technical and business ownership. While these can be the same person, it's better to have two equally ranked people shooting for consensus covering both business and tech. That ensures the business and tech is actually aligned. Weed out unrealistic requirements and deadlines; make sure that the technically easy yet valuable work actually gets done; ensure that business value is delivered; ensure that work gets prioritized correctly and that POs don't revert back to waterfall. 4) Management by exception. I like giving people enough room to manage themselves. I step in when that doesn't work. And I use positive re-enforcement to encourage them to do more of the right things. I'm not actually a genius; so I need smart people to tell me what the right way is to do things. Especially when those are things I'm not that good at. People closest to the problems, usually are best positioned to come up with good solutions. So let them. Fix it when that isn't working. 5) Use sprints as a predictable, calendar based umbrella for people to structure their activities around. Short enough cycles that it doesn't turn into waterfall. Long enough that we don't drown in meetings. Day to day management is Kanban based. Just generally remove uncertainty about what needs doing, who is doing it, why we're doing it, what's coming next, etc. Using continuous deployment to release stuff means that guarding quality is a constant and not a once a sprint kind of thing. Sprints are not release deadlines. Using Kanban day to day means that any high priority issues jump to the top of the stack right away. Short feedback cycles are key to keeping quality and morale high. 6) Meetings can be synchronization blocks. Any engineer knows those are bad. Business people seem to never grasp the cost of meetings (as this is all they do). It translates 1 to 1 to how teams function as well. That's why day to day work should not be blocked on meetings. We have issue trackers, slack, and other communication tools to sort out any blocking issues. Also, just talking to a person can be surprisingly effective. Scrum meetings are neatly partitioned to be about things like status updates, prioritization, estimation, and reviews. None of those meetings should be on the critical path to delivering working software. The correct way to resolve issues is direct or asynchronous communication (as is convenient). 7) Try to keep the few meetings we have a bit positive, light and friendly. It's bad enough that we have to sit through those. Conflict is what makes scrum so controversial. The constant bickering about everything and anything is just a mental drain on everyone. I try to keep that out of meetings as much as I can. Having tech leads means that they get a first shot at a decision. So, no need to have a lot of meetings about that. I use one on ones to correct a lot of things when they go wrong in meetings. Meetings are for positive re-enforcement. Call out the things that go well, inspire people to do more of the good stuff, etc.

binary132 3y ago

Most companies want to minimize salary while managers and directors are highly incentivized to maximize headcount. It’s very perverse.

kelnos 3y ago

> But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works. I don't think that's even the case. I've been brought onto teams of junior (in the sense that you talk about) developers to help fix broken, late projects. Those projects had always been managed under some sort of agile process, and they still ended up in trouble. I wouldn't even say the process "sort of" worked before then. I dunno, maybe it would have been even more of a disaster without the process, but I still don't think that lends much praise to the process. I'm lucky that I can pick and choose what sort of projects I work on these days, and I will never work at or for a company where I'd be subject to any kind of agile garbage. Another toplevel commenter farther down mentioned a study that showed that projects managed under the "get to work and let me know when it's done" model outperformed all the others. I've always intuitively believed that model can work (though perhaps not in all situations with all types of developers), and it's nice to see some data to back that up.