Scrum is a cancer(twitter.com)
twitter.com
Scrum is a cancer
https://twitter.com/svpino/status/1695806027256475777
485 comments
The best I can say of scrum is that it's designed to get some amount of output from an otherwise extremely dysfunctional team. If your teams were achieving nothing, it provides a modicum of accountability. So there's places where yes, scrum is an improvement.
But yes, a team of people that understand the business, and can prioritize well without needing someone to do it all for them, scrum just slows the team down. I've seen it happen multiple times in my career, and sometimes succeeded at either undoing the change, or making the jira-based work basically fictional.
But yes, a team of people that understand the business, and can prioritize well without needing someone to do it all for them, scrum just slows the team down. I've seen it happen multiple times in my career, and sometimes succeeded at either undoing the change, or making the jira-based work basically fictional.
There is the old saying that scrum turns bad devs into mediocre devs and good devs into mediocre ones.
Ah yes the defence:
"The process failed because you didn't have enough project managers on board"
No the process failed because it was fucking shit and everyone went somewhere else.
The only good thing heavy processes are for are propping up employment statistics.
"The process failed because you didn't have enough project managers on board"
No the process failed because it was fucking shit and everyone went somewhere else.
The only good thing heavy processes are for are propping up employment statistics.
Have you ever seen the movie Office Space? There’s a bit about “TPS reports” where multiple managers individually correct the main character on a new cover sheet. I’ve experienced that myself. The movie portrays it comedically but IRL it’s kind of a demoralizing experience. A bit soul crushing actually.
Office space is actually accurate once you replace TPS reports with Status reports/JIRA tickets/Performance reports/Incident reports etc.
The amount of dancing required for the sake of management in this industry is just insane.
The amount of dancing required for the sake of management in this industry is just insane.
I think “TPS report” is actually meaningless so it’s supposed to be swapped in for whatever is relevant to the viewer.
It's actually a real thing that software companies of the time were not unlikely to have: https://en.wikipedia.org/wiki/TPS_report
As a long time PM (of all sorts of P)...
If you don't want to have to talk to customers, which only one developer who I've ever worked with has actually wanted to do, you need a way to equip someone else to do so.
Same thing if you want to keep your investors happy, your counterparts in other departments informed of when they need to have the hardware to pair up with your software ready, etc.
There's definitely such a thing as too much overhead, but developers who just do the things they are interested in without considering that they are part of a larger business are the other side of the coin that you're describing.
If you don't want to have to talk to customers, which only one developer who I've ever worked with has actually wanted to do, you need a way to equip someone else to do so.
Same thing if you want to keep your investors happy, your counterparts in other departments informed of when they need to have the hardware to pair up with your software ready, etc.
There's definitely such a thing as too much overhead, but developers who just do the things they are interested in without considering that they are part of a larger business are the other side of the coin that you're describing.
I think there are few things that developers object to that don't appear to get addressed.
1. If other departments need metrics/insights/visibility, why don't they go collect it? As a PM, go collect that information yourself and deliver it to stakeholders? Why does everything need to be done by engineers?
2. When engineers get measured, evaluated and pitted against each other using these activities, it breaks camaraderie. We don't enjoy these activities because we see through the management practices of rating people based on the number of proverbial TPS reports or the quality of the cover sheet or the number of story points completed - none of which are actually important to the success of business but very important to the manager who will just recycle them upwards. Do you really think people are motivated to do this meaningless work?
1. If other departments need metrics/insights/visibility, why don't they go collect it? As a PM, go collect that information yourself and deliver it to stakeholders? Why does everything need to be done by engineers?
2. When engineers get measured, evaluated and pitted against each other using these activities, it breaks camaraderie. We don't enjoy these activities because we see through the management practices of rating people based on the number of proverbial TPS reports or the quality of the cover sheet or the number of story points completed - none of which are actually important to the success of business but very important to the manager who will just recycle them upwards. Do you really think people are motivated to do this meaningless work?
The movie came out the same year all my friends and I graduated a Software Engineering degree.
I love the movie, but damn it hits close to home and I never know if I should laugh or cry.
I love the movie, but damn it hits close to home and I never know if I should laugh or cry.
Silicon valley started the year I entered the tech workforce. Very similar feeling.
I have been unable to re-watch that movie. Because it hits too close to home.
I haven’t seen it yet surprisingly. I will watch it tonight.
You absolutely must. It was great when it was new, it's even better now.
Saw it after getting hooked on Silicon Valley and I’m glad I did. Both come from Mike Judge just as Idiocracy does which is simply brilliant. Had I known that he’s also behind Beavis & Butthead, I would have given it all a hard pass. Now I’m thinking, maybe I just misunderstood Beavis & Butthead.
Just watched it. I am dying inside a little. Amazing film!
Heavy process is fine and necessary if you are building, say, a skyscraper or a nuclear reactor.
Most of us are not.
Most of us are not.
I'm not even sure in that case...
Having written code for a nuclear power plant, I can say, yes, you want some process. But you want effective process. And a lot of thought went into deciding what code was "safety critical" and what code was just "important."
> I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now).
And that was your big mistake. Those are real concerns, but those things are abstract and non-quantifiable. The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.
In my experience even the dumbest and thick-headed management can understand that. I've always imagined if it didn't I could ask to hire more people to compensate for the time lost, but I never had to resort to that.
Granted, you still end up with a mutilated scrum at the end. But if you mutilate it right, you can fit your pre-scrum work process into the terminology of a mutilated scrum.
And that was your big mistake. Those are real concerns, but those things are abstract and non-quantifiable. The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.
In my experience even the dumbest and thick-headed management can understand that. I've always imagined if it didn't I could ask to hire more people to compensate for the time lost, but I never had to resort to that.
Granted, you still end up with a mutilated scrum at the end. But if you mutilate it right, you can fit your pre-scrum work process into the terminology of a mutilated scrum.
> The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common.
I do not understand how this is possible.
* Sprint planning: 2 hours
* Sprint review: 1 hour
* Sprint retro: 1 hour
* Daily stand-up: 15min / day
On a 2 week sprint, 80 hours, that's 5.5 hours spent on ceremonies. That's ~7%.
What are you doing that it could ever take _half_ of total work time and how will you convince management that you aren't completely fucking up scrum?
I do not understand how this is possible.
* Sprint planning: 2 hours
* Sprint review: 1 hour
* Sprint retro: 1 hour
* Daily stand-up: 15min / day
On a 2 week sprint, 80 hours, that's 5.5 hours spent on ceremonies. That's ~7%.
What are you doing that it could ever take _half_ of total work time and how will you convince management that you aren't completely fucking up scrum?
One place I worked at had two week sprints.
Week 1: One whole day for demo, retro, planning, commitment. But because the scrum master had to "build" a sprint and couldn't do that without knowing the size of tickets, there were two morning meetings every week to "analyse" tickets. So two mornings for "analysis" to produce point estimates for tickets.
Week 2: Also two mornings for "analysis".
So 3 days out of the 10 day sprint, so 30% time spent on Scrum.
Plus standups, they were at 10am so 9am-10am nobody did anything (as judged by the number of PRs and comments and Slack activity) so that's an hour plus the time for standup every single day, so I guess the work day started 10:30am on those days which weren't scrum days or scrum mornings.
Plus the scrum "analysis" meetings were in the morning as it was generally accepted everyone was too tired in the afternoon to to those meetings. So what that actually meant imho was that programming was a low-importance activity that could be done when tired, after the actual work of Scrum had been completed.
Maybe that's insanity, I mean I certainly thought so, but these things do happen.
Week 1: One whole day for demo, retro, planning, commitment. But because the scrum master had to "build" a sprint and couldn't do that without knowing the size of tickets, there were two morning meetings every week to "analyse" tickets. So two mornings for "analysis" to produce point estimates for tickets.
Week 2: Also two mornings for "analysis".
So 3 days out of the 10 day sprint, so 30% time spent on Scrum.
Plus standups, they were at 10am so 9am-10am nobody did anything (as judged by the number of PRs and comments and Slack activity) so that's an hour plus the time for standup every single day, so I guess the work day started 10:30am on those days which weren't scrum days or scrum mornings.
Plus the scrum "analysis" meetings were in the morning as it was generally accepted everyone was too tired in the afternoon to to those meetings. So what that actually meant imho was that programming was a low-importance activity that could be done when tired, after the actual work of Scrum had been completed.
Maybe that's insanity, I mean I certainly thought so, but these things do happen.
Our 15 minute standups were about an hour, sometimes longer. The project manager aka scrum master spent at least 80% of those minutes talking. They were scheduled for 11:30am, right when everyone was either wanting to go to lunch, or for people not taking lunch probably the most productive middle part of the day. For those who went to lunch afterward, they never got to start before 12:30pm, and were out to at least 1:30pm. So it sort of wrecked the start of the afternoon too. Not that it didn't wreck the lead-up either, because if you have that crap looming over you at 10:45am you sort of shut down any important thinking you need to do... best not get caught up in what you are doing, because if you're 1 minute late for the standup, there's hell to pay.
But, what little progress there was, was easily measured. That seems to be the important part.
Lunatics run this asylum.
But, what little progress there was, was easily measured. That seems to be the important part.
Lunatics run this asylum.
So it wasn't scrum. It was just bullshitters using the word and doing what they wanted to do anyhow.
There may be a mythical "scrum" out there somewhere, but I and no one I've ever known has seen it. As much as I love a No True Scotsman fallacy, if this is the only thing people have ever seen and have ever attached the label "scrum" to...
Then that is what scrum is.
Then that is what scrum is.
Well you don't know me but I am not a scrum master and I was on a team that had a great experience with it and are all still friends years after we all went to other jobs. It was the great experience of my life.
I know how it worked and why every team I've been on since has not been able to make it work and it all boils down to: 1) internal sabotage - an influential developer does everything they can to shit on it. 2) Management interference - developers could not change the things we needed to change to make it fit our circumstances.
I know how it worked and why every team I've been on since has not been able to make it work and it all boils down to: 1) internal sabotage - an influential developer does everything they can to shit on it. 2) Management interference - developers could not change the things we needed to change to make it fit our circumstances.
No True Scotsman?
That argument can be used either way around so it's fairly useless.
In reality we don't have good software development because people at some level or another don't want to do the things that make it possible. They're always going to pretend they care but do what suits them.
It can be from the most basic thing: the customer doesn't want to pay what it really costs to get something good but can be made to pay for something that's going to turn out to be crap in the end.
In reality we don't have good software development because people at some level or another don't want to do the things that make it possible. They're always going to pretend they care but do what suits them.
It can be from the most basic thing: the customer doesn't want to pay what it really costs to get something good but can be made to pay for something that's going to turn out to be crap in the end.
> n reality we don't have good software development because people at some level or another don't want to do the things that make it possible.
If you're confessing that it's contrary to human nature and/or the engineering thought process, then I humbly accept your concession in this debate.
If you're confessing that it's contrary to human nature and/or the engineering thought process, then I humbly accept your concession in this debate.
That's just a deliberate misinterpretation. How can you argue that way with any honesty?
No True Scrum Master
> What are you doing that it could ever take _half_ of total work time and how will you convince management that you aren't completely fucking up scrum?
Oh, that's very easy. So much so, I wonder exactly how you managed to perform everything required for a planning or review in the time you give. Business meetings can take more than expected in the best of cases, and the various dysfunctions inherent in scrum only add to that.
Here's a fairly obvious example - scrum encourages you to have a lot of management. At minimum a team needs a product owner, a team lead and a scrum master (and if you merge those positions you aren't "doing scrum properly"). Because there are so many managers, each is under pressure to prove they add value. How do they prove that? By providing valuable input in the various ceremonies scrum requires. Hours of it.
And sometimes they add so much value it can't be contained in the normal flow of scrum meetings (or rather, the meetings can't be contained in the course of a work day), so more meetings have to be created.
Oh, that's very easy. So much so, I wonder exactly how you managed to perform everything required for a planning or review in the time you give. Business meetings can take more than expected in the best of cases, and the various dysfunctions inherent in scrum only add to that.
Here's a fairly obvious example - scrum encourages you to have a lot of management. At minimum a team needs a product owner, a team lead and a scrum master (and if you merge those positions you aren't "doing scrum properly"). Because there are so many managers, each is under pressure to prove they add value. How do they prove that? By providing valuable input in the various ceremonies scrum requires. Hours of it.
And sometimes they add so much value it can't be contained in the normal flow of scrum meetings (or rather, the meetings can't be contained in the course of a work day), so more meetings have to be created.
At my job we have
It's laughable.
* pre-planning - 30m
* planning - 30m
* refinement - 90m
* ultra refinement - 90m
* retro - 60m
It's laughable.
Time spent preparing for these is at least the length of each meeting, so at least 14%.
Sprint planning is typically 4 hours [1]. I think there are further reasonable quibbles to be made that would revise that 7% number up to a reasonable 13% or 18%.
The 13% takes into account the time tax of context switching. 18% if we consider only (at best) 6 hours per day and meetings are taking away from that high productivity time (which is to say a greater proportion of time is spent around the coffee maker and not coding)
To go into detail, there is a tax to every meeting. With 13 scrum meetings this adds up fast. For me, as a remote worker, I stop everything 5 minutes before or else (for example) 1:57 is going to suddenly turn into 2:03 and then I'm late. Recovering from a meeting takes me about 10 minutes (plenty of resources state it takes 25 minutes to get back into a flow state once interrupted).
Thus, for me, the meeting tax of scrum meetings alone is 13*15 = 195 minutes. Further, there is a conflict as projects have their own required meetings (if the scrum meetings are the only meetings, then seemingly the team is just talking once a day and then not again - that sounds bad! So yeah, there are other meetings too).
Further, not all 80 hours are equal. Software development is a highly creative field, it's not an assembly line with interchangeable parts. If you have your developers in office for 90 hours instead of 80 you're not going to get 10% more on your story point velocity. Similar for 70 hours vs 80, eventually there is a point of diminishing returns.
By measures of how long I can pair program with someone, 5 hours is a pretty upper limit on how long I can stay in a high productivity state for one day. Time spent in meetings can take away from that high productivity.
Let's say a person can generously be in a high productivity state for 6 hours per day and that meetings take away from that time, then we are very reasonably at 10.75/60 => ~18%*
*I'll emphasizes we are talking scrum meetings only, and still not even taking into account prep time for the scrum meetings
[1] https://resources.scrumalliance.org/Article/scrum-events
"The general rule of thumb is to allow two hours of sprint planning for every one week of sprint length. That means teams should timebox sprint planning to four hours for a two-week sprint and eight hours for a one-month sprint."
The 13% takes into account the time tax of context switching. 18% if we consider only (at best) 6 hours per day and meetings are taking away from that high productivity time (which is to say a greater proportion of time is spent around the coffee maker and not coding)
To go into detail, there is a tax to every meeting. With 13 scrum meetings this adds up fast. For me, as a remote worker, I stop everything 5 minutes before or else (for example) 1:57 is going to suddenly turn into 2:03 and then I'm late. Recovering from a meeting takes me about 10 minutes (plenty of resources state it takes 25 minutes to get back into a flow state once interrupted).
Thus, for me, the meeting tax of scrum meetings alone is 13*15 = 195 minutes. Further, there is a conflict as projects have their own required meetings (if the scrum meetings are the only meetings, then seemingly the team is just talking once a day and then not again - that sounds bad! So yeah, there are other meetings too).
Further, not all 80 hours are equal. Software development is a highly creative field, it's not an assembly line with interchangeable parts. If you have your developers in office for 90 hours instead of 80 you're not going to get 10% more on your story point velocity. Similar for 70 hours vs 80, eventually there is a point of diminishing returns.
By measures of how long I can pair program with someone, 5 hours is a pretty upper limit on how long I can stay in a high productivity state for one day. Time spent in meetings can take away from that high productivity.
Let's say a person can generously be in a high productivity state for 6 hours per day and that meetings take away from that time, then we are very reasonably at 10.75/60 => ~18%*
*I'll emphasizes we are talking scrum meetings only, and still not even taking into account prep time for the scrum meetings
[1] https://resources.scrumalliance.org/Article/scrum-events
"The general rule of thumb is to allow two hours of sprint planning for every one week of sprint length. That means teams should timebox sprint planning to four hours for a two-week sprint and eight hours for a one-month sprint."
At my previous job, the "daily stand up" never lasted less than 30min, and often times went to 2 hours. Also, I didn't just have one "daily stand up" but two! One with multiple teams, and one with just our team because our manager really wanted to silo our work and ignore as much as possible other teams (especially QA for some bizarre reason).
Yes, we weren't doing "scrum" right, but like communism, no one does it right.
Yes, we weren't doing "scrum" right, but like communism, no one does it right.
We manage short standups most of the time - why didn't you tell the manager to shut down after 15 minutes? All these agile processes require the team to take some responsibility and have some courage.
First, there was major miscommunication on the part of the new management [1] and who I thought was my manager wasn't [2]. Second, I was raising the alarm that the "agile and scrum" methods weren't working, and got it raised to a VP of the company [3]. He was let go. Did I cause him to be fired? I don't know. All I know, the new VP just said "that's a shame" when I brought up my points. I knew then, it was time to go.
[1] The silliness didn't start until new management took over.
[2] The term "team lead" meant "manager". I didn't get the memo.
[3] I was regularly talking to him at least once a week. He didn't want me to leave the company and to give him time.
[1] The silliness didn't start until new management took over.
[2] The term "team lead" meant "manager". I didn't get the memo.
[3] I was regularly talking to him at least once a week. He didn't want me to leave the company and to give him time.
It sounds more to me like you could have just asked for meetings to end on time and quoted why they are meant to be held standing up.
No, it was more like before they pushed "Enterprise Agile with a side of scrum", the team I was on, for 10 years, produced code on time, with very few bugs and only two regressions to production (caught during deployment). Afterwards (bought out, new management), we kept missing our deadlines, bugs proliferated, and deployments became nightmares. The meetings were the least of the issues, but they weren't helping any.
Not that I disagree with you, but I read your message as: "managers suck, so I found a way to work around them".
It is a bit sad, but that is my experience as well. I had one good manager in my 12 years experience. I had to work around the rest.
It is a bit sad, but that is my experience as well. I had one good manager in my 12 years experience. I had to work around the rest.
The proper way to fight scrum is simply doing scrum properly.
Nobody usually wants this.
For developers scrum is actually quite nice. The main success metric is predictability, i.e. the team is held accountable for delivering the sprint successfully. Which means you're supposed to be left alone while the sprint is ongoing.
Some bug? Pfft, if not critical, will maybe take it next sprint.
Finance needs a new report, pronto? Sure, let's talk about business value for priorization. And earliest next sprint anyway.
CEO has a crazy idea that he wants somebody to pull off? Sure, but please talk to Product.
What do you mean, you need more story points delivered per sprint?
The main issue is there are actually people that thrive in this kind of bureaucrazy. I've seen a number of 20-something POs burning themselves over these shitty processes.
Nobody usually wants this.
For developers scrum is actually quite nice. The main success metric is predictability, i.e. the team is held accountable for delivering the sprint successfully. Which means you're supposed to be left alone while the sprint is ongoing.
Some bug? Pfft, if not critical, will maybe take it next sprint.
Finance needs a new report, pronto? Sure, let's talk about business value for priorization. And earliest next sprint anyway.
CEO has a crazy idea that he wants somebody to pull off? Sure, but please talk to Product.
What do you mean, you need more story points delivered per sprint?
The main issue is there are actually people that thrive in this kind of bureaucrazy. I've seen a number of 20-something POs burning themselves over these shitty processes.
50%?? Scrum is like a 1-2 hour planning/retrospective meeting per fortnight plus 10-15 minute standups every 1-2 days. How could that possibly take 50% of your time?
I once had twice weekly refinement sessions 1 hour each. twice weekly grooming sessions one hour each. daily standups 30 minutes, weekly planning 2 hours, weekly retro 2 hours. This was industry standard according to the consultants brought in with mckinsey to train the whole company. 10.5 hours before any other technical meetings,
That's extremely unusual. Very few companies do that for obvious reasons.
Ugh, swapping out a successful development paradigm midstream sounds like somebody up the chain thinks change is the same thing as progress.
In situations like this, one strategy I have used (not for Scrum, but for people who want to tinker with shit for the sake of tinkering) is to say: "Great, we welcome experimentation, this is really cool. What will we measure to decide whether this change is improving our process, and how long will the initial round of experiments last?"
Because: this frames it as something we are trying together rather than something they are dictating, but also something that is not necessarily permanent, which can be changed in the future (including changed back to the way it was), and which is oriented around measurable improvement rather than arbitrary whims. Almost nobody is willing to be the guy who says "we'll do it my way because I said so, even if it makes everything worse", and if they are, that in itself gives you some valuable information about your manager or leadership team.
In situations like this, one strategy I have used (not for Scrum, but for people who want to tinker with shit for the sake of tinkering) is to say: "Great, we welcome experimentation, this is really cool. What will we measure to decide whether this change is improving our process, and how long will the initial round of experiments last?"
Because: this frames it as something we are trying together rather than something they are dictating, but also something that is not necessarily permanent, which can be changed in the future (including changed back to the way it was), and which is oriented around measurable improvement rather than arbitrary whims. Almost nobody is willing to be the guy who says "we'll do it my way because I said so, even if it makes everything worse", and if they are, that in itself gives you some valuable information about your manager or leadership team.
It never occured to me that the change can be framed this way, I will learn from this.
I thank you for this perspective kind stranger, truly.
I thank you for this perspective kind stranger, truly.
My most informative experience was had at this huge auction company that I was doing frontend on. At one point, I was working on what we'd now call a component, but was at that time manually created dom elements generated with a very long series of logic branches that depended on a number of external, possibly async conditions. It was extremely hard and time consuming to test and keep all of the possible conditions loaded into my consciousness with all of the chatter in the surrounding space and some fuckhead making sales calls on his phone and typing on his mechanical keyboard—because y'know, everyone's gotta be in the same room—meanwhile the product owner would come over to add new requirements while I was trying to focus and then the scrum master would come over to ask why I wasn't done yet. This went on until my productivity and motivation ground to a halt, I burnt out, got depressed, and got fired. However, when I started at the company, it was surprisingly fine. I worked with two other guys collaboratively on some tricky frontend issues, which we solved, and it was fine.
scrum masters should only bother you at the standup. They also shouldn't add requirements.
So .... the one you were dealing with was just an average bullshitter pretending to do scrum.
So .... the one you were dealing with was just an average bullshitter pretending to do scrum.
The product owner was typically changing requirements, Scrum Master I think realized they had no functional role and tried to be a busybody.
Either way, it was awful, and it was looked down upon to try and find some peace and quiet to actually get things done.
Either way, it was awful, and it was looked down upon to try and find some peace and quiet to actually get things done.
Well, a sprint is a contract - people are not allowed to change the deal in the middle and if they are then the PO isn't doing their job. They're really there to defend the team from pesky customers and prioritise work so that you DO have peace and quiet.
I get that this often doesn't work because individuals don't really grasp their function properly and don't defend or don't prioritise and then that part of the scheme cannot work. Sometimes the company structure makes the POs too scared to standup. IMO that would be a problem without scrum.
I get that this often doesn't work because individuals don't really grasp their function properly and don't defend or don't prioritise and then that part of the scheme cannot work. Sometimes the company structure makes the POs too scared to standup. IMO that would be a problem without scrum.
I don't think much of that is true at all if the result of their role is supposed to be remotely inspired by Agile, but yes it's the structure screwing it up and individuals just following along.
More likely they'll just blame you, just like the sibling comment says...
Their goal was never increased productivity and developer hapiness. It was literally what they said "introducing scrum and bringing in a scrum master". Their purpose is to add and manage processes (bureucratic layers) and increase their dependants.
Their goal was never increased productivity and developer hapiness. It was literally what they said "introducing scrum and bringing in a scrum master". Their purpose is to add and manage processes (bureucratic layers) and increase their dependants.
In many companies headcount = power. You getting a ton of work done with a small team matters less than Bruce with his 50 reports and $6m budget for them.
Middle managers will always increase headcount so that they eventually can become directors. Oldest game in business.
Middle managers will always increase headcount so that they eventually can become directors. Oldest game in business.
aka: micro-manage, because they don’t understand the effort and cost…or if you’re cynical because you’ve experienced it, some middle manager desperately needs to control other people because they subconsciously know their position is 90% absolute dead weight. Maybe that’s a bit too negative, sorry.
> After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time.
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
Oh wait till management finds engineers to scapegoat for their own decisions. If there is one truth about management, it is that they cannot accept "I told you so" from their reports.
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
Oh wait till management finds engineers to scapegoat for their own decisions. If there is one truth about management, it is that they cannot accept "I told you so" from their reports.
Of course. Because they don't produce outputs directly, reputation is all a manager has to prove their worth to the company. If you take that away by publicly demonstrating how their actions caused bad results, their boss might well fire them since they are apparently being a net negative. Managers face a much more difficult labor market than most engineers too.
So to exaggerate a little bit, not accepting "I told you so" from their reports is directly required to keep paying their mortgage and feeding their children. It's not weird that they get upset when you endanger their livelihood. OP has got the right idea and is just being zen about it IMO.
So to exaggerate a little bit, not accepting "I told you so" from their reports is directly required to keep paying their mortgage and feeding their children. It's not weird that they get upset when you endanger their livelihood. OP has got the right idea and is just being zen about it IMO.
You are not wrong. We both agree that the problem is the org structure as it stands. The incentives for layers and layers of management are divergent from the needs of the business and the needs of the producers of output.
Perhaps we need to reduce the number of levels, replace managers with technical leaders whose incentives are aligned with the needs of the business. Offload all grunt paper work to an executive assistant.
No need for EM1, EM2, EM3, Director, Sr Director, VP, SVP, SSVP nonsense.
Perhaps we need to reduce the number of levels, replace managers with technical leaders whose incentives are aligned with the needs of the business. Offload all grunt paper work to an executive assistant.
No need for EM1, EM2, EM3, Director, Sr Director, VP, SVP, SSVP nonsense.
> Managers face a much more difficult labor market than most engineers too.
Indeed. I've been thinking about shifting back into management after a couple years as an individual contributor (playing an instrument is fun, but so is conducting a well functioning orchestra). In this space, aligning with stereotypes has become very important in the past decade or so.
Indeed. I've been thinking about shifting back into management after a couple years as an individual contributor (playing an instrument is fun, but so is conducting a well functioning orchestra). In this space, aligning with stereotypes has become very important in the past decade or so.
Yet to find a company where the folks down the reporting ladder can rate how they perceived various initiatives to have gone. So weird how businesses just don't want to hear how "Implement formal agile process" (or other goals) went.
It's because companies are far more obsessed with power structures than with actual output. This is especially true for public companies where the grift is to get into positions of power, propose "initiatives", find scapegoats for failures, then hop on to another company - leaving a trail of damage behind.
In my experience, the only time a company does well with structures is when there are fewer levels in the org chart and when the C-Suite penalizes management before ICs.
Doesn't happen very often though.
In my experience, the only time a company does well with structures is when there are fewer levels in the org chart and when the C-Suite penalizes management before ICs.
Doesn't happen very often though.
I am curious, how did management respond when the progress slowed
did they revert back to the old method, did it deteriorate so fast there was no way to stop it, was the team not very important
what happened ?
did they revert back to the old method, did it deteriorate so fast there was no way to stop it, was the team not very important
what happened ?
Standard playbook in this situation is everyone involved saves face by blaming the team who were driven out, then they adjust to the new normal and everyone forgets they were ever able to build and ship software.
Their view was that there was no problem, but rather that the new process was an improvement. I am not joking.
They said that we didn't measure the work before, so they had no visibility into how much the team does. But after introducing scrum, they were very happy to see that the team usually delivered around 20 story points per sprint, while the other teams in the company did around 10.
In my view, if we estimated tickets in old process as we did after introducing scrum, we would have been delivering around 60 points in two weeks through old process.
They said that we didn't measure the work before, so they had no visibility into how much the team does. But after introducing scrum, they were very happy to see that the team usually delivered around 20 story points per sprint, while the other teams in the company did around 10.
In my view, if we estimated tickets in old process as we did after introducing scrum, we would have been delivering around 60 points in two weeks through old process.
> how did management respond when the progress slowed
Rule number 1: management is never wrong. The progress did not slow down.
Rule number 1: management is never wrong. The progress did not slow down.
this would be an example to be studied in future classes of business school if this resulted in a change like you would hope for. otherwise, it's business as usual, and no, the changes you seek would not happen.
i'm obviously turning this into a hypothetical
i'm obviously turning this into a hypothetical
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master
Well, if there was a distinct Product Owner and they delegated this to the Scrum Master, it may have been by-the-Guide Scrum, but just extraordinarily poor judgement.
But it sounds like you had a dev team that wasn’t using Scrum, got a Scrum Master and no P.O., and gave the Scrum Master some or all of the P.O. duties. Even as weakly prescriptive as the current Scrum Guide is, that's still not real Scrum.
(Moreover, most places that purport to do Scrum also purport to do Agile, and having a bottleneck between the team and client is even more explicitly not Agile than it is not Scrum.)
Which is not to say your scenario isn’t a valid illustration of problems with Scrum (or Agile) in terms of the (largely cargo-cult) common behavior going under the name.
Its just that in terms of clarity of discussion of what practices should be adopted, its worth noting that the problems being identified are with practices which the Scrum Guide (at the organizational level) and Agile Manifesto (and the broad practice level) are pretty explicitly directed against. Not just in terms of the communication bottleneck but also things like:
> tickets taking exactly one sprint to complete
This seems to be confusing increments or Sprint Backlog items (for which the dev team is responaible for making from Product Backlog items) with Product Backlog items that the P.O. is responsible for (and also Product Backlog items with client tickets, though the Scrum Guide doesn't explicitly discuss client tickets at all — in fact, it mentions customers only once — and so doesn’t explicitly distinguish them from Product Backlog items. The P.O. is free to, and responsible for, structure Product Backlog items optimally based on achieving customer goals, which is almost never realistically going to be 1:1 with tickets.)
EDIT: I want to make extra clear that I am neither disagreeing with the criticism of “Scrum as the thing that I am likely to have imposed on me if my workplace says they are doing Scrum” nor arguing that the Scrum Guide (or Agile Manifesto and principals) are anything like perfect edicts that can only be failed but never fail.
I am just saying it is important to recognize the difference between “this failure is caused by a set of practices a workplace adopted under the label ‘Scrum’” and “this failure is caused by adopting the practices described in the Scrum Guide”, eepecially if you are interested in what good practices might be.
Well, if there was a distinct Product Owner and they delegated this to the Scrum Master, it may have been by-the-Guide Scrum, but just extraordinarily poor judgement.
But it sounds like you had a dev team that wasn’t using Scrum, got a Scrum Master and no P.O., and gave the Scrum Master some or all of the P.O. duties. Even as weakly prescriptive as the current Scrum Guide is, that's still not real Scrum.
(Moreover, most places that purport to do Scrum also purport to do Agile, and having a bottleneck between the team and client is even more explicitly not Agile than it is not Scrum.)
Which is not to say your scenario isn’t a valid illustration of problems with Scrum (or Agile) in terms of the (largely cargo-cult) common behavior going under the name.
Its just that in terms of clarity of discussion of what practices should be adopted, its worth noting that the problems being identified are with practices which the Scrum Guide (at the organizational level) and Agile Manifesto (and the broad practice level) are pretty explicitly directed against. Not just in terms of the communication bottleneck but also things like:
> tickets taking exactly one sprint to complete
This seems to be confusing increments or Sprint Backlog items (for which the dev team is responaible for making from Product Backlog items) with Product Backlog items that the P.O. is responsible for (and also Product Backlog items with client tickets, though the Scrum Guide doesn't explicitly discuss client tickets at all — in fact, it mentions customers only once — and so doesn’t explicitly distinguish them from Product Backlog items. The P.O. is free to, and responsible for, structure Product Backlog items optimally based on achieving customer goals, which is almost never realistically going to be 1:1 with tickets.)
EDIT: I want to make extra clear that I am neither disagreeing with the criticism of “Scrum as the thing that I am likely to have imposed on me if my workplace says they are doing Scrum” nor arguing that the Scrum Guide (or Agile Manifesto and principals) are anything like perfect edicts that can only be failed but never fail.
I am just saying it is important to recognize the difference between “this failure is caused by a set of practices a workplace adopted under the label ‘Scrum’” and “this failure is caused by adopting the practices described in the Scrum Guide”, eepecially if you are interested in what good practices might be.
I'm reminded of Ben's question about the shamble-men in The Name of the Wind [0]. It doesn't particularly matter whether people are disappearing because of shamble-men or because of bears and wolves, if people are regularly disappearing in the woods then you'd do well to steer clear of them.
In the same way, I don't particularly care if Scrum fails because people consistently fail to implement it "right" or if it fails because it's a flawed concept at its heart. Either way, odds are that my team will suffer if we introduce Scrum: if Scrum isn't fundamentally flawed, it's still hubris to assume that we'll be the team that finally gets it right.
[0]
> “Listen, if tomorrow we pulled into Biren and someone told you there were shamble-men in the woods, would you believe them?” My father shook his head.
> “What if two people told you?” Another shake.
> Ben leaned forward on his stump. “What if a dozen people told you, with perfect earnestness, that shamble-men were out in the fields, eating—”
> “Of course I wouldn’t believe them,” my father said, irritated. “It’s ridiculous.”
> “Of course it is,” Ben agreed, raising a finger. “But the real question is this: Would you go into the woods?”
In the same way, I don't particularly care if Scrum fails because people consistently fail to implement it "right" or if it fails because it's a flawed concept at its heart. Either way, odds are that my team will suffer if we introduce Scrum: if Scrum isn't fundamentally flawed, it's still hubris to assume that we'll be the team that finally gets it right.
[0]
> “Listen, if tomorrow we pulled into Biren and someone told you there were shamble-men in the woods, would you believe them?” My father shook his head.
> “What if two people told you?” Another shake.
> Ben leaned forward on his stump. “What if a dozen people told you, with perfect earnestness, that shamble-men were out in the fields, eating—”
> “Of course I wouldn’t believe them,” my father said, irritated. “It’s ridiculous.”
> “Of course it is,” Ben agreed, raising a finger. “But the real question is this: Would you go into the woods?”
> It doesn't particularly matter whether people are disappearing because of shamble-men or because of bears and wolves, if people are regularly disappearing in the woods then you'd do well to steer clear of them.
“Steer clear of things called Scrum” is a very limited guide to how to develop software, actually figuring out what the methodological pitfalls are and addressing them is something that is, I would submit, worth pursuing in more detail, especially for people who have some influence over substantive development methodology choices, rather than only having a choice of whether or not to avoid some place that is imposing a thing that they call “Scrum”. (And, really, you should probably steer clear of any place where being in the dev team gives you no input on substantive methodological decisions irrespective of whether what is imposed is called “Scrum”.)
“Steer clear of things called Scrum” is a very limited guide to how to develop software, actually figuring out what the methodological pitfalls are and addressing them is something that is, I would submit, worth pursuing in more detail, especially for people who have some influence over substantive development methodology choices, rather than only having a choice of whether or not to avoid some place that is imposing a thing that they call “Scrum”. (And, really, you should probably steer clear of any place where being in the dev team gives you no input on substantive methodological decisions irrespective of whether what is imposed is called “Scrum”.)
I'm not suggesting that "don't call it Scrum" be the final word in software development methodology.
I am suggesting that calling it Scrum will increase your risk of failure, and you'll likely be better off choosing a completely different methodology that has more consistency in implementation and a higher success rate.
By all means let's dig into what specific details of the implemented methodologies work well and which don't! But taking the output of that process and calling it "Real Scrum™" will just lead to further confusion.
I am suggesting that calling it Scrum will increase your risk of failure, and you'll likely be better off choosing a completely different methodology that has more consistency in implementation and a higher success rate.
By all means let's dig into what specific details of the implemented methodologies work well and which don't! But taking the output of that process and calling it "Real Scrum™" will just lead to further confusion.
> By all means let's dig into what specific details of the implemented methodologies work well and which don't! But taking the output of that process and calling it "Real Scrum™" will just lead to further confusion.
I’m not saying “Real Scrum™” should be the name of the output. I’m saying that diagnosing the problem is obscured by not distinguishing between “what is in the Scrum Guide” and “what someone is doing and calling Scrum”, especially as the latter can be a diversity of mutually incompatible approaches.
I’m not saying “Real Scrum™” should be the name of the output. I’m saying that diagnosing the problem is obscured by not distinguishing between “what is in the Scrum Guide” and “what someone is doing and calling Scrum”, especially as the latter can be a diversity of mutually incompatible approaches.
You're surely getting downvoted and lumped as one of the "but that wasn't real scrum" types, but this strikes me as unfair. I am highly critical of scrum, and have had many of the "that's not scrum" variety dismiss criticism, but yours is actually thoughtful and (indirectly) makes a good point: some people really do deviate from "real scrum" substantially. I hate scrum with a passion, but if we just do the inverse argument of blanket dismissing any criticism under "oh you're one of those" then we're being as intellectually dishonest as the "that's not real scrum" crowd (and for the record I don't include you in that crowd).
I appreciate you being willing to articulate an unpopular opinion :-)
I appreciate you being willing to articulate an unpopular opinion :-)
So, would it be fair to summarize this as, "You weren't doing True Scrum" ?
Yes I think so, but GP did point to actual specifications as justification. I hate the "you weren't doing real scrum" replies, but I don't think GP was doing that.
No, it would be fair to summarize this as “’Scrum’ is used so inconsistency that trying to evaluate ‘Scrum’ is of no value; it is worth evaluate specific practices and well-defined collections of practices including ‘the set of practices described in the Scrum Guide’, and, if you are evaluating that particular set of practices, it is worth noting that the example cited is not an example of them.”
Much less TLDRish, but zooming out to take a broader perspective:
There seems to be an intense agreement with both of the following statements:
1. The practices in the industry that the people imposing them call “Scrum” are often quite bad, and
2. The practices in the industry that the people imposing them call “Scrum” often bear very little relationship to the methodology laid out in any version of the Scrum Guide.
Apparently because consensus is a bad thing and there aren’t enough real issues to argue about, some people who agree on points #1 and #2 seem to have squared off into a weird tribal battle over whether “Scrum” is bad due to #1 specifically that mostly turns on whether or not the One True Meaning of “Scrum”” is the thing they agree is very often bad in #1 or the thing they agree that thing differ differs from in #2. My position is that this is mostly silly, especially since there are very few contexts where both of those things are meaningful to consider: the first is so inconsistent in terms of actual practices that it is useless describe as a single thing in the context of concrete development practice, though it may be interesting to discuss as an industry cultural phenomenon, whereas particular practices or combinations of practices within its ambit can be discussed more productively when the focus is on concrete development practice; the second is specific enough to be useful to discuss in the context of concrete development practices, but not much else, except maybe in terms of its historical role in relation to the cultural phenomenon. With a little care to being clear what they are talking about and the what it is people are looking for from a discussion, the whole semantic side-debate can be avoided.
Much less TLDRish, but zooming out to take a broader perspective:
There seems to be an intense agreement with both of the following statements:
1. The practices in the industry that the people imposing them call “Scrum” are often quite bad, and
2. The practices in the industry that the people imposing them call “Scrum” often bear very little relationship to the methodology laid out in any version of the Scrum Guide.
Apparently because consensus is a bad thing and there aren’t enough real issues to argue about, some people who agree on points #1 and #2 seem to have squared off into a weird tribal battle over whether “Scrum” is bad due to #1 specifically that mostly turns on whether or not the One True Meaning of “Scrum”” is the thing they agree is very often bad in #1 or the thing they agree that thing differ differs from in #2. My position is that this is mostly silly, especially since there are very few contexts where both of those things are meaningful to consider: the first is so inconsistent in terms of actual practices that it is useless describe as a single thing in the context of concrete development practice, though it may be interesting to discuss as an industry cultural phenomenon, whereas particular practices or combinations of practices within its ambit can be discussed more productively when the focus is on concrete development practice; the second is specific enough to be useful to discuss in the context of concrete development practices, but not much else, except maybe in terms of its historical role in relation to the cultural phenomenon. With a little care to being clear what they are talking about and the what it is people are looking for from a discussion, the whole semantic side-debate can be avoided.
Unfortunately, "scrum master" is an actual job classification. So the true meaning of it, whatever that is, has escaped into the wild.
"if everyone is productive, don't hire a manager, promote." applies here.
If scrum isn't working for you and you're productive, do more of that.
If what you have isn't working, and scrum might help. Do that.
That's the point. Don't break something just because others are doing it.
If scrum isn't working for you and you're productive, do more of that.
If what you have isn't working, and scrum might help. Do that.
That's the point. Don't break something just because others are doing it.
Real Scrum has never been tried.
True Scrumunism? :)
In Scrumunism complexity puts the points on you!
Well, technically OP described anarcho-development.
If you've got people who don't need bosses, that can work really well. If you impose clueless bosses on those who don't need them, they will often leave.
No True Scrummist
Scrum can never fail, only be failed.
What (or who) made them decide they needed scrum in the first place?
IME, it's usually a new hire, usually a product person. There's always pressure on those people to introduce changes to increase whatever the KPI metric is, and from their perspective scrum is a great choice. Plus management drools over data/metrics, no matter how much you explain to them that there are serious flaws with the data. You get more of what you measure, and the law of unintended consequence can be a beast. I've seen people come under the Eye of Sauron because they weren't closing as many "story points" as their peers. In reality it's because this person was the best mentor on the team, and the most experienced in the codebase. They spent most of their time pairing and training others, but only one person gets to make the commit and claim the points. That person initially stopped helping people and would (understandably) get irritable when asked questions, and then left the company. Management considered it a win to dispense with a "low velocity" engineer. It hurts my soul to think about the stupidity, especially since they were told numerous times that this person was the MVP of the team, no matter what the metrics said. You get more of what you measure.
Scrum master name is supposed to be joke, like dungeon master. They are supposed to lead the process of scrum and stay in the background.
This was exactly my experience, but many more months than 3.
gumballindie(1)
This wasn't scrum because talking to the costumer is the primary job of the Product Owner and not of the Scrum Master. PO is also a full time job and not some side hustle of a team lead or SM. Having a good Product Owner
makes the difference between adopting scrum successfully or failing at this process.
Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple - no one in your team was open to adopting scrum so it failed. That's fine but it's not the fault of scrum rather than the company management.
Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple - no one in your team was open to adopting scrum so it failed. That's fine but it's not the fault of scrum rather than the company management.
I honestly can't tell, because you don't have a history of joke comments and didn't include a /s. Is this intentional parody, or did you miss OP's closing line?
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
> Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)
His point is not exactly invalid though?
If you go into something with the intention of 'this sucks' and then do not even want to make it work would it not reason that it probably will fail?
Scrum usually fails because people become enamored with the process instead of thinking about what that process is for. Layering on more and more of it because something is not working. Until you are busy with 40% of your time just managing scrum. Something in scrum not working throw it out. Do not double down and add more.
If you go into something with the intention of 'this sucks' and then do not even want to make it work would it not reason that it probably will fail?
Scrum usually fails because people become enamored with the process instead of thinking about what that process is for. Layering on more and more of it because something is not working. Until you are busy with 40% of your time just managing scrum. Something in scrum not working throw it out. Do not double down and add more.
> if you go into something with the intention of 'this sucks' and then do not even want to make it work
we can rephrase this as "the serum didn't work because you didn't have faith in it."
we can rephrase this as "the serum didn't work because you didn't have faith in it."
Expanding on that, scrum is a religion. Like many/most religions, it requires faith, and that a lack of faith is singularly responsible for any failure of said belief/religion to deliver its promises.
I agree completely about scrum being a religion and lack of faith and all that, and I can't stand the "but that wasn't real scrum" automatic response that most of the defenders make.
But the GP point is valid. not every iteration can be blamed on "scrum" anymore than anything bad that happens in life can be blamed on Satan. If people want it to fail, they can make it fail.
But that said, to slightly counter my own point: I think that demonstrates a weakness with Scrum. If people following the system (even malicous compliance) can make it fail, then the system is flawed. It obviously sucks for those people or they wouldn't have a bad attitude about it. For example, Scrum likes to pretend that all engineers are fungible, but this is clearly wrong and a big problem with the system.
But the GP point is valid. not every iteration can be blamed on "scrum" anymore than anything bad that happens in life can be blamed on Satan. If people want it to fail, they can make it fail.
But that said, to slightly counter my own point: I think that demonstrates a weakness with Scrum. If people following the system (even malicous compliance) can make it fail, then the system is flawed. It obviously sucks for those people or they wouldn't have a bad attitude about it. For example, Scrum likes to pretend that all engineers are fungible, but this is clearly wrong and a big problem with the system.
No. The doctor told you to take care of yourself but you went to McDonald's again.
People are stuck in their ways and don't actually want to try anything new. That's why management always fails- you can't manage people.
People are stuck in their ways and don't actually want to try anything new. That's why management always fails- you can't manage people.
> People are stuck in their ways and don't actually want to try anything new
Those damn people. Business would go so much better if you didn't have to hire them /s
Those damn people. Business would go so much better if you didn't have to hire them /s
I can't tell if you are saying Scrum socks when people hate it or when people are enamored with it. I guess it will work if everybody is casually indifferent?
Scrum sucks when people ignore why they are using it and decide to use it just because everyone else is. indifference is usually the root cause of broken scrum. No one speaking up and saying 'lets fix this'. Things piled on for no real reason but not thrown out when they are shown to just be in the way. Throw in a 'bad actor' and yeah it can really suck but then the whole job will anyway no matter what your process. No one really wants to work with a grumpy person. That is not the fault of scrum that is a organization/people problem.
> Regarding why your team failed - i've been in a similiar scenario like you as a team lead. The answer is simple - no one in your team was open to adopting scrum so it failed. That's fine but it's not the fault of scrum rather than the company management.
How do you know no one was open to trying it? I specifically mentioned that I personally objected to scrum, but wrote nothing about other people.
What happened in fact was that people initially really tried their best ti cooperate, but it simply didn't work very well and crippled the team.
How do you know no one was open to trying it? I specifically mentioned that I personally objected to scrum, but wrote nothing about other people.
What happened in fact was that people initially really tried their best ti cooperate, but it simply didn't work very well and crippled the team.
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.
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.
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.
> 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.
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.
> 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.
Story of my life! And I guess it is the case for most competent employees unfortunately.
I'm also wondering whether using Scrum somehow makes your team become this dysfunctional COBOL programmer team...
The reply to that comment is also valid, IMHO
> 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.
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.
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.
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.
> 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.
Yes I think you got to the crux here - managers want to be indispensable and make everyone else "a machine" so he told you a bunch of self-serving bs. I'm sure if you turn this around on him then project manager will not be a machine but more like a wizard or an artist whose needs must be carefully tended =)
> 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.
Right and who is better to help here than someone who can take business requirements and hand them to the engineers? You know, someone who got people skills!
Yes I think you got to the crux here - managers want to be indispensable and make everyone else "a machine" so he told you a bunch of self-serving bs. I'm sure if you turn this around on him then project manager will not be a machine but more like a wizard or an artist whose needs must be carefully tended =)
> 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.
Right and who is better to help here than someone who can take business requirements and hand them to the engineers? You know, someone who got people skills!
[deleted]
"Software engineer" is a special category in that people think you can train someone for 3 months on React and Node and shove them into this line of work and they should be fungible and just a green version of the real thing.
The high demand, high pay and low general understanding of computer architecture all fuel this race to the bottom and we all pay for it in low quality, overtly complicated and vulnerable software and all ancillary industries that spring around it. Coding "bootcamps", "Cybersecurity", Agile/SCRUM, Wordpress and clones, AWS and clones etc etc.
The high demand, high pay and low general understanding of computer architecture all fuel this race to the bottom and we all pay for it in low quality, overtly complicated and vulnerable software and all ancillary industries that spring around it. Coding "bootcamps", "Cybersecurity", Agile/SCRUM, Wordpress and clones, AWS and clones etc etc.
Having been on both sides of this, and having worked closely with "the business" doing requirements analysis, project management, tech-leading and individual development, my conclusion was that your original view is somewhat closer to the right one than the PMs.
One may ask, from where does the tech industry come from? From where tech startups come from? Why is there such a thing as the "tech" industry at all? Don't all companies use tech? We don't talk about the "science industry", do we? If you try and find a definition of tech firm that captures what people mean when they say this, you'll conclude they're basically either computer companies or ordinary firms doing ordinary things, who use computers more effectively than normal. And in the latter case what makes a firm a tech firm is basically unarticulated, people know it when they see it but it's not like there's a set of rules to classify, say, Netflix as a tech firm and Disney as not a tech firm.
So what is it that people see? Mostly it's the distinctive culture that appears when you have (ex-)programmers at the very top of the company, as in CEO and/or board level. This causes companies to differ in all sorts of ways, but one way in which tech firms differ, for example, is that in tech firms you don't get terms like "the business" and "IT". You don't get non-technical project managers. The distinction between the two sides simply doesn't exist.
Non-tech firms live in fear of tech firms and startups. It took me a while to notice this, but go to enough conferences, talk to enough people and you'll see it. The average firm is far more scared of Google or Apple encroaching on their space than they are of an established competitor. This is because tech firm culture is more effective than their own. Such firms have a long history of coming from nowhere to utterly dominate entire industries very fast, and they don't know how to respond to it.
The cultural problems can be seen in the stories you were told. Programmers who understand the business are too expensive. They get ideas. They get passionate, and that's a problem. In a tech firm, experienced devs who understand business end up at director level or higher and firms compete to pay them the best. In non tech firms, they are a problem and get pushed out. This is because the business people are scared of such devs because senior developers end up understanding the business better than the business people do. After all, they implemented the business logic so every rule, regulation and detail is in their mind. And they're used to the rigor demands of programming, so tend to say awkward things in meetings like "that won't work" or "that contradicts the other thing you just said". Tech firms don't mind this because that guy's boss is himself a former developer, and is used to such discussions (from e.g. code or design reviews). "Business people" on the other hand aren't used to this at all, yet feel like their value is their business understanding. They need their devs to be bored and uncaring drones because otherwise what's their own value? You don't want to be competing for a promotion against someone whose understanding of the business is better than yours and who can actually execute change projects effectively!
Underlying all this of course is the uncomfortable fact that programming is much harder than most office jobs. Programmers can and will learn programming and then go on to learn the fine details of finance, accounting or shipping without breaking a sweat, but the reverse is generally not true. It was maybe to some extent in the Visual Basic era but the move to web apps put a stop to gifted amateurs cobbling together business apps and nothing really replaced it (maybe Oracle APEX but it's not as widely used).
One may ask, from where does the tech industry come from? From where tech startups come from? Why is there such a thing as the "tech" industry at all? Don't all companies use tech? We don't talk about the "science industry", do we? If you try and find a definition of tech firm that captures what people mean when they say this, you'll conclude they're basically either computer companies or ordinary firms doing ordinary things, who use computers more effectively than normal. And in the latter case what makes a firm a tech firm is basically unarticulated, people know it when they see it but it's not like there's a set of rules to classify, say, Netflix as a tech firm and Disney as not a tech firm.
So what is it that people see? Mostly it's the distinctive culture that appears when you have (ex-)programmers at the very top of the company, as in CEO and/or board level. This causes companies to differ in all sorts of ways, but one way in which tech firms differ, for example, is that in tech firms you don't get terms like "the business" and "IT". You don't get non-technical project managers. The distinction between the two sides simply doesn't exist.
Non-tech firms live in fear of tech firms and startups. It took me a while to notice this, but go to enough conferences, talk to enough people and you'll see it. The average firm is far more scared of Google or Apple encroaching on their space than they are of an established competitor. This is because tech firm culture is more effective than their own. Such firms have a long history of coming from nowhere to utterly dominate entire industries very fast, and they don't know how to respond to it.
The cultural problems can be seen in the stories you were told. Programmers who understand the business are too expensive. They get ideas. They get passionate, and that's a problem. In a tech firm, experienced devs who understand business end up at director level or higher and firms compete to pay them the best. In non tech firms, they are a problem and get pushed out. This is because the business people are scared of such devs because senior developers end up understanding the business better than the business people do. After all, they implemented the business logic so every rule, regulation and detail is in their mind. And they're used to the rigor demands of programming, so tend to say awkward things in meetings like "that won't work" or "that contradicts the other thing you just said". Tech firms don't mind this because that guy's boss is himself a former developer, and is used to such discussions (from e.g. code or design reviews). "Business people" on the other hand aren't used to this at all, yet feel like their value is their business understanding. They need their devs to be bored and uncaring drones because otherwise what's their own value? You don't want to be competing for a promotion against someone whose understanding of the business is better than yours and who can actually execute change projects effectively!
Underlying all this of course is the uncomfortable fact that programming is much harder than most office jobs. Programmers can and will learn programming and then go on to learn the fine details of finance, accounting or shipping without breaking a sweat, but the reverse is generally not true. It was maybe to some extent in the Visual Basic era but the move to web apps put a stop to gifted amateurs cobbling together business apps and nothing really replaced it (maybe Oracle APEX but it's not as widely used).
> > 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.
It's harder than finding uncaring juniors, sure.
But if you need 40+6 people, or 6 experienced people, that's nearly 8x salary.
In silicon valley money, you'll need to pay those uncaring juniors about 150K.
I guarantee you that you can very easily find those 6 experienced people in a few weeks if you're offering over $1M/yr to them. In a month you can staff all 6 positions.
If you're saying you want ~8x performance but not interested in paying ~8x salary.. then yes, it's harder to find the people.
> The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
It's harder than finding uncaring juniors, sure.
But if you need 40+6 people, or 6 experienced people, that's nearly 8x salary.
In silicon valley money, you'll need to pay those uncaring juniors about 150K.
I guarantee you that you can very easily find those 6 experienced people in a few weeks if you're offering over $1M/yr to them. In a month you can staff all 6 positions.
If you're saying you want ~8x performance but not interested in paying ~8x salary.. then yes, it's harder to find the people.
The problem is that I'm not talking about Silicon Valley, it's an anomaly within an anomaly when it comes to hiring.
I'm pretty sure that short of John Carmack or a legend of that caliber I can't justify paying 1M to _anyone_ to the people making the budget.
Of course you can grab a half dozen superstars if you pay them a million per head, but they'll also leave the second the job stops being 100% interesting.
That's not a sustainable way to build a company or a team.
I'm pretty sure that short of John Carmack or a legend of that caliber I can't justify paying 1M to _anyone_ to the people making the budget.
Of course you can grab a half dozen superstars if you pay them a million per head, but they'll also leave the second the job stops being 100% interesting.
That's not a sustainable way to build a company or a team.
In Japan they are struggling even to find juniors because of the declining population.
Yea, they f'd up a whole generation because of TRADITION.
There was a good video about this but the tl;dw is about this:
In Japan you're supposed to get hired straight out of school and then you'll stay with The Company until you retire.
The same tradition implies that The Company will _never_ fire people.
Japan faced some very hard times. Companies couldn't afford to hire new people because they couldn't fire the older people.
A whole generation never really entered the workforce because they never got the experience. Now they're mostly doing odd jobs and for the same reason never got married and had children.
Oopsie.
There was a good video about this but the tl;dw is about this:
In Japan you're supposed to get hired straight out of school and then you'll stay with The Company until you retire.
The same tradition implies that The Company will _never_ fire people.
Japan faced some very hard times. Companies couldn't afford to hire new people because they couldn't fire the older people.
A whole generation never really entered the workforce because they never got the experience. Now they're mostly doing odd jobs and for the same reason never got married and had children.
Oopsie.
> The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
That’s not the only cause with all due respect, I have worked with several C-level managers before, they WANT those mid-low level developers/engineers, they are cheaper and easy to find like you said, but most importantly, they can replace them on a whim with another one who will do the same work, with “super” engineers, it isn’t the case, the amount of knowledge and depth one of them has, you will need a whole team to understand what’s going on first and another to carry on the job, and C-levels being egoistic, they don’t like anyone to have any leverage by any means.
That’s not the only cause with all due respect, I have worked with several C-level managers before, they WANT those mid-low level developers/engineers, they are cheaper and easy to find like you said, but most importantly, they can replace them on a whim with another one who will do the same work, with “super” engineers, it isn’t the case, the amount of knowledge and depth one of them has, you will need a whole team to understand what’s going on first and another to carry on the job, and C-levels being egoistic, they don’t like anyone to have any leverage by any means.
> 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.
And turnover you will have! =)
Note that you just ballooned the cost probably 3-4x compared to keeping the team small and strong. And that is how we got to this zombiecorn land we see today.
Also consider this - hiring a large team of bozos is a one-way street. You will likely never be able to hire and retain strong talent ever again. While you can always turn to hiring "mid-tier coders" when the product matures.
And turnover you will have! =)
Note that you just ballooned the cost probably 3-4x compared to keeping the team small and strong. And that is how we got to this zombiecorn land we see today.
Also consider this - hiring a large team of bozos is a one-way street. You will likely never be able to hire and retain strong talent ever again. While you can always turn to hiring "mid-tier coders" when the product matures.
All you said is true. But the number of talented programmers is very limited and concentrated. And they are quite expensive. Most companies and teams have to go the structured approach with whatever local mediocrity they can hire.
I disagree I guess and they are not as expensive as 4-5x more mids.
> Most companies and teams have to go the structured approach with whatever local mediocrity they can hire.
Yes most companies fail
> Most companies and teams have to go the structured approach with whatever local mediocrity they can hire.
Yes most companies fail
Most people work in most companies that mostly fail over time. Making a living is the goal with work, building enduring value is something that few achieve.
One thing to remember is that every superstar used to be a mid-tier coder. This is not an YA novel where talent is decided at an arbitrary time and that's the lane you'll hold until you retire. =)
When you hire people straight off school or "mid tier" people, you can help them grow to be better and reap the benefits.
If everyone will just hire the "top tier talent", their prices will inflate and the pool of top tier people will never grow.
When you hire people straight off school or "mid tier" people, you can help them grow to be better and reap the benefits.
If everyone will just hire the "top tier talent", their prices will inflate and the pool of top tier people will never grow.
There’s a pretty big difference between carefully seeding up and coming talent and deliberately hiring 40 mids like some folks are suggesting here to build their scrum teams or whatever. There aint going to be no growth here.
If you can determine an "up and coming talent" from a "mid" during a 1 hour job interview, you really should start up a HR consulting company. =)
The only way to figure it out is to hire the ones that seem good and see who blossoms.
The only way to figure it out is to hire the ones that seem good and see who blossoms.
Yes which is why your strategy doesn't work unless you're also really good at firing people (which brings its own set of challenges).
Over here we have a 6 month probation, during which you can fire people American-style by just saying "GTFO" with no reason required. (You can give one, but it's an art to tell the correct one, the wrong reasons will get you in trouble)
Yes, there are some people who shape up for 6 months and then start slacking, but they're definitely not the norm. You should be able to evaluate a person in that time and see if their personality fits the team and whether they are a net positive for the productivity.
Yes, there are some people who shape up for 6 months and then start slacking, but they're definitely not the norm. You should be able to evaluate a person in that time and see if their personality fits the team and whether they are a net positive for the productivity.
"don't hire a 10x team, learn to build a 10x team"
or something like that.
or something like that.
This, and more. Like it or not,the incredible success of software made it an industrial affair, the way clothing industry went 200 years ago - from highly skilled artisans creating unique beautiful designs tailor specifically to their customer to cheap patterns industrially printed. Its just that the printers are still human.
So sweatshops basically?
Not sure it's a great analogy though since software is still basically the design part - the duplication part is trivial.
Not sure it's a great analogy though since software is still basically the design part - the duplication part is trivial.
Yeah, very comfortable sweat shops for highly paid manual laborers. Why do you think open seating plan exists?!? Open plan is the default layout of a standard sweatshop.
The key observation is that they successfully made the "design" of software they "mass duplication" part. The cost of designing and creating crappy custom software has never been so low and it continues to fall.
The key observation is that they successfully made the "design" of software they "mass duplication" part. The cost of designing and creating crappy custom software has never been so low and it continues to fall.
You do know that there are steps between bespoke tailor and exploitative sweat shop, right?
Multiple steps actually.
(And in some cases the alternative to the "sweat shop" is the same amount of hours outside in the fields with fluctuating income based on what happens with the crop that year)
Multiple steps actually.
(And in some cases the alternative to the "sweat shop" is the same amount of hours outside in the fields with fluctuating income based on what happens with the crop that year)
I love 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
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
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.
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.
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
1. https://igormroz.com/documents/netflix_culture.pdf
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
Most companies want to minimize salary while managers and directors are highly incentivized to maximize headcount. It’s very perverse.
>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.
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.
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.
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.
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.
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.
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.
> 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.
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.
I really appreciate this take and the sibling comment. Exactly. See what good is there, move on about the rest.
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.'
> 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.
Leave.
That sounds like it's someone's problem, but it doesn't need to be yours.
[deleted]
From Peopleware: “In the 1985 Jeffery-Lawrence study [from the University of New South Wales]…they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others…Projects on which the boss applied no schedule pressure whatsoever (‘Just wake me up when you’re done.’) had the highest productivity of all.”
I read 20+ books on management and leadership[1], and none of them mentioned anything like Scrum. I agree it's BS.
[1] https://tuckerconnelly.com/management-leadership
I read 20+ books on management and leadership[1], and none of them mentioned anything like Scrum. I agree it's BS.
[1] https://tuckerconnelly.com/management-leadership
While I too despise Scrum, the causation could be runming the other way: the Bosses that have a better team could be more likely to let them run without major pressure.
No love for Scrum but this is the more likely explanation.
A good team that runs itself? Ofc it doesn't need Ten Scrum Masters to deliver value.
Now, the real question is why leadership tries to salvage failing teams with Scrum? Save the wasted money, use it to hire top talent instead... easy.
A good team that runs itself? Ofc it doesn't need Ten Scrum Masters to deliver value.
Now, the real question is why leadership tries to salvage failing teams with Scrum? Save the wasted money, use it to hire top talent instead... easy.
Top programming talent may still need to be managed (and in fact may need to be managed more than lower quality talent). The sweet spot is to hire top programming talent who is also good at intra-team communication and can organize themselves with little direction from management except to be informed about outside factors like client priorities.
Even better is top talent who can also interface directly with the client when necessary (not necessarily all the time) and doesn't need everything first filtered through a manager.
I've worked with teams like this in the past and it was always a pleasure. Most of them were fairly experienced devs and knew the value of email, phone calls, and water cooler talk (serendipitous discussions which led to valuable information being exchanged). Despite the lack of "modern" productivity tools like text messages, chat apps, and Slack, we were able to get stuff done efficiently.
We had weekly meetings which were productive and useful, and actually helped identify if anything was falling through the cracks. Nobody got bored because the meetings were actually helpful.
Even better is top talent who can also interface directly with the client when necessary (not necessarily all the time) and doesn't need everything first filtered through a manager.
I've worked with teams like this in the past and it was always a pleasure. Most of them were fairly experienced devs and knew the value of email, phone calls, and water cooler talk (serendipitous discussions which led to valuable information being exchanged). Despite the lack of "modern" productivity tools like text messages, chat apps, and Slack, we were able to get stuff done efficiently.
We had weekly meetings which were productive and useful, and actually helped identify if anything was falling through the cracks. Nobody got bored because the meetings were actually helpful.
If CEO can hire a 100$ scrum master to save a 1000$ failing team, it's much cheaper than hiring 2000$ successful team. That's probably what they're thinking
Sadly the $1000 team doesn't get saved by the $100 scrum master though.
You are 100% right that legacy management falls for the SCRUM sales pitch.
At one company I worked at the scrum salesman basically bullied the executive team by saying "You don't want to be the last company to adopt scrum do you?!!??!"
You are 100% right that legacy management falls for the SCRUM sales pitch.
At one company I worked at the scrum salesman basically bullied the executive team by saying "You don't want to be the last company to adopt scrum do you?!!??!"
I don't think that's true at all. If there's time-to-market pressure (for example), then you really want that $2000 team to deliver on time. "Saving" the $1000 failing team with a $100 scrum master may not be good enough.
Also, please at least acknowledge that your numbers are completely made up and may have no basis in reality. It might be a $1000 team only if they deliver on time, but the overages might push that to $5000. Or whatever. See, I can completely make up numbers to support my point too.
Also, please at least acknowledge that your numbers are completely made up and may have no basis in reality. It might be a $1000 team only if they deliver on time, but the overages might push that to $5000. Or whatever. See, I can completely make up numbers to support my point too.
Saying that doesn't mean I agree with what I say, you know.
Also, this is needed now and needs to be repeatable.
> […] hire top talent […] easy
Have you _tried_ hiring good people?
Have you _tried_ hiring good people?
Top talent does not exist.
This problem exists at big tech and startup, in companies that spend fractional multipliers of the average salary on engineers as well as those who pay poorly.
In this environment, if your solution is "hire better people', you can't- there isn't any
This problem exists at big tech and startup, in companies that spend fractional multipliers of the average salary on engineers as well as those who pay poorly.
In this environment, if your solution is "hire better people', you can't- there isn't any
> This problem exists at big tech and startup,
Big tech or startup status are not correlated with top talent. I've seen the whole spectrum of low to high talent from both places.
> in companies that spend fractional multipliers of the average salary on engineers as well as those who pay poorly
Pay and top skill are only slightly correlated, unfortunately.
> Top talent does not exist.
It does exist. I've seen it, but most managers don't know how to find it, identify it, and retain it.
Big tech or startup status are not correlated with top talent. I've seen the whole spectrum of low to high talent from both places.
> in companies that spend fractional multipliers of the average salary on engineers as well as those who pay poorly
Pay and top skill are only slightly correlated, unfortunately.
> Top talent does not exist.
It does exist. I've seen it, but most managers don't know how to find it, identify it, and retain it.
The people who implement Scrum are insecure managers. They don't understand the development process, don't trust their staff to just get on with it, and need constant reassurance that their project/product is making progress.
So it would have to be both: the devs are good and don't need hand-holding, and the manager is able to deal with the lack of transparency that "it'll be done when it's done" comes with.
So it would have to be both: the devs are good and don't need hand-holding, and the manager is able to deal with the lack of transparency that "it'll be done when it's done" comes with.
44 yo dev here. What I've seen from managers is that "letting go" is more of a personal trait than an external force.
Some people just have a very hard time letting go and trusting a team. Who they are managing just needs to follow.
Some people just have a very hard time letting go and trusting a team. Who they are managing just needs to follow.
Our team is the only one not doing “scrum” or estimates or shit. Our team is the only one far ahead because we don’t waste our lead engineers’ time and allow them to move at their own pace (that means very fast). I just have 15 minute dailies with the other senior and the manager to stay in sync.
During a certain phase of my career, I was part of a company that extensively used the Scrum framework.
My takeaway then was that Scrum fosters a modular team management style, which diminishes the dependence on highly skilled individuals.
This approach seemed to offer management a sense of oversight in the software development process, but I didn't stay long enough to determine whether this was actual control and predictability or merely an illusion of it.
My takeaway then was that Scrum fosters a modular team management style, which diminishes the dependence on highly skilled individuals.
This approach seemed to offer management a sense of oversight in the software development process, but I didn't stay long enough to determine whether this was actual control and predictability or merely an illusion of it.
I re-read Peopleware this last weekend. It's one of my favourite books on the topic of software management. There are chapters that are not very useful for the $current_year (eg. regarding telephones or office furniture) but overall it's a fantastic piece on human interactions in the industry.
What if the boss gets a wake up call from bank, saying they are out of funds to pay team salaries, first?
Interesting phenomenon happens at my place which is scrum + Safe. Our team gets publicly dinged if we "carry over" tickets between sprints, so if we finish our work with 2 days left the manager asks not to start anything new.
The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira's toxic charts).
You might think this is nice to have free time to sit around, but frankly it also drains a lot of the joy out of my work, takes away my sense of autonomy and pride in my work and leads to some resentment.
The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira's toxic charts).
You might think this is nice to have free time to sit around, but frankly it also drains a lot of the joy out of my work, takes away my sense of autonomy and pride in my work and leads to some resentment.
This. I moved from being the Main Tech Guy at a startup to being a backend engineer at a mature company running Scrum. I was amazed by how little work anyone did at the mature company. People obviously doing f-all during the day. If we finished our sprint 3 days early then we just pretended to be working (what is the point in having a standup every day when there are no tickets to work on?).
It was painful. I constantly felt that I should be working, because I was being paid decent money. But there was nothing to do, and no-one wanted me to do anything. I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything.
We adopted Mob Programming. Five senior engineers on one call writing one piece of code. Or rather, one of us teaching the manager some Golang while he spent 4 hours doing a ticket that should have taken 1 hour. No stakeholders present because none of them wanted to waste a day watching us work.
Such a waste of time and talent.
It was painful. I constantly felt that I should be working, because I was being paid decent money. But there was nothing to do, and no-one wanted me to do anything. I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything.
We adopted Mob Programming. Five senior engineers on one call writing one piece of code. Or rather, one of us teaching the manager some Golang while he spent 4 hours doing a ticket that should have taken 1 hour. No stakeholders present because none of them wanted to waste a day watching us work.
Such a waste of time and talent.
> I couldn't focus on a side project because I felt so guilty about taking their money and not doing anything.
That’s what I hate about these wasted “pockets” of time.. you don’t have work to do, and you can’t focus on doing your side projects either, just a waste.
That’s what I hate about these wasted “pockets” of time.. you don’t have work to do, and you can’t focus on doing your side projects either, just a waste.
As a consultant with 25 years of experience in enterprise software for sizable corporations and universities, I have observed numerous development shops. The number of individuals in corporate America who accomplish little throughout the day is astonishing. This phenomenon aligns with the Pareto principle, wherein 20% of the workforce completes approximately 99% of the tasks and the rest are dead weight.
Our solution for this is to have nebulous time sucks that need to be done, but don't have a ticket with an estimate. Like "increase test coverage" or "experiment with new things for a git hook to do" or "eliminate warnings". There's no deadline, and everything else is higher priority- but when you finish your sprint early, now you know what you can work on. And it's useful, not just scutwork.
> Our team gets publicly dinged if we "carry over" tickets between sprints
This is not part of scrum
This is not part of scrum
You'd be surprised at how many places this is.
At a place I worked the management decided that a "story" should always be completed within a sprint. So what did we do? We started using stories instead of tasks and epics instead of stories[0]. And voila, now magically stories complete within a sprint!
[0] Just writing that sentence makes my eye twitch
At a place I worked the management decided that a "story" should always be completed within a sprint. So what did we do? We started using stories instead of tasks and epics instead of stories[0]. And voila, now magically stories complete within a sprint!
[0] Just writing that sentence makes my eye twitch
Similarly, in order to fit stories into a sprint and not spillover, there is the constant fixation on making stories "as small as possible". So now people make a story for adding a button, then another story for the click handler of the button, then another story for saving data into DB when button is clicked, then another story for adding the tests, and so on. Then the sheer amount of time talking about how to split that up and adding all those into JIRA...
It kind of is. Well, the public dinging probably isn't. But at a few companies I've seen, teams are tracked on how many tickets span multiple sprints. If it exceeds some threshold, then theoretically it means that either:
1. The team is not breaking down tasks granularly enough, or
2. They're not estimating tasks correctly
Practically, it means nothing of course.
Practically, it means nothing of course.
In Scrum:
- the product owner sets the backlog priority
- team estimates
- team commits to what it can deliver from the backlog
- any misses are analyzed for scope mistakes
Rinse/repeat
There’s no shaming part
Edit: format
- the product owner sets the backlog priority
- team estimates
- team commits to what it can deliver from the backlog
- any misses are analyzed for scope mistakes
Rinse/repeat
There’s no shaming part
Edit: format
The scrum guide [1] says team gives a forecast and not a commitment. I have yet to know any other scrum practitioners aware of that update.
Unless a person has no shame, failing a commitment I certainly believe is intrinsically shameful. Some cultures would commit seppuku if you don't deliver on a commitment.
The words, "you failed on your commitments" seems very much like shaming. Thus the move to "forecast" over "commitment"
[1] https://www.scrum.org/resources/commitment-vs-forecast
*edit (addendum): Invoking 'seppuku' might be a bit sensationalist, my apologies. The southerner in me is coming out - saying someone does not live up to their word is a very big deal.
Unless a person has no shame, failing a commitment I certainly believe is intrinsically shameful. Some cultures would commit seppuku if you don't deliver on a commitment.
The words, "you failed on your commitments" seems very much like shaming. Thus the move to "forecast" over "commitment"
[1] https://www.scrum.org/resources/commitment-vs-forecast
*edit (addendum): Invoking 'seppuku' might be a bit sensationalist, my apologies. The southerner in me is coming out - saying someone does not live up to their word is a very big deal.
I can totally relate. We are not told not to do more work but at sprint planning if someone thinks a ticket would spill over then they should add it only to next sprint. So we do less work just to not spill over.
I had a team with a shadow backlog. Fun times
I work on a very small scale nowadays, but what I have found to be helpful is "weekend fun" tickets. Nice to have things that I wouldn't do otherwise but are fun when I don't have the energy for other stuff / when I consciously try to reward myself.
Great time to tackle some tech debt
Not if you can't work on anything without a ticket, and you can't add a ticket to the current sprint.
Do it anyway, file the ticket and pull it into the next sprint.
So stop following Scrum? Completely agree
Ah yeah I had a boss that wanted me to open tickets, estimate them, plan them, do them, to fix 1 line issues that I would randomly find working on other tasks.
Normally I just fix them within a separate commit.
Normally I just fix them within a separate commit.
I have a lot of issues with scrum and I think twitter post and the comments here touch on a lot of them, but one of my biggest annoyances with the whole thing that I hardly ever hear anyone mention is the term "sprints".
If you asked a marathon runner how to run a marathon, they're going to tell you things like run slower, make sure you conserve energy, and control your pace. They're not going to tell you to mentally break the marathon into small sections and sprint them all.
I know it seems minor (and it probably is), but it's always felt a bit telling that the recurring segment for work in scrum is named after something you cannot do repeatedly without completely burning yourself out.
If you asked a marathon runner how to run a marathon, they're going to tell you things like run slower, make sure you conserve energy, and control your pace. They're not going to tell you to mentally break the marathon into small sections and sprint them all.
I know it seems minor (and it probably is), but it's always felt a bit telling that the recurring segment for work in scrum is named after something you cannot do repeatedly without completely burning yourself out.
From “Agile In Their Own Words”, https://github.com/rayfrankenstein/AITOW/blob/master/README....
“One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behalf of the team for assessing risks/opportunities, as with a regular fixed price contract. As a freelancer, you can't let this happen, so it leads to unpleasant discussions.
I also take issue with the term 'sprint'. By definition, a sprint is a short-term sports activity to reach a goal in the shortest amount of time possible. But just as in sports, you can't expect to do one sprint after another without quickly burning out, and that's exactly what I've been seeing in agile projects. An engineering-heavy software project shouldn't be seen as a series of sprints at all, but more as an endurance run if anything.
I also hate the term 'agile' itself, which seems to be chosen to appease to a manager's idea of interchangeable, faceless staffing. Actually, "agile" makes me think of spermatozoa striving to fertilize ova.
I also despise the motivation propaganda that usually goes with agile, and the "scrum masters" non-coders interrupting any meaningful technical discussion they don't understand and suggest to take the discussion 'offline' or 'time-boxed'."--imhotap, https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nu...
“One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behalf of the team for assessing risks/opportunities, as with a regular fixed price contract. As a freelancer, you can't let this happen, so it leads to unpleasant discussions.
I also take issue with the term 'sprint'. By definition, a sprint is a short-term sports activity to reach a goal in the shortest amount of time possible. But just as in sports, you can't expect to do one sprint after another without quickly burning out, and that's exactly what I've been seeing in agile projects. An engineering-heavy software project shouldn't be seen as a series of sprints at all, but more as an endurance run if anything.
I also hate the term 'agile' itself, which seems to be chosen to appease to a manager's idea of interchangeable, faceless staffing. Actually, "agile" makes me think of spermatozoa striving to fertilize ova.
I also despise the motivation propaganda that usually goes with agile, and the "scrum masters" non-coders interrupting any meaningful technical discussion they don't understand and suggest to take the discussion 'offline' or 'time-boxed'."--imhotap, https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nu...
Another from “Agile In Their Own Words”
“My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.”—klyrs, https://news.ycombinator.com/item?id=20017854#20021832
“My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.”—klyrs, https://news.ycombinator.com/item?id=20017854#20021832
Another from AITOW
“I regularly ask ‘Why are we running a marathon in a thousand sprints?’.
Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for ‘high velocity’. There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.”—epage, https://news.ycombinator.com/item?id=20017854#20021832
“I regularly ask ‘Why are we running a marathon in a thousand sprints?’.
Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for ‘high velocity’. There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.”—epage, https://news.ycombinator.com/item?id=20017854#20021832
Thanks for pointing this and I don't believe this is a minor point. I'm managing multiple teams - I was a developer - and I consider the "long" time perspective as a product quality technically speaking and also the team health. And a sprint is not compatible with those two last points where at the end of a sprint everybody in the team rush to deliver the user story and everybody is exhausted or tired...
Completely agree, it has always bothered me as well. To me it (strongly) implies rushing, and I don't believe that constantly keeping your team in a stressful state where you are always rushing or 'sprinting' towards the next goal is a good sustainable long-term strategy.
If the word (sprint) is a problem, then change it. Call it "iteration", "segment", whatever.
Taking a 500km bicycle ride from one place to another, you surely will plan the thing as segments. I would plan days and see where I can reach milestones: a city, a place to stay, a sight-seeing place, a mountain top, a ferry, a destination...
A software development project of several months is not a Marathon.
I've run a Marathon in a few hours. But even in a Marathon I look at my starting preparations of the day, my 5km times, reach the half marathon, plan for the drinking stops, plan when my primary energy source is depleted, how to get over it, ... Few people run a Marathon from front to end with the same speed&energy, without a plan how to mentally split up the race.
Taking a 500km bicycle ride from one place to another, you surely will plan the thing as segments. I would plan days and see where I can reach milestones: a city, a place to stay, a sight-seeing place, a mountain top, a ferry, a destination...
A software development project of several months is not a Marathon.
I've run a Marathon in a few hours. But even in a Marathon I look at my starting preparations of the day, my 5km times, reach the half marathon, plan for the drinking stops, plan when my primary energy source is depleted, how to get over it, ... Few people run a Marathon from front to end with the same speed&energy, without a plan how to mentally split up the race.
I agree that a word is just a word and it can easily be changed. That's why I called it a minor issue. I think my issue is more that if we have a framework where part of the framework is named after something that is not unsustainable long term, it makes me question the goals and intent of the people who created it. I have to ask myself, "are we using this in an unintended way".
It's like if you came to my house and asked for a towel and I went, "oh yeah, use my butt towel". Just because it's called a butt towel doesn't mean it's actually got anything to do with a butt, but you're probably going to be a bit uncomfortable until you understand why I'm calling it that.
It's like if you came to my house and asked for a towel and I went, "oh yeah, use my butt towel". Just because it's called a butt towel doesn't mean it's actually got anything to do with a butt, but you're probably going to be a bit uncomfortable until you understand why I'm calling it that.
Bonus points for starting and ending sprints with meetings instead of work :)
I think there's a bit of selection bias here in that only people who are either very enamored or very unhappy with scrum are going to respond to a hot take on twitter.
But, that's besides the point. Scrum doesn't exist to make developer's lives easier. In my experience as a SWE in a scrum team, devs have basically always felt like our time is being wasted in meetings.
Scrum, imo, exists so that management and business stakeholders can have an understanding of how efforts are being allocated and give feedback on it. There's still plenty of ways this can go wrong, and I agree with others that the short sprint cycles of 1-2 weeks lead to the extra overhead of too many ceremonies, but I think for the average business stakeholder it probably gives a better result than waterfall.
But, that's besides the point. Scrum doesn't exist to make developer's lives easier. In my experience as a SWE in a scrum team, devs have basically always felt like our time is being wasted in meetings.
Scrum, imo, exists so that management and business stakeholders can have an understanding of how efforts are being allocated and give feedback on it. There's still plenty of ways this can go wrong, and I agree with others that the short sprint cycles of 1-2 weeks lead to the extra overhead of too many ceremonies, but I think for the average business stakeholder it probably gives a better result than waterfall.
> devs have basically always felt like our time is being wasted in meetings.
I think that's key. My experience is that I have often told my managers that "I don't need this meeting personally, so unless somebody else needs me in this meeting, I am losing my time".
Do you know what the managers usually answered? "I disagree, I think this meeting is useful for you. We are having this meeting to help you developers".
No wonder I don't respect my managers then, and now I happily waste my time in their meetings.
I think that's key. My experience is that I have often told my managers that "I don't need this meeting personally, so unless somebody else needs me in this meeting, I am losing my time".
Do you know what the managers usually answered? "I disagree, I think this meeting is useful for you. We are having this meeting to help you developers".
No wonder I don't respect my managers then, and now I happily waste my time in their meetings.
Scrum practitioners often spout weird propaganda. I once remarked that a programming task might be time-intensive, and difficult to accomplish quickly in a process as meeting-heavy as Scrum. The Scrum Master then linked me to a FAQ item on some pro-Scrum web site which purported to assure us that Scrum teams spend far fewer hours per week in meetings compared to other teams. She might've had a point, albeit a small one, if:
* standups were limited to 15 min/day (all Scrum teams I'd been on took 30 min, minimum, to do standup)
* we actually had 1 hour retro, planning and refinement meetings (retro, the most useful meeting, was actually 1.5h, planning and refinement could take 2h)
* POs did not feel free to schedule arbitrary additional meetings to keep up with the increasing backlog. SAFe specifies a quarterly, multi-day, division-wide planning meeting to align disparate teams during which all the work you intended to do for the next six sprints was scheduled on a big board. Of course there was never enough time to point and schedule six sprints' worth of work, necessitating a pre-planning meeting, and sometimes a pre-pre-planning meeting. Hours each.
* standups were limited to 15 min/day (all Scrum teams I'd been on took 30 min, minimum, to do standup)
* we actually had 1 hour retro, planning and refinement meetings (retro, the most useful meeting, was actually 1.5h, planning and refinement could take 2h)
* POs did not feel free to schedule arbitrary additional meetings to keep up with the increasing backlog. SAFe specifies a quarterly, multi-day, division-wide planning meeting to align disparate teams during which all the work you intended to do for the next six sprints was scheduled on a big board. Of course there was never enough time to point and schedule six sprints' worth of work, necessitating a pre-planning meeting, and sometimes a pre-pre-planning meeting. Hours each.
The meetings are good. You're getting paid during them. I managed to customise my bike, plan two international adventures, run a side business and do a year of a degree in pointless meetings in the last 5 years!
Yep. I have come to love Scrum for the dysfunction it provides as a remote employee. I can sit in the background and do other things while not being expected to achieve anything.
Eyes are watching. Your manager is likely to bring up that you're not an active enough participant in meetings; and yes, it will count against you in your performance reviews.
Manager isn't in the Scrum meetings most of the time. Self managing team and all...
Ding! Ding! Ding! We have a winner. Tell him what he's won, Johnny!
Enlightenment came to me when I realized that companies only adopt Agile for reasons that benefit executives and management, not developers, to wit: fine-grained observability and direct control over the SDLC itself. It's really a game of Mornington Crescent: the team pretends to be playing one game when they're actually playing a different sort of game.
Enlightenment came to me when I realized that companies only adopt Agile for reasons that benefit executives and management, not developers, to wit: fine-grained observability and direct control over the SDLC itself. It's really a game of Mornington Crescent: the team pretends to be playing one game when they're actually playing a different sort of game.
> management and business stakeholders can have an understanding of how efforts are being allocated and give feedback on it
I agree that devs can often mistake this need for wasted time. That does _not_ mean that Scrum is the best way to not waste time. A good project manager can get that info without so many full team meetings.
I guess one way to put it is that scrum is a clear way to lead a project (which is what entices people) but its not a great way.
I agree that devs can often mistake this need for wasted time. That does _not_ mean that Scrum is the best way to not waste time. A good project manager can get that info without so many full team meetings.
I guess one way to put it is that scrum is a clear way to lead a project (which is what entices people) but its not a great way.
>I think there's a bit of selection bias here in that only people who are either very enamored or very unhappy with scrum are going to respond to a hot take on twitter.
All 10 of the former?
All 10 of the former?
Well - since he did say they were mostly people with the title 'scrum master' or 'agile coach' defending it, perhaps a better phrasing is "people whose livelihoods depend on it" :)
I'm going to get blasted for this, but you *are* doing scrum wrong.
Scrum was invented by engineers to defend themselves against incompetent middle managers. The moment you let management take the process over and warp it you are already doing it wrong.
Story points and sprints are a *self-calibrating* tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have given a middle manager will be missed.
You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and *measure* how many points fit in a sprint.
Nearly every single point in that tweet just screams bad management and bad engineers without any agency.
Story points and sprints are a *self-calibrating* tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have given a middle manager will be missed.
You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and *measure* how many points fit in a sprint.
Nearly every single point in that tweet just screams bad management and bad engineers without any agency.
> Story points and sprints are a self-calibrating tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have given a middle manager will be missed.
> You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and measure how many points fit in a sprint.
I don't know how you can use both "sprint"[1] and "sustainable" in the same post with a straight face.
[1] A sprint, by definition, is an unsustainable burst of speed. The word "unsustainable" is literally in the definition.
> You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and measure how many points fit in a sprint.
I don't know how you can use both "sprint"[1] and "sustainable" in the same post with a straight face.
[1] A sprint, by definition, is an unsustainable burst of speed. The word "unsustainable" is literally in the definition.
You're arguing that the entire system is invalid because one of the concepts is poorly named?
This is turning into a discussion about naming, which is important. I think the sprints are maybe wrongly worded, but I struggle to find a better term.
User stories are not actual stories with a plots as well, but the idea makes sense
User stories are not actual stories with a plots as well, but the idea makes sense
Maybe, but the people you are telling the word "sprint" to do not interpret it as "iteration" or "phase", they are interpreting it as "unsustainable burst of speed".
When you tell people the word "story", they know exactly what you mean, because the word story is used all the time for things without plots ("So, what's your story?" comes to mind).
We frequently use the word story to mean "your side of things"; in civil litigation for example.
When you tell people the word "story", they know exactly what you mean, because the word story is used all the time for things without plots ("So, what's your story?" comes to mind).
We frequently use the word story to mean "your side of things"; in civil litigation for example.
we call them cycles (weekly cycles, or bi-weekly cycles, mostly they are product planning cycles, and also usually the basic time interval after the previous planing assumptions should be checked/revised, etc.)
// linear also calls them cycles, https://linear.app/features/plan#cycles , but linear is a bit meh
// linear also calls them cycles, https://linear.app/features/plan#cycles , but linear is a bit meh
Not only I'm not blasting you but also I'm right there with you.
I've always said that Scrum doesn't fix problems, but it makes them more evident so you can fix them.
Teams that don't realize this are going to be unhappy about Scrum, but in my opinion they wouldn't be happy without.
Often the problems are one of these:
- Focusing on estimates. In scrum, a team doesn't really need any estimates beyond planning what they will do in the next two weeks. Planning poker, story points, estimations are just a means to that end. If you don't like them, don't use them.
- Focusing on ceremonies without understanding how to use them (or when to drop them!). I haven't done stand ups in years. I use online tools like geek bot. Retrospectives are just as useful as the number of problems you actually solve after they are pointed out. Planning is only useful if it produces teamwork, if the engineers all work in 1-person silos, it becomes a joke.
- Not understanding that Agile > Scrum. If you think you can be more agile without some parts of scrum, drop the parts you don't need. Being able to change the rules of the game in-flight is part of agile (and of scrum).
I've always said that Scrum doesn't fix problems, but it makes them more evident so you can fix them.
Teams that don't realize this are going to be unhappy about Scrum, but in my opinion they wouldn't be happy without.
Often the problems are one of these:
- Focusing on estimates. In scrum, a team doesn't really need any estimates beyond planning what they will do in the next two weeks. Planning poker, story points, estimations are just a means to that end. If you don't like them, don't use them.
- Focusing on ceremonies without understanding how to use them (or when to drop them!). I haven't done stand ups in years. I use online tools like geek bot. Retrospectives are just as useful as the number of problems you actually solve after they are pointed out. Planning is only useful if it produces teamwork, if the engineers all work in 1-person silos, it becomes a joke.
- Not understanding that Agile > Scrum. If you think you can be more agile without some parts of scrum, drop the parts you don't need. Being able to change the rules of the game in-flight is part of agile (and of scrum).
Sorry, but that's a catch-all defense. You're either doing too much Scrum, or not enough, and if it's not working you're doing it wrong. But the Party is always right, no matter what! Read our manifesto and attend some certificated training.
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.
> 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.
Agree, but the warnings are for management, not for you. What do you care whether something's finished? Shoulda hired more interchangeable devs or lowered the expectations.
> bad management and bad engineers without any agency.
bad management destroys agency
bad management destroys agency
Yep, Scrum can't fix bad management!
I still chuckle a bit when people get anti-scrum, because I've been around long enough when agile/scrum was the disruptive thing.
Of course in practice agile/scrum/whatever has turned into the same cargo-cult nonsense that the original promoters of the ideals were fighting against.
One thing I thought was interesting was:
> First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "Scrum Master." They feel very strongly in favor of Scrum, but I'm not sure why.
It seems funny to critique people's job titles when the poster's Twitter profile reads:
> I teach Machine Learning and run http://ml.school
I mean loudly critiquing a mainstream practice in a flippant way is pretty much the textbook approach to bring attention to yourself and establish as an expert in... teaching people about these topics. It's content marketing 101.
Of course in practice agile/scrum/whatever has turned into the same cargo-cult nonsense that the original promoters of the ideals were fighting against.
One thing I thought was interesting was:
> First, the most common jobs among the people who told me I was wrong were "Agile Coach" and "Scrum Master." They feel very strongly in favor of Scrum, but I'm not sure why.
It seems funny to critique people's job titles when the poster's Twitter profile reads:
> I teach Machine Learning and run http://ml.school
I mean loudly critiquing a mainstream practice in a flippant way is pretty much the textbook approach to bring attention to yourself and establish as an expert in... teaching people about these topics. It's content marketing 101.
Thank you! Personally I started to ignore any post from twitter on HN, which otherwise has fantastic quality on its content, since you just know that the content will shallow and "clickbaity".
My wish is for HN to ban all links from there. It would be better to HN anyways if the discussions got contained within the forum instead.
It would be nice if it became normal for HN users to flag and or at least refrain from upvoting twitter links, since my belief is that they are bound to influence HN negatively.
Failing that I suppose I'll have to mess around with an extension so that my browser removes them automatically instead.
My wish is for HN to ban all links from there. It would be better to HN anyways if the discussions got contained within the forum instead.
It would be nice if it became normal for HN users to flag and or at least refrain from upvoting twitter links, since my belief is that they are bound to influence HN negatively.
Failing that I suppose I'll have to mess around with an extension so that my browser removes them automatically instead.
Scrum was never the disruption. Agile was. But really, it started with eXtreme Programming, from which "agile" was the more generalize distillation.
I'll say this: I worked in XP (and then "agile") teams ~20 years ago a couple times with varying success, but the one good thing was it got people thinking and agitating against the delusions that went along with waterfall.
Then I got stuck at Google for 10 years, where "agile" isn't really a thing. (There are teams that are sorta doing scrum... ish stuff. And there's a wide diversity of how things are done there. But on the whole Google has effectively unlimited budgets and headcount so things sorta just ... broken down waterfall ... until they're "done" whenever). When I got out... Scrum or some variant had taken over.
And I don't recognize this as the "agile" I worked with before. It's just a mess of pointless routines and shiboleths without the meat of what made things "agile".
Agile was: developers do their own estimates. Short iterations. "Stories" are 2-3 days and tied directly to a customer's business request. Intense involvement with the "customer" letting them know the trade-offs for every decision. Ship the prototype. "You ain't gonna need it." Informal daily standup just for the purpose of making sure everyone is on the same page. At the end of the iteration, go over the "cards" and triage and discuss why some estimates were off.
What I see now is just going through the motions of some of these, but in the end it's either chaos, or waterfall in disguise and some PM with a hard-on for configuring JIRA in some convoluted fashion so they can pass on reports to their superiors and make people jump through hoops so it looks like progress.
I just wanna code, get things done, fix things and ship things. Agile was the recognition that (good) engineers want to get work done and the upfront design process was often just getting in the way of problem solving and the creative process. The ones who don't? Get them off your team.
Somewhere along the line that message was lost.
I'll say this: I worked in XP (and then "agile") teams ~20 years ago a couple times with varying success, but the one good thing was it got people thinking and agitating against the delusions that went along with waterfall.
Then I got stuck at Google for 10 years, where "agile" isn't really a thing. (There are teams that are sorta doing scrum... ish stuff. And there's a wide diversity of how things are done there. But on the whole Google has effectively unlimited budgets and headcount so things sorta just ... broken down waterfall ... until they're "done" whenever). When I got out... Scrum or some variant had taken over.
And I don't recognize this as the "agile" I worked with before. It's just a mess of pointless routines and shiboleths without the meat of what made things "agile".
Agile was: developers do their own estimates. Short iterations. "Stories" are 2-3 days and tied directly to a customer's business request. Intense involvement with the "customer" letting them know the trade-offs for every decision. Ship the prototype. "You ain't gonna need it." Informal daily standup just for the purpose of making sure everyone is on the same page. At the end of the iteration, go over the "cards" and triage and discuss why some estimates were off.
What I see now is just going through the motions of some of these, but in the end it's either chaos, or waterfall in disguise and some PM with a hard-on for configuring JIRA in some convoluted fashion so they can pass on reports to their superiors and make people jump through hoops so it looks like progress.
I just wanna code, get things done, fix things and ship things. Agile was the recognition that (good) engineers want to get work done and the upfront design process was often just getting in the way of problem solving and the creative process. The ones who don't? Get them off your team.
Somewhere along the line that message was lost.
I don't think that part is so much about the job titles themselves. It's more about the interests/motivations. As in "I said smoking was bad and a lot of people that worked in selling tobacco told me I was wrong and that smoking was perfectly healthy".
Critiquing Scrum in now way establishes you as an expert in teaching ML
Yes, that seems to be IKantRead's point.
The OP barely has any experience in the field so... One bad gig is maybe 50% of his work experience.
I got rejected from a job recently and I strongly suspect it was because I went on a rant about how awful scum was against my better judgement.
Something I've noticed in the last 3-5 years is that it's become more and more common for companies to quiz candidates on their scrum knowledge during interviews. They don't care what you think of scrum (though they may phase their questions like this) they simply want to know you know how to scrum because they scrum. And like in most places you can assume that although "scrum is flexible" it's also religiously followed in practise.
Anyway, this company wanted to know what I liked and disliked about scrum and my initial answer was kinda similar to this post – that I liked the idea of it but have never seen it work well in practise. Obviously this was a bad answer because it meant for the next 10 minutes of the interview they were asking me to expand and were trying to understand if I was a bad culture fit. Which to be fair I probably was.
But the truth is everywhere I've worked spirt ceremonies are universally hated and typically viewed as a waste of time (especially spirt reviews). Planning rarely adds much value and since estimates are often wrong you either need to be overly conservative with your estimation (rendering it useless), or you're forced to cut corners to deliver stuff on time. And even if you do estimation perfectly ACs always change and extra tickets are always brought into the spirt because "it's essential". Standup is never 15 minutes – it's 10 minutes per team member who likes to hear their own voice, and 30 seconds to those who don't and who just want to get on with their work. Don't even get me started on the team building games...
I have seen companies implement it better than others though. The place I work at the moment does it surprisingly well. We do standups which are mostly mandatory, but everything else is optional for the vast majority of the team.
Something I've noticed in the last 3-5 years is that it's become more and more common for companies to quiz candidates on their scrum knowledge during interviews. They don't care what you think of scrum (though they may phase their questions like this) they simply want to know you know how to scrum because they scrum. And like in most places you can assume that although "scrum is flexible" it's also religiously followed in practise.
Anyway, this company wanted to know what I liked and disliked about scrum and my initial answer was kinda similar to this post – that I liked the idea of it but have never seen it work well in practise. Obviously this was a bad answer because it meant for the next 10 minutes of the interview they were asking me to expand and were trying to understand if I was a bad culture fit. Which to be fair I probably was.
But the truth is everywhere I've worked spirt ceremonies are universally hated and typically viewed as a waste of time (especially spirt reviews). Planning rarely adds much value and since estimates are often wrong you either need to be overly conservative with your estimation (rendering it useless), or you're forced to cut corners to deliver stuff on time. And even if you do estimation perfectly ACs always change and extra tickets are always brought into the spirt because "it's essential". Standup is never 15 minutes – it's 10 minutes per team member who likes to hear their own voice, and 30 seconds to those who don't and who just want to get on with their work. Don't even get me started on the team building games...
I have seen companies implement it better than others though. The place I work at the moment does it surprisingly well. We do standups which are mostly mandatory, but everything else is optional for the vast majority of the team.
> I went on a rant
I think that sums up why you got rejected. Over the years I've found anything negative said during an interview process works against you. I really noticed this when I had a job I hated and some of that kept creeping into my interviews with me saying something about it (varied from rant to a few comments) and I was interviewing for a few months... I noticed this and consciously edited it out and had 2 offers in the next couple weeks. I've noticed it more subtly after that and have sense tried to make sure I stay 100% positive in my interviews.
I think that sums up why you got rejected. Over the years I've found anything negative said during an interview process works against you. I really noticed this when I had a job I hated and some of that kept creeping into my interviews with me saying something about it (varied from rant to a few comments) and I was interviewing for a few months... I noticed this and consciously edited it out and had 2 offers in the next couple weeks. I've noticed it more subtly after that and have sense tried to make sure I stay 100% positive in my interviews.
This is an apt observation. Anything negative. Even if true. Even if it doesn't reflect on you. They want someone socially aware enough that they can say negative things without saying anything negative. There's a nuance. "I understand where they're coming from. There's definitely situations where that is preferred", translates to "I disagree totally but it's their prerogative so I'm not going to worry myself too much with that decision."
It shows experience with people and ability to read between the lines.
It shows experience with people and ability to read between the lines.
You're right. I had already got bad vibes from the interview by this point and started acting up a bit.
I was initially really interested in the company and made it clear early on that I really liked what they were doing and how I thought I could add value, but they started shooting me down assuring me the role I was applying for wasn't that interesting and that I'd mostly be a code monkey (obviously not in those exact words).
By the time they started asking about my agile experience and what I thought of scum I figured I didn't have much to lose being honest with them. It would have been in neither of our interest for me to pretend I might have been a good fit.
But yeah, generally I'll try to be mostly positive while finding something minor to be constructively critical about. I think that tends to strike the right balance between showing you can think for yourself without coming across as the type of person who will cause problems. Sounds like you've noticed the same thing.
I was initially really interested in the company and made it clear early on that I really liked what they were doing and how I thought I could add value, but they started shooting me down assuring me the role I was applying for wasn't that interesting and that I'd mostly be a code monkey (obviously not in those exact words).
By the time they started asking about my agile experience and what I thought of scum I figured I didn't have much to lose being honest with them. It would have been in neither of our interest for me to pretend I might have been a good fit.
But yeah, generally I'll try to be mostly positive while finding something minor to be constructively critical about. I think that tends to strike the right balance between showing you can think for yourself without coming across as the type of person who will cause problems. Sounds like you've noticed the same thing.
Most people don’t know some history. During 1990s, a group of people made a fortune out of consulting gigs where they will be called in by their CTO friends in traditional enterprises to save the late and over budget projects. One of these people was Kent Beck. Kent will use his license to kill to turn things around and eventually generalize his rescue formula and sell it to make 100X more. His crowning glory during those days was XP or eXtreme Programming.
Like with all self-help formulas, Kent will label his solution as magic bullet for all software development problems. He will advertise it as secret medicine that cures all ills. He will be at every conference, write articles after articles, publish books.
Also, like all magic self-help formulas, it wouldn’t quite work. So, Kent will invent something new. His next prescription was TDD and when I first saw it, I thought it was a joke. But people around me started drinking cool aid and if you didn’t join them then you weren’t one of them. Again, Kent and friends will go out on massive marketing spree advertising it as secret talisman. Like all overweight desperate people in need to lose weight, people will enthusiastically start new Kent Beck diet, lose few pounds and endorse the formula. But they will soon find that they had simply traded one problem for another more uglier one.
This went on for long time. For more than two decades, these group of people kept inventing these processes, selling it as magic pill and made millions upon millions in consulting gigs, books, training, certifications and so on. They came up with Agile and 17 people in that group created “agile manifesto”. Their most aggressively marketed prescription was scrum. Like their all previous prescription, world is finally coming off of night of drinking cool aid and feeling severe headache.
I think most of these people have now sort of retired after amassing massive fortunes and hopefully we will not see more of these magic processes pushed to dumb CTOs with promises of curing all ills.
The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company. For everything else, it should never have been used. It is especially going to hurt creativity, originality and novelty if you are in business of making a differentiating unique novel product. It also is very very bad choice if you already had tier-1 highly motivated team.
So exercise caution!
Like with all self-help formulas, Kent will label his solution as magic bullet for all software development problems. He will advertise it as secret medicine that cures all ills. He will be at every conference, write articles after articles, publish books.
Also, like all magic self-help formulas, it wouldn’t quite work. So, Kent will invent something new. His next prescription was TDD and when I first saw it, I thought it was a joke. But people around me started drinking cool aid and if you didn’t join them then you weren’t one of them. Again, Kent and friends will go out on massive marketing spree advertising it as secret talisman. Like all overweight desperate people in need to lose weight, people will enthusiastically start new Kent Beck diet, lose few pounds and endorse the formula. But they will soon find that they had simply traded one problem for another more uglier one.
This went on for long time. For more than two decades, these group of people kept inventing these processes, selling it as magic pill and made millions upon millions in consulting gigs, books, training, certifications and so on. They came up with Agile and 17 people in that group created “agile manifesto”. Their most aggressively marketed prescription was scrum. Like their all previous prescription, world is finally coming off of night of drinking cool aid and feeling severe headache.
I think most of these people have now sort of retired after amassing massive fortunes and hopefully we will not see more of these magic processes pushed to dumb CTOs with promises of curing all ills.
The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company. For everything else, it should never have been used. It is especially going to hurt creativity, originality and novelty if you are in business of making a differentiating unique novel product. It also is very very bad choice if you already had tier-1 highly motivated team.
So exercise caution!
I think even a tier-1 team could make it work for them, but the key is they would make it work for them (make it their own process).
Once you hire a scrum master to tell you how to do your work, you've sort of lost. They are rarely useful other than as sort of "priest" of the process, who ends up becoming another sort of management, but without management powers (usually).
The meetings etc. can be downright useful, in certain cases, but don't really make sense to follow religiously. I.e. if the devs themselves are running the meetings, for themselves, its a useful form of self-management, and you don't need much management skill to run it (any seasoned dev with any sort of communication capability can do it).
But if its imposed upon you, its just a cookie-cutter sort of management, which, doesn't fit all teams or scenarios.
Once you hire a scrum master to tell you how to do your work, you've sort of lost. They are rarely useful other than as sort of "priest" of the process, who ends up becoming another sort of management, but without management powers (usually).
The meetings etc. can be downright useful, in certain cases, but don't really make sense to follow religiously. I.e. if the devs themselves are running the meetings, for themselves, its a useful form of self-management, and you don't need much management skill to run it (any seasoned dev with any sort of communication capability can do it).
But if its imposed upon you, its just a cookie-cutter sort of management, which, doesn't fit all teams or scenarios.
Er, no.
First, Scrum is not XP. Huge difference.
Second, even XP is not a "magic bullet". Nothing is. It's work that works. (Scrum, on the other hand, is not a "magic bullet" but simply a "bullet". Use it to kill projects very effectively).
Third, at my first real job after uni, we did most of the XP-like practices, and it worked amazingly well. But we didn't know about "XP". Partly because it didn't exist yet, as this was around the same time the Kent Beck started at Chrysler Comprehensive. When the XP books came out it was fun to have a name for what we had been doing so successfully. And also to compare and contrast.
Fourth, I had a great side-by-side natural experiment during my tenure at the BBC. My team did XP-ish things, mostly the technical practices, so test first/TDD, YAGNI etc. Pairing when necessary, but we were co-located around a desk "island" (sort of the way journalist workspaces are organised). My team succeeded far beyond expectations [1]
The team next to us, larger, more important and with way more experienced developers did SCRUM, but not XP. That project had to be rebooted completely after 2 years.
[1] https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...
First, Scrum is not XP. Huge difference.
Second, even XP is not a "magic bullet". Nothing is. It's work that works. (Scrum, on the other hand, is not a "magic bullet" but simply a "bullet". Use it to kill projects very effectively).
Third, at my first real job after uni, we did most of the XP-like practices, and it worked amazingly well. But we didn't know about "XP". Partly because it didn't exist yet, as this was around the same time the Kent Beck started at Chrysler Comprehensive. When the XP books came out it was fun to have a name for what we had been doing so successfully. And also to compare and contrast.
Fourth, I had a great side-by-side natural experiment during my tenure at the BBC. My team did XP-ish things, mostly the technical practices, so test first/TDD, YAGNI etc. Pairing when necessary, but we were co-located around a desk "island" (sort of the way journalist workspaces are organised). My team succeeded far beyond expectations [1]
The team next to us, larger, more important and with way more experienced developers did SCRUM, but not XP. That project had to be rebooted completely after 2 years.
[1] https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...
> Their most aggressively marketed prescription was scrum.
I don't think Agile has prescribed this though. Scrum, in my view, is an intermediary 'solution' so non-technical 'bosses' can overlook and micromanage dev teams. I guess it all stems from 'unproductivity' really, those cases you mention, where you end up with sub-par devs trying to deliver complex software products.
I don't think Agile has prescribed this though. Scrum, in my view, is an intermediary 'solution' so non-technical 'bosses' can overlook and micromanage dev teams. I guess it all stems from 'unproductivity' really, those cases you mention, where you end up with sub-par devs trying to deliver complex software products.
What's wrong with TDD
If you don't already have a clear spec for what your code needs to do, it's essentially doubling what you need to code for no real gain.
I'd argue the opposite:
If you already know _exactly_ what your code needs to do, you can "just implement it".
I find TDD to be very helpful in the cases where I do _not_ know everything in advance, because it lets me take small steps to explore things and I get very fast feedback if I "misstepped".
If you already know _exactly_ what your code needs to do, you can "just implement it".
I find TDD to be very helpful in the cases where I do _not_ know everything in advance, because it lets me take small steps to explore things and I get very fast feedback if I "misstepped".
All of the methods mentioned are based on a reasonable core. It muddles the waters and make the snake oil marketing - the "this is the cure to it all" discourse - harder to dismiss. Testing is good. Planning is good. Discussing the project is good. But these things are beside the point of op. The point is, these cargo cults are designed to make consultants money. Now they have a lot of inertia because people grow up on it.
It seems like the new generation of software development silver bullets is "microservice", cloud "devops" etc... Managed kubernetes is not a bad thing. Configuration files, software defined infrastructure, etc, not bad things at all. But there is a definite market push in consulting for overtly complicated frameworks as The Way and people who are anxious about their complicated projects gobble it up.
It seems like the new generation of software development silver bullets is "microservice", cloud "devops" etc... Managed kubernetes is not a bad thing. Configuration files, software defined infrastructure, etc, not bad things at all. But there is a definite market push in consulting for overtly complicated frameworks as The Way and people who are anxious about their complicated projects gobble it up.
It is dogmatic.
>The truth is Scrum was never a magic bullet and it is downright harmful for many projects. It is useful for highly predictable projects where research component is negligible, for example, CRUD websites AND where you are stuck with unmotivated tier-3 talent who failed to get job at insurance company.
Nailed it.
Nailed it.
Scrum puts "feel good" limits around the unknown qualities of time-to-complete and "divide and conquer"
You still don't really know when it will be ready, but you now have talking points with management about a) whats been done and b) how complex it is. This builds belief: Belief there will be a solution, and Belief you can find it.
Nothing not said better by others here, but I say this as a party who was dragged kicking and screaming into the process to be an agile product manager, hated it, and got out. I totally "get" why people want this. It's very rare to be a Bell Labs, or Xerox Parc, and have pretty much complete freedom to spend budget and deliver an outcome when it's ready.
I also have worked on large s/w projects which cost $16m to fail to work, and $60m in lawsuits out the other side. I know that the alternative (a massive proscriptive playbook of minute details of functions, UML, flowcharts, you-name-it) exists and works, or not (depending on your point of view).
Really? I think scrum was the wrong name. The process itself, is fine. Talking to your co-workers builds a sense of purpose and direction.
You still don't really know when it will be ready, but you now have talking points with management about a) whats been done and b) how complex it is. This builds belief: Belief there will be a solution, and Belief you can find it.
Nothing not said better by others here, but I say this as a party who was dragged kicking and screaming into the process to be an agile product manager, hated it, and got out. I totally "get" why people want this. It's very rare to be a Bell Labs, or Xerox Parc, and have pretty much complete freedom to spend budget and deliver an outcome when it's ready.
I also have worked on large s/w projects which cost $16m to fail to work, and $60m in lawsuits out the other side. I know that the alternative (a massive proscriptive playbook of minute details of functions, UML, flowcharts, you-name-it) exists and works, or not (depending on your point of view).
Really? I think scrum was the wrong name. The process itself, is fine. Talking to your co-workers builds a sense of purpose and direction.
[deleted]
I would have guessed more HN readers would attempt to understand the desired outcomes, how the implementation attempts to achieve them, then take the good from the bad as a source of constant improvement.
The tone on this thread has that jaded and defeatest "management sucks" attitude that I find most often in the least productive engineers regardless of how they work.
The tone on this thread has that jaded and defeatest "management sucks" attitude that I find most often in the least productive engineers regardless of how they work.
I'll be the first to admit that managing a complex project's timeline is not a skill of mine. All I know is that the franken-scrum monstrosities that I have been subjected to in various organizations have all had a very negative impact on my morale and productivity. The problem I see is that the the business will want to make tradeoffs that the developers may not like. How you reconcile the two without hurting morale is the challenge. I left my last company largely because their version of scrum was sucking the life out of me.
My problem is not whether I “like” management’s tradeoffs they force me as a developer to make; my problem is that managements typically don’t take accountability for choosing to make them.
And then management (and their allies in the closely aligned “Software Craftsmanship” movement) blame the developers for the consequences of those tradeoffs and all the technical debt that typical entails.
And then management (and their allies in the closely aligned “Software Craftsmanship” movement) blame the developers for the consequences of those tradeoffs and all the technical debt that typical entails.
> then take the good from the bad as a source of constant improvement.
I worked as an engineer, PM, and a manager, when I was an engineer and scrum was applied wrongly, I tried to communicate for that “continuous improvement”, but that only works with an actual leaderships that listen, 99% of your middle management are just power hungry folks that are kept in their positions to take the shit instead of senior managements, when I worked as a PM however and tried to customize those agile tools per project and per team personalities too, everyone was happy, projects got delivered and things worked as expected. In 90% those situations you can never blame the engineers, look at the work environment as a workshop, the guy working in that shop is the PM and the tools are your engineers, ultimately that guy is accountable for the success or failure to deliver that work, if you start blaming the tools you have in the workshop, then you are the incompetent one, simply put.
I worked as an engineer, PM, and a manager, when I was an engineer and scrum was applied wrongly, I tried to communicate for that “continuous improvement”, but that only works with an actual leaderships that listen, 99% of your middle management are just power hungry folks that are kept in their positions to take the shit instead of senior managements, when I worked as a PM however and tried to customize those agile tools per project and per team personalities too, everyone was happy, projects got delivered and things worked as expected. In 90% those situations you can never blame the engineers, look at the work environment as a workshop, the guy working in that shop is the PM and the tools are your engineers, ultimately that guy is accountable for the success or failure to deliver that work, if you start blaming the tools you have in the workshop, then you are the incompetent one, simply put.
The guys here come to the scrum retrospectives, stay silent the entire time, and then complain that scrum sucks.
I think Scrum done well works rather well but retrospectives tend to be a lie.
Teams generally aren't allowed to stop doing sprints. In some places they aren't even allowed to pick start and end dates because management wants all teams on the same cadence.
If you use Jira - there's often all kinds of stupid imposed workflows. Mandatory fields depending on ticket types etc. If it's not useful to your team - tough shit, you don't have a choice.
Want to stop doing story points and use tshirt sizes? You can't, management monitors velocity as performance indicator.
Once you've had a few suggestions shot down because of top-down mandates, why even bother with retros?
Basically, scrum is very frequently a top-down management technique and teams aren't actually self-organizing because management can't deal with 10 teams each doing things their own way.
Teams generally aren't allowed to stop doing sprints. In some places they aren't even allowed to pick start and end dates because management wants all teams on the same cadence.
If you use Jira - there's often all kinds of stupid imposed workflows. Mandatory fields depending on ticket types etc. If it's not useful to your team - tough shit, you don't have a choice.
Want to stop doing story points and use tshirt sizes? You can't, management monitors velocity as performance indicator.
Once you've had a few suggestions shot down because of top-down mandates, why even bother with retros?
Basically, scrum is very frequently a top-down management technique and teams aren't actually self-organizing because management can't deal with 10 teams each doing things their own way.
Tried saying "this process sucks, can we do it better?". Was told that Scrum is what all organisations use, there's nothing else (except Waterfall), and that this is "best practice".
The people who are silent in the retros are probably jaded and cynical about the whole process. And if the manager knew their shit, they'd do something about that instead of accepting that some of their team are not engaged with the process.
The people who are silent in the retros are probably jaded and cynical about the whole process. And if the manager knew their shit, they'd do something about that instead of accepting that some of their team are not engaged with the process.
Or maybe they have tried speaking out, only to be chewed and digested for daring to raise their voice. Life is not black and white
Too true, seen it so many times.
I'm also very surprised by what the overall thread is saying.
Scrum and the agile movement in general have been a revolution for the better in management and organization, in my point of view.
I must live in some kind of alternative reality where 80% of teams that I worked with liked Scrum (and I lead tens of teams).
The remaining teams just needed Kanban.
Not sure what everybody else is doing here, but I have seen teams where before we started doing scrum+jira all tasks were coming on Skype and discord, and stakeholders were either micromanaging (programmers managed by non-programmers) or either would forget project for 1 month and would come back to find something delivered that completely missed expectations.
After moving to proper task tracking and clear planning and review rituals, the developer satisfaction went through the roof (before that people were borderline considering quiting)
The remaining teams just needed Kanban.
Not sure what everybody else is doing here, but I have seen teams where before we started doing scrum+jira all tasks were coming on Skype and discord, and stakeholders were either micromanaging (programmers managed by non-programmers) or either would forget project for 1 month and would come back to find something delivered that completely missed expectations.
After moving to proper task tracking and clear planning and review rituals, the developer satisfaction went through the roof (before that people were borderline considering quiting)
> I must live in some kind of alternative reality where 80% of teams that I worked with liked Scrum (and I lead tens of teams).
I think it has a lot to do with how good estimates can be, and how much can be shared between the members of the team. The extreme situation where the tasks are all boring/predictable and everyone in the team can do everything probably works well with Agile (or any estimation-based religion, I suppose).
The problem is that in many situations, many tasks are not very predictable (because they involve novelty, risk, exploration, challenge), and not everyone is capable of doing everything. In that case the estimates are a big joke, and Agile is just bullshit.
I think it has a lot to do with how good estimates can be, and how much can be shared between the members of the team. The extreme situation where the tasks are all boring/predictable and everyone in the team can do everything probably works well with Agile (or any estimation-based religion, I suppose).
The problem is that in many situations, many tasks are not very predictable (because they involve novelty, risk, exploration, challenge), and not everyone is capable of doing everything. In that case the estimates are a big joke, and Agile is just bullshit.
I'm one that prefers Kanban myself. List each task, be able to group those tasks, move those tasks to whoever needs them, move those tasks to QA or wherever finished tasks go. So, I prefer Trello over Jira any day
How do you "prefer kanban"? Don't all these methodologies use kanban boards?
Kanban is more than just a board. To have effective Kanban your process needs to:
1. Be pull based - someone only picks something new up when they have the capacity to do so. There's no "finish this set of tasks by the end of the sprint" because there are no sprints, just priorities
2. Manage work-in-process, either explicitly or implicitly. This prevents the team working on too many things at once, which leads to any given piece of work taking a long time to get to production
1. Be pull based - someone only picks something new up when they have the capacity to do so. There's no "finish this set of tasks by the end of the sprint" because there are no sprints, just priorities
2. Manage work-in-process, either explicitly or implicitly. This prevents the team working on too many things at once, which leads to any given piece of work taking a long time to get to production
Kanban (for the definition as I understand it) ditches sprints. There's the backlog, tickets that are ready to be worked on, in progress tickets, and various flavors of "done". It's common for kanban teams to ship directly to production once tasks/stories are merged in.
Scrum I think is pretty bad. It’s designed to work in contract shops where you have a short window deliverable for the customer, and isn’t really well designed for a more collaborative development process. Also the cargo culting meetings are pointless.
Agile in theory is great, teams should just do what works for them. End of story. But the issue is that agile and scrum are synonymous in the “agile” industry of consultants selling agile training to companies which largely drives how it’s practiced.
Kanban I think is a great organizational method though. It tracks work, shows what needs to be done and the progress. And gets out of the way.
Agile in theory is great, teams should just do what works for them. End of story. But the issue is that agile and scrum are synonymous in the “agile” industry of consultants selling agile training to companies which largely drives how it’s practiced.
Kanban I think is a great organizational method though. It tracks work, shows what needs to be done and the progress. And gets out of the way.
I hope people read this person's full post. he says, "I believe in Agile, but this ain't agile."
Yeah, agile and scrum aren't the same. In my humble opinion, agile process is pretty fantastic and a lot better than waterfall (although waterfall has some elements that should be carried over to agile) or even Rational Unified Process. Yeah, Agile is taking over the engineering world (not just software) for a reason, because iterative development using small teams works.
Yeah, agile and scrum aren't the same. In my humble opinion, agile process is pretty fantastic and a lot better than waterfall (although waterfall has some elements that should be carried over to agile) or even Rational Unified Process. Yeah, Agile is taking over the engineering world (not just software) for a reason, because iterative development using small teams works.
I once blew a team's mind by this simple demonstration:
1) Searched the entire agile manifesto site for "sprints", "stories", "velocity", "stand ups" etc. Zero references.
2) Searched the official scrum guide for the words "agile", "stories", "story points". Zero references. It only defined sprints.
1) Searched the entire agile manifesto site for "sprints", "stories", "velocity", "stand ups" etc. Zero references.
2) Searched the official scrum guide for the words "agile", "stories", "story points". Zero references. It only defined sprints.
https://agilemanifesto.org/principles.html
Read through the principles and then find out how it maps to scrum.
Scrum is not the same as "Agile", but it tries to provide a simple methodology to implement parts of it.
> continuous delivery of valuable software
> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
That's a sprint in Scrum.
> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
A stand-up is one way to do it. Standing and talking face to face may seem foreign to people used to sit all day in front of computer screens, but I think it's worth trying... ;-)
and so on.
Read through the principles and then find out how it maps to scrum.
Scrum is not the same as "Agile", but it tries to provide a simple methodology to implement parts of it.
> continuous delivery of valuable software
> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
That's a sprint in Scrum.
> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
A stand-up is one way to do it. Standing and talking face to face may seem foreign to people used to sit all day in front of computer screens, but I think it's worth trying... ;-)
and so on.
In some cases having a formalized process/methodology helps to appear professional and hide the fact that nobody knows exactly what they're doing. I've seen it it some place - very serious software dev company delivering very serious medical software, but in fact the whole team was just faking it and trying to keep up the professional image. The developers were random people without business domain knowledge, managers were managing the work without understanding it, analysts were producing some documents that nobody understood, customer approved some scopes hoping that the specification is actually what is needed (but in vain). The team was assembled from contractors, and people rotated quite frequently so that there was no chance for them to acquire the domain knowledge necessary to talk to the customer. It was just painful to take part in it, but took me some time before i realized in fact everyone is just pretending to understand what's going on. Endless approvals and multi-step procedures required for medical stuff just made the whole thing impossible to understand and smeared the responsibility so broadly that it was guaranteed there's no single person that knows too much.
I agree it's rarely "done right", but I've been in career long enough that waterfall was still common early in career and horrible crunch time targeting some date at end of 9-12 months projects was inevitable - Scrum was a total breath of fresh air back in 2005-2006 and saved my sanity.
Basically we'd ask mgmt "what do you want next?" and they had to fuck off for the next 4 weeks while devs, ux, QA worked with no changes in plans until next demo and release. They were responsible for figuring out "when will everything be done?" etc.
I recently left a startup that said they were "doing Scrum" and it was just daily task tracking and pushing devs to overcommit to each sprint - that's not what I consider Scrum.
Basically we'd ask mgmt "what do you want next?" and they had to fuck off for the next 4 weeks while devs, ux, QA worked with no changes in plans until next demo and release. They were responsible for figuring out "when will everything be done?" etc.
I recently left a startup that said they were "doing Scrum" and it was just daily task tracking and pushing devs to overcommit to each sprint - that's not what I consider Scrum.
I should clarify: we had one of the early Scrum guys (Ken Schwaber) come in and train devs, QA, UX, and management - so there was little room for people to hide behind random interpretations of "agile" and it really helped us to start out correctly.
"pushing devs to overcommit to each sprint"
Yeah, that's definitely not Scrum like you said. The whole point is that the team promises to deliver features during a sprint and won't overcommit, they might deliver extra if they have extra time.
If your sprints continuously fail to deliver, then you need to decrease the team's velocity.
Yeah, that's definitely not Scrum like you said. The whole point is that the team promises to deliver features during a sprint and won't overcommit, they might deliver extra if they have extra time.
If your sprints continuously fail to deliver, then you need to decrease the team's velocity.
Yeah it was really messed up - their "velocity tracking" was so they could make sure devs committed to at least as many points as the last sprint, even if they didn't finish the last sprint.. I only lasted there 4 months before I quit.
Anecdotes #6 and #7 in their list is a real indicator of something bad, wholly unrelated to Scrum.
> #6 We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points."
> #7 Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.
> #6 We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points."
> #7 Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.
Agile is a cancer too: In many orgs, Agile is essentially synonymous with chaos. Zero look-ahead. Let's do it first and fix it later. Later never comes.
I believe 99% of Agile's value comes from caring about developers and letting them pride themselves with their progress.
Managers benefit from regularly reminding devs that their progress is not measured by amount of code, but working features. "Can you do a demo?"
Care about your devs, let them demonstrate progress. There, I just invented another Agile framework.
I believe 99% of Agile's value comes from caring about developers and letting them pride themselves with their progress.
Managers benefit from regularly reminding devs that their progress is not measured by amount of code, but working features. "Can you do a demo?"
Care about your devs, let them demonstrate progress. There, I just invented another Agile framework.
100% scrum might work in very simple projects.
Once things become difficult, challenging, or new, it's garbage.
Projects that are taking more story points than expected are "behind schedule". No, your shitty schedule is the problem, because you were unable to estimate the difficulty of doing something new. And that's the hard thing about hard things. Maybe it will be done in 3 days or maybe you'll need 2 weeks, but you can't do that with very difficult things.
Scrum is an attempt to label Parkinson's Law: that a task will expand to fit the time it is allocated in the schedule.
With people that need to be micromanaged, and tasks that you know how to do but take time, scrum can work. This is because it basically gives you a way to measure whether you believe a junior developer is performing up to the level of expected, rather than slacking off or sandbagging.
Personally, I hate scrum.
Once things become difficult, challenging, or new, it's garbage.
Projects that are taking more story points than expected are "behind schedule". No, your shitty schedule is the problem, because you were unable to estimate the difficulty of doing something new. And that's the hard thing about hard things. Maybe it will be done in 3 days or maybe you'll need 2 weeks, but you can't do that with very difficult things.
Scrum is an attempt to label Parkinson's Law: that a task will expand to fit the time it is allocated in the schedule.
With people that need to be micromanaged, and tasks that you know how to do but take time, scrum can work. This is because it basically gives you a way to measure whether you believe a junior developer is performing up to the level of expected, rather than slacking off or sandbagging.
Personally, I hate scrum.
After 10 years in software development, going from junior to lead, I still fail to see the benefit of sprints. The best performing teams that I have been part of all worked around it, in order to make the team look good, in the eyes of the customer whom we sold Scrum to.
For features, I'd say that Kanban works better, when mixed with ideas from Scrum. Most of Scrum's ceremonies are useful without sprints, and gives, in my experience, the same value to managers as they do in Scrum. The overhead in administration and time that sprints bring are not worth it at all, though. And if management wants, commitments and planning can be done against a deadline, in the same way they'd do with sprints, just without the artificial short periods.
The tweet however contains lots of bad management, and general bullshit otherwise.
"Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously." I think this is fantastic, not having a single boss, but having different "hats". One person can also have multiple, for different projects. In my experience, this worked out well.
T-shirt and poker.... I don't see why they don't work as analogies, and therefore this is moot criticism.
Even the author himself acknowledges: that wasn't scrum, they were doing scrum wrong. So stop doing scrum? Why not do scrum better? What makes him think that the same bad management will do any other methodology better?
For features, I'd say that Kanban works better, when mixed with ideas from Scrum. Most of Scrum's ceremonies are useful without sprints, and gives, in my experience, the same value to managers as they do in Scrum. The overhead in administration and time that sprints bring are not worth it at all, though. And if management wants, commitments and planning can be done against a deadline, in the same way they'd do with sprints, just without the artificial short periods.
The tweet however contains lots of bad management, and general bullshit otherwise.
"Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously." I think this is fantastic, not having a single boss, but having different "hats". One person can also have multiple, for different projects. In my experience, this worked out well.
T-shirt and poker.... I don't see why they don't work as analogies, and therefore this is moot criticism.
Even the author himself acknowledges: that wasn't scrum, they were doing scrum wrong. So stop doing scrum? Why not do scrum better? What makes him think that the same bad management will do any other methodology better?
Usually mindless implementation of some buzzword process in its entirety is doomed to failure. I worked for a manufacturing company a number of years ago. I was a developer, working on machine control software.
Management decided that the company needed to implement the 5S workspace management system company wide. In short, one focus of the system is to help you put tools and materials back in the right spot to keep the workspace organized for the next person that needs to use it.
This is helpful for organizing the manufacturing workspaces where different employees would be coming in on different shifts and using the same space.
They had engineering (software, mechanical, electrical) doing the same thing. They sent up rolls of different colors of tape so we could mark all the stuff on our desks and asked us to write documentation about our workspaces. We were all marking off with tape "Keyboard", "Mouse" and "Stapler". It was truly asinine. I left the company shortly after that.
Management decided that the company needed to implement the 5S workspace management system company wide. In short, one focus of the system is to help you put tools and materials back in the right spot to keep the workspace organized for the next person that needs to use it.
This is helpful for organizing the manufacturing workspaces where different employees would be coming in on different shifts and using the same space.
They had engineering (software, mechanical, electrical) doing the same thing. They sent up rolls of different colors of tape so we could mark all the stuff on our desks and asked us to write documentation about our workspaces. We were all marking off with tape "Keyboard", "Mouse" and "Stapler". It was truly asinine. I left the company shortly after that.
I hope someone had the acerbic wit to label the tape 'tape'
one of my former companies went all in on scrum/agile/whatever you want to call it.
In ops, I think sprints work uniquely terribly. Lots of super urgent tasks come up in a normal workday that aren't always captured in the workload or capacity planning, and some times are much more interrupt driven than others, leading to similar issues.
Another issue I had with it, it did not really encourage me to be super productive . Like, I took on 16 story points this sprint, finished them all in a week, what possible incentive do I have to take something off the backlog and squeeze it into this sprint when my teammates (some of whom are paid more than me) are doing half of the "points" I am? It creates tension where I don't think any is needed. To make things worse, the system is easily gamed.
Another thing is I think it created way way more meetings than was needed.
In ops, I think sprints work uniquely terribly. Lots of super urgent tasks come up in a normal workday that aren't always captured in the workload or capacity planning, and some times are much more interrupt driven than others, leading to similar issues.
Another issue I had with it, it did not really encourage me to be super productive . Like, I took on 16 story points this sprint, finished them all in a week, what possible incentive do I have to take something off the backlog and squeeze it into this sprint when my teammates (some of whom are paid more than me) are doing half of the "points" I am? It creates tension where I don't think any is needed. To make things worse, the system is easily gamed.
Another thing is I think it created way way more meetings than was needed.
First off define what is scrum for you
For me scrum is daily 10min meeting and that's it
and I like it, I don't have problem with one quick meeting to sync.
But when I hear stories about estimations in some imaginary units, then it sounds bad.
For me scrum is daily 10min meeting and that's it
and I like it, I don't have problem with one quick meeting to sync.
But when I hear stories about estimations in some imaginary units, then it sounds bad.
I have delivered successfully projects using Scrum, but we were fortunate that our Scrum Master was well trained and a senior engineer. Our CTO also let us figure things out, and helped us when we were blocked. He was genuinely concerned with the team having a balanced workload, ensured we deliver user value and our software was of high quality. Story points were not used as performance metrics but a tool to help provide stakeholders with some estimation, but only when our velocity became stable. Overall, our process was light-weight, we spent most of our time coding, and we pushed hard to deliver value to the user. If we fell short, we learned from it, no blame, just learned.
agile, scrum, sprints are all bullshit, software & development are endurance, long-distance running, you only need some milestones for releases, but never ever 1 week or 2 week sprints
Scrum is a good tool for a bad manager https://www.yegor256.com/2015/01/08/morning-standup-meetings...
This dude talks about directly punishing people for not meeting deadlines and monetary rewards for completing tasks. This is weird, patronizing, de-motivating. I would run from him as fast as possible.
> She already knows what she is working for, and she is motivated enough. When she finishes on time, organize a meeting and give her a $500 check in front of everybody. This is what a good manager uses meetings for.
> She already knows what she is working for, and she is motivated enough. When she finishes on time, organize a meeting and give her a $500 check in front of everybody. This is what a good manager uses meetings for.
the article is satire - at least i consider it so - but it describes the whole scrum charade pretty well
Over the past ten years, I've made sure our team's rely on scum and agile less and less. We still have a minimal board, and standups, but that's it. No extra meetings. No definition of done. No stories. We just talk when needed. In practice, any work done to define in the card is likely to slightly change when there's new knowledge anyway. We find our approach substantially more flexible, agile, and stress free.
One of our engineers today said that he felt bad that some of the cards were on the board for so long. He was self conscious about some false sense of velocity that was expected. I told him it's just a page on the internet with some text on it. Scrum, with its frameworks and ideology and self righteous way of looking like a way to be performant and sophisticated, is just some words on a page and some performative meetings. Poor guy was getting distracted by that.
The goal of scrum is to let middle management and non coders bring Science(c) to the organization. There's a culture fostered by executives, consultants, that posits that engineers don't understand what to work on and waste time, therefore we need this stuff to run a tighter ship. As it happens, it'd also what justifies middle management's jobs.
Scrum is good at tightening things that work, or making work feel predictable. A lot of growth scenarios or experimentation aren't predictable, so it becomes more like a broken dogma that serves the needs of the bureaucracy.
One of our engineers today said that he felt bad that some of the cards were on the board for so long. He was self conscious about some false sense of velocity that was expected. I told him it's just a page on the internet with some text on it. Scrum, with its frameworks and ideology and self righteous way of looking like a way to be performant and sophisticated, is just some words on a page and some performative meetings. Poor guy was getting distracted by that.
The goal of scrum is to let middle management and non coders bring Science(c) to the organization. There's a culture fostered by executives, consultants, that posits that engineers don't understand what to work on and waste time, therefore we need this stuff to run a tighter ship. As it happens, it'd also what justifies middle management's jobs.
Scrum is good at tightening things that work, or making work feel predictable. A lot of growth scenarios or experimentation aren't predictable, so it becomes more like a broken dogma that serves the needs of the bureaucracy.
Many of these management techniques require a well-run shop to work well. They are not forgiving of riff raff and institutional dysfunction, and may even magnify dysfunction. So yes, they CAN work under ideal conditions, but ideal conditions are too rare, especially for non-IT domains who don't understand & value IT management.
Borrow the best fitting ideas from each methodology, but don't obsess on them.
Borrow the best fitting ideas from each methodology, but don't obsess on them.
I much prefer Kanban. No unnecessary time spent coming up with story points that will be inaccurate anyways and don't even provide much benefit.
My team does soft-agile. Month long sprints and minimal meetings. We treat it less like a rigid structure everyone must conform to and more of a way to organize backlog and delegate. It has worked very well for us, however we are a small and fairly siloed team and our stakeholders are highly technical people who consume our services internally. we get the leeway to self govern properly.
We have tried 2-3-4 week iterations, but keep coming back to 2 weeks. It's enough time to do something, but not so much people can get lost off track for a long time. But, we're also ok incrementally delivering features. No single feature has to be done in 2 weeks. Some take many iterations.
Also agree with minimal meetings. 1-2 meetings/iteration. When new people start we'll add some office hours time every other day as needed until they get up to speed.
Also agree with minimal meetings. 1-2 meetings/iteration. When new people start we'll add some office hours time every other day as needed until they get up to speed.
Six of the nine points is about estimates and I agree. And depending on who you ask estimates is or is not part of Scrum, but that doesn't really matter... you shouldn't be spending too much time of them and if your organization requires detailed estimates they simply don't understand "agile" and they are doing "Agile". The absolutely worst thing that I've experienced was the "story point budget negotiation" ... that is not how any of it works.
I totally agree with you, but I would add "for me".
I absolutely hate guidelines and processes and methodologies. I'm totally not a team player either. I need to have my own responsibilities. As ISTP personality these things are totally contrary to my personality.
As such I hate every methodology, of course right now agile (and Scrum as a subset of that) is the darling of every project manager so I hate it. But I do realize it would apply to every other type too.
But anyway I do as I've always done, the absolute minimum to comply with the framework and ignore what I can get away with. Because I get results this is accepted and I'm usually maneuvered into a niche area where I can perform.
For example I always stop logging my mandatory hours in Jira until I get reprimanded and then I stop again a few months later :P
Of course "logging hours in Jira" is our company's idea of "we're agile". We literally don't do anything else :P So it's easy to get away with.
I absolutely hate guidelines and processes and methodologies. I'm totally not a team player either. I need to have my own responsibilities. As ISTP personality these things are totally contrary to my personality.
As such I hate every methodology, of course right now agile (and Scrum as a subset of that) is the darling of every project manager so I hate it. But I do realize it would apply to every other type too.
But anyway I do as I've always done, the absolute minimum to comply with the framework and ignore what I can get away with. Because I get results this is accepted and I'm usually maneuvered into a niche area where I can perform.
For example I always stop logging my mandatory hours in Jira until I get reprimanded and then I stop again a few months later :P
Of course "logging hours in Jira" is our company's idea of "we're agile". We literally don't do anything else :P So it's easy to get away with.
I’ve had good experiences with scrum. I was on a team that was empowered to own and refine its practice. We were able to halve our cycle time and improve sprint planning to the point where we rarely overcommitted. It was great, and it was credited with the successful delivery of a major project.
Unfortunately, our management changed, and we were no longer empowered. The new manager had his own ideas for how things should be done, and that resulted in a replacement process that was worse. We lost the ability to do effective capacity planning and iterate quickly. It was terrible.
That’s really my biggest issue with agile. There’s a big focus on process, but it’s about the people. If the people aren’t empowered, it won’t work. If you’re not iterating and communicating, it won’t work. If someone’s not on board with that, they can sabotage things (intentionally or otherwise).
Unfortunately, our management changed, and we were no longer empowered. The new manager had his own ideas for how things should be done, and that resulted in a replacement process that was worse. We lost the ability to do effective capacity planning and iterate quickly. It was terrible.
That’s really my biggest issue with agile. There’s a big focus on process, but it’s about the people. If the people aren’t empowered, it won’t work. If you’re not iterating and communicating, it won’t work. If someone’s not on board with that, they can sabotage things (intentionally or otherwise).
> That’s really my biggest issue with agile. There’s a big focus on process, but it’s about the people
From the Agile Manifesto: Individuals and interactions over processes and tools. What you described doesn't sound Agile by the book.
From the Agile Manifesto: Individuals and interactions over processes and tools. What you described doesn't sound Agile by the book.
That’s fair, and you’re right. I apologize for being unclear. Perhaps I should have quoted it to reflect that my issue is with what gets called “agile” rather than what the practice is supposed be (and the former seems unfortunately common).
If you're in a situation where someone is suggesting applying an off-the-shelf process like Scrum or SAFe, you've already lost.
> 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
This continues to be one of the most aggravating parts of capital A Agile software development. Forcing people to be uncomfortable to make them talk less is something a child would come up with.
> 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
This continues to be one of the most aggravating parts of capital A Agile software development. Forcing people to be uncomfortable to make them talk less is something a child would come up with.
If you’re going to have lots of unnecessary meetings, it’s important to keep them short or no one will have time to do work.
I probably said it before in a previous post, but the problem isn’t scrum/agile per se, it’s just a tool, the problem is the inexperienced PM who thought just because it was applied in their previous company or another big tech, then it must be the secret formula for success, that, or as OP said, abused by control freak managers to micro-manage the team more, like poor soul I know, they had meetings for meetings..
I remember one time got in several conflicts with a manager who -again- is trying to copy-cat all these shenanigans like standup and what not even though neither the work nor the team nature fits that type of work, first, I wrote him that wasn’t the best approach and better to use these tools, second I tried to communicate that face to face, third, I actually applied these tools I was suggesting in a project I am doing as a way to show an example how it’s done maybe that will convince him, unfortunately, nothing worked with him, it was “my wrong way or the highway” approach, he wasn’t even certified PM with no training and I was, had to leave them after delivering my project.
I remember one time got in several conflicts with a manager who -again- is trying to copy-cat all these shenanigans like standup and what not even though neither the work nor the team nature fits that type of work, first, I wrote him that wasn’t the best approach and better to use these tools, second I tried to communicate that face to face, third, I actually applied these tools I was suggesting in a project I am doing as a way to show an example how it’s done maybe that will convince him, unfortunately, nothing worked with him, it was “my wrong way or the highway” approach, he wasn’t even certified PM with no training and I was, had to leave them after delivering my project.
"Agile is a cult." Is a refrain I've had for a few years. I don't mean like the agile process, I mean the agile culture. I went to an agile conference for work and the things they talked about were just really really dumb, I swear they almost professed that agile could cure cancer.
I think it's Scrum that's a cult, agile works fine in the rare place that does it.
But to me it just means trusting the devs, close cooperation within the team and with the customer, iterative development, continuously refining the bits of process you have to fit the needs of the devs at the moment.
Not something you have conferences about.
But to me it just means trusting the devs, close cooperation within the team and with the customer, iterative development, continuously refining the bits of process you have to fit the needs of the devs at the moment.
Not something you have conferences about.
What's the difference between what you're talking about and scrum? IMO the conferences are really there because the way companies think about projects and plans is not agile and it's difficult to marry up the higher level decision making with the way that agile makes decisions much faster. I don't think there has really been a solution to this.
Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work. If it turns out that the goals of the company are stupid or won't work how does it "realise" that? Lets say you're fulfilling a contract - you really need to go to your customer and tell them that what they want will end up being of low quality at the time and price you've agreed and that adjustments have to be made if they want a success. I cannot see any incentive to try to do such a thing so it's at odds with agile from the start.
Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work. If it turns out that the goals of the company are stupid or won't work how does it "realise" that? Lets say you're fulfilling a contract - you really need to go to your customer and tell them that what they want will end up being of low quality at the time and price you've agreed and that adjustments have to be made if they want a success. I cannot see any incentive to try to do such a thing so it's at odds with agile from the start.
Scrum is a strictly defined process, it has Scrum Masters, Product Owners, certifications, books, a number of defined meetings, sprints...
Sort of the opposite of agile.
> Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work
Exactly. But with Scrum, if devs complain it's not working, the certified Scrum Master will just say what you're doing right now isn't exactly Scrum to the letter yet, you need more Scrum.
Sort of the opposite of agile.
> Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work
Exactly. But with Scrum, if devs complain it's not working, the certified Scrum Master will just say what you're doing right now isn't exactly Scrum to the letter yet, you need more Scrum.
Scrum includes retrospectives - they exist to change the process. If the process cannot be changed then it's not scrum.
OTOH when you're starting out it takes some time to find out what works and a scrum master will probably want to make you try to stick to the basics until you've given them a chance. Most people cannot see the point of one part or another until it has helped them personally once. After a while the team should be able to have a rotating scrum master - one of the team for a sprint.
OTOH when you're starting out it takes some time to find out what works and a scrum master will probably want to make you try to stick to the basics until you've given them a chance. Most people cannot see the point of one part or another until it has helped them personally once. After a while the team should be able to have a rotating scrum master - one of the team for a sprint.
In my experience, the best you can hope for from retrospectives is small tweaks. The length of sprints, how standups should go, who writes what in tickets.
But you can't change the process to be not-Scrum.
Once a company has decided "we do Scrum", you can't argue in retrospectives that sprints are completely artificial and unnecessary for the project in this phase, or that things would go much smoother if devs talked directly to the customer instead of through a product owner. Or even that tickets on a board are not a useful way to work at the moment. Things have to stay Scrum.
But you can't change the process to be not-Scrum.
Once a company has decided "we do Scrum", you can't argue in retrospectives that sprints are completely artificial and unnecessary for the project in this phase, or that things would go much smoother if devs talked directly to the customer instead of through a product owner. Or even that tickets on a board are not a useful way to work at the moment. Things have to stay Scrum.
Why not?
I talked to customers as a dev - it's just that customers couldn't come and pester me to make me do extra work or change priorities. Is that too hard or inconvenient to understand?
Scrum fits new development more than maintenance and I've never found any other "phase" where it doesn't fit reasonably. I've been in situations where I've thought we needed longer sprints.
Ultimately if the overhead is too much we used the retrospectives to remove it.
The problem is if you're the only one in the team that wants some change - then you cannot force it.
I talked to customers as a dev - it's just that customers couldn't come and pester me to make me do extra work or change priorities. Is that too hard or inconvenient to understand?
Scrum fits new development more than maintenance and I've never found any other "phase" where it doesn't fit reasonably. I've been in situations where I've thought we needed longer sprints.
Ultimately if the overhead is too much we used the retrospectives to remove it.
The problem is if you're the only one in the team that wants some change - then you cannot force it.
If you thing scrum is bad, try adopting scaled agile. It's so bad that our new CEO who introduced it less than a year ago tried to pull the Steve Jobs reality distortion trick to convince everyone in a recent all hands that "we're not Scaled Agile, we never have been. We used little parts of it to make something better that's all our own".
What you need to recognize with all these processes that go beyond the direct dev team is that they are not there for the devs. They're for senior leadership and non-technical executives to pretend they can have their cake (agile with responsive and constant delivery) and eat it too (waterfall with scheduled "final" delivery). It still sucks but this understanding does help you survive.
What you need to recognize with all these processes that go beyond the direct dev team is that they are not there for the devs. They're for senior leadership and non-technical executives to pretend they can have their cake (agile with responsive and constant delivery) and eat it too (waterfall with scheduled "final" delivery). It still sucks but this understanding does help you survive.
My experience with scrum is: metric driven development.
Not metric as in the measure of the effect of your code, but Jira (or whatever your task manager is) metrics. It systematize the process, without taking the actual work into consideration. This is why you get a "but you did the other similar project with just 50 points."
The metrics always win because developers end up working overnight to complete the project on time. So it validates the metrics.
My teammates message me when they find issues with their task. We discuss, hop on calls, involve other teammates, the works. But then on the daily stand up, we repeat the issue to the scrum master, even though this person could care less about the issue.
Scrum is a fantastic tool if your job involves making reports about the work being done. Except, it doesn't reflect the actual work being done. And my poor reader, you are probably not in a position where you can do something about it.
Not metric as in the measure of the effect of your code, but Jira (or whatever your task manager is) metrics. It systematize the process, without taking the actual work into consideration. This is why you get a "but you did the other similar project with just 50 points."
The metrics always win because developers end up working overnight to complete the project on time. So it validates the metrics.
My teammates message me when they find issues with their task. We discuss, hop on calls, involve other teammates, the works. But then on the daily stand up, we repeat the issue to the scrum master, even though this person could care less about the issue.
Scrum is a fantastic tool if your job involves making reports about the work being done. Except, it doesn't reflect the actual work being done. And my poor reader, you are probably not in a position where you can do something about it.
Worked for a consulting company that was heavily into Agile. You were given an Agile book just for making the final interview. I honestly can't say it was 'agile's' fault but every decision we made in the project I worked on was completely overwrought and fraught with bike shedding, which could only be resolved by the underlying power dynamics where some people were in power and some weren't. The client eventually pulled the plug on our project which we failed to deliver. Not that we failed a specific delivery date; afaik we didn't have a set deadline for the project. I think back on it sometimes as an example of how not to be.
This guy is a grifter with uninformed, ranty opinions, and it's a shame he is getting so many of these HN eyeballs for his purposefully provocative nonsense.
Here's my more comprehensive post the last time this was raised: https://news.ycombinator.com/item?id=37289151#37290237
The TL;DR is that he's just making unsubstantiated angry ravings and being treated like he's saying something meaningful because there are people on this site who happen to agree with him.
But if course, if you pay him, he'll say whatever you like, per his website.
Here's my more comprehensive post the last time this was raised: https://news.ycombinator.com/item?id=37289151#37290237
The TL;DR is that he's just making unsubstantiated angry ravings and being treated like he's saying something meaningful because there are people on this site who happen to agree with him.
But if course, if you pay him, he'll say whatever you like, per his website.
I think the reason he's getting upvotes is that a lot of people have had similar experiences. It should be obvious that adopting Scrum won't fix a dysfunctional organization[1]; nothing in the previous post, nor this one argues more than that.
I'm more interested in some of the comments I have seen here of people observing the adoption of Scrum as significantly reducing the velocity at what was previously observed to be well run. Maybe adopting the more formal process revealed an underlying organizational dysfunction that could remain hidden in the previous laissez-faire culture, maybe there's something wrong with how Scrum gets implemented at those places, and maybe there's actually something wrong with Scrum itself.
My only interaction with things explicitly described as "agile" (Scrum, or otherwise) appeared to be very large organizations mostly just renaming roles and processes that already existed, with a few minor changes that did not appear to have any effect (other than being able to claim that they were now "agile"), so I don't have any personal experience to answer any of these questions.
1: Though in defense of the ranters, you'll be able to find many Scrum consultants that will argue it can.
I'm more interested in some of the comments I have seen here of people observing the adoption of Scrum as significantly reducing the velocity at what was previously observed to be well run. Maybe adopting the more formal process revealed an underlying organizational dysfunction that could remain hidden in the previous laissez-faire culture, maybe there's something wrong with how Scrum gets implemented at those places, and maybe there's actually something wrong with Scrum itself.
My only interaction with things explicitly described as "agile" (Scrum, or otherwise) appeared to be very large organizations mostly just renaming roles and processes that already existed, with a few minor changes that did not appear to have any effect (other than being able to claim that they were now "agile"), so I don't have any personal experience to answer any of these questions.
1: Though in defense of the ranters, you'll be able to find many Scrum consultants that will argue it can.
I'm not going to provide a source, but I bet a lot of developers can relate to what he said. It feels like a lot of us have had Scrum shoved down our throats at some point or another and it feels great to finally lash out.
Writing software is more like writing books more than anything else. So any process that presupposes that the workload can be divided among roughly equal agents is bound to fail. That's my experience after two decades as a software engineer. Every good software team has two or three engineers who knows how to write books, how to structure a story, and can work towards a common vision. The rest of the team more often than not consists of tag-alongs that don't know nor care about good literature. Every good software project lets these two or three engineers get stuff done. Every bad software project suffocates these engineers with processes and/or makes them quit.
Removing the OP energy of "enrage to engage", I think there's a room for a more nuanced position.
It's a pity that we do not have more people doing systematic research related with Scrum/Agile practices and it's advantages, Regarding on outcomes, in comparison with RUP, empirically we know that it worked better based on economic results + adoption/spread + people empathetic to use it in a corporate environment.
However, after 22 years of Agile/Scrum we do not know in a systematic and in a scientific researched way the second order (side effects) of Scrum as a management tool, and which kinds of incentives it creates. We know empirically based in a small amount samples.
It's a pity that we do not have more people doing systematic research related with Scrum/Agile practices and it's advantages, Regarding on outcomes, in comparison with RUP, empirically we know that it worked better based on economic results + adoption/spread + people empathetic to use it in a corporate environment.
However, after 22 years of Agile/Scrum we do not know in a systematic and in a scientific researched way the second order (side effects) of Scrum as a management tool, and which kinds of incentives it creates. We know empirically based in a small amount samples.
I’ve managed teams that have been excellent without scrum. Then there’s one or two teams that just cannot get things done and are all over the place. Had to introduce scrum to get more structure and accountability to getting things done. Once the team started having a good cadence, slowly weaned off scrum.
Tldr; scrum is another tool in your toolbelt you can reach for. Some teams work better with scrum, some dont. Experiment and see which one works - ultimately the goal is the same which is a productive, well oiled machine, regardless of the ‘how’
Tldr; scrum is another tool in your toolbelt you can reach for. Some teams work better with scrum, some dont. Experiment and see which one works - ultimately the goal is the same which is a productive, well oiled machine, regardless of the ‘how’
This is the correct answer.
Different teams get by with different amounts of Scrum Processes.
Less experienced ones need the full-on shit with backlog grooming, planning poker, dailies and retrospectives.
When the team gets better (and there isn't much turnover), you can relax the Processes.
I'm pretty sure I might be the only one on HN who has Scrum actually work in real life. (I've had my share of shitty-Scrum too, like 45 minute "dailies"... =)
Different teams get by with different amounts of Scrum Processes.
Less experienced ones need the full-on shit with backlog grooming, planning poker, dailies and retrospectives.
When the team gets better (and there isn't much turnover), you can relax the Processes.
I'm pretty sure I might be the only one on HN who has Scrum actually work in real life. (I've had my share of shitty-Scrum too, like 45 minute "dailies"... =)
To read without logging in to Xitter:
https://nitter.net/svpino/status/1695806027256475777
I know for a fact engineers on my team that called me crazy for thinking scrum is snake oil sold to management will upvote this.
Sounds like the guy is very happy to have whipped up a shitstorm because it Drives Engagement.
I feel very sorry for Santiago.
His pain seems to be real, even if it is not even connected with scrum.
What makes it really sad: all of this can be fixed very easy - the company "just" need to hire somebody who is able to address the underlaying root cause of this anti-pattern.
1) "1. They tried to convince me that Poker is a planning tool, not a game." Planing poker has nothing to do with scrum. It is an estimation technique. Just do "no estimation" and if it works for the team, everything is fine. Also it is a planning tool - if you didn´t understand how it works, maybe a quick google search could be helpful.
2) Scrum does not have "ceremonies". They are called "events" and can be extremely efficient - so if you spend more times in those meetings than actually working, something is very very wrong. Maybe get some outside help, have a retrospective that is done properly and understand the root cause?
2) "Scrum of Scrums" is not part of scrum - this is some scaled approach. Based on what he described it is most likely the anti-agile SAFe frankenstein of frameworks.
3) "We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention." -> WEIRD. People should pay attention to the actual meeting? Also none of this is part of scrum.
4) "We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint." -> this is not scrum. This is whatever the team came up with.
5) "I had to use t-shirt sizes to estimate software." -> this is not scrum. It is estimation techniques.
6+7 "story points" are not a part of scrum. Agile contracts are a common practices however, but contracts based on story points are weird, because story points are a relative measurement that cannot be compared (same as velocity)
8. "Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously." - Scrum does not have the role of "manager" or "tech lead". So obviously you are not doing scrum.
His pain seems to be real, even if it is not even connected with scrum.
What makes it really sad: all of this can be fixed very easy - the company "just" need to hire somebody who is able to address the underlaying root cause of this anti-pattern.
1) "1. They tried to convince me that Poker is a planning tool, not a game." Planing poker has nothing to do with scrum. It is an estimation technique. Just do "no estimation" and if it works for the team, everything is fine. Also it is a planning tool - if you didn´t understand how it works, maybe a quick google search could be helpful.
2) Scrum does not have "ceremonies". They are called "events" and can be extremely efficient - so if you spend more times in those meetings than actually working, something is very very wrong. Maybe get some outside help, have a retrospective that is done properly and understand the root cause?
2) "Scrum of Scrums" is not part of scrum - this is some scaled approach. Based on what he described it is most likely the anti-agile SAFe frankenstein of frameworks.
3) "We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention." -> WEIRD. People should pay attention to the actual meeting? Also none of this is part of scrum.
4) "We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint." -> this is not scrum. This is whatever the team came up with.
5) "I had to use t-shirt sizes to estimate software." -> this is not scrum. It is estimation techniques.
6+7 "story points" are not a part of scrum. Agile contracts are a common practices however, but contracts based on story points are weird, because story points are a relative measurement that cannot be compared (same as velocity)
8. "Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously." - Scrum does not have the role of "manager" or "tech lead". So obviously you are not doing scrum.
Scrum and agile always fails if your company has a finance department. The finance department is never agile an will demand numbers every quarter. They don't care about your sprints. They want a plan for the next quarter and don't care about your sprints or your t-shirt estimates of your Kanban backlog. Unfortunately since they have the money the needs of the finance departments always win over all agile processes you have in place.
No agile book or manifesto ever mentions this issue, because there simply is no solution for it.
No agile book or manifesto ever mentions this issue, because there simply is no solution for it.
Yep, if the CFO has this kind of power the R&D pipeline is essentially being run by an accountant.
Remember when wall street was complaining about how Bezos was running the company? If an accountant was in charge Amazon would have been quarter packing to please wall street, and would be much smaller/out of business.
Remember when wall street was complaining about how Bezos was running the company? If an accountant was in charge Amazon would have been quarter packing to please wall street, and would be much smaller/out of business.
I think Scrum is a transitional phase. It is a solution to the problem of having a dev team shared between multiple business functions.
The dev team keeps getting yanked around and interrupted. So every two weeks you get all the business people in a room and you have them make a list of things that the dev team will work on this cycle. Then the dev team can execute in peace. The Scrum Master's job is to protect the dev team. The Product Owner's job is to get the business people to converge on the prioritized list of work.
In a healthy organization, Scrum is much less useful. Scrum combines three different cycles: defining work, executing work, and reviewing work. In a flow-based process like Kanban, you can split them up.
The product manager builds a prioritized backlog of work, and the dev team estimates tasks to help do business ROI calculations. It's a collaboration between product and development.
The dev team implements tasks from the backlog one by one. You can batch up work to make a release, deliver incrementally, or use tools like feature flags. You evaluate whether features are effective working based on metrics.
The dev team keeps getting yanked around and interrupted. So every two weeks you get all the business people in a room and you have them make a list of things that the dev team will work on this cycle. Then the dev team can execute in peace. The Scrum Master's job is to protect the dev team. The Product Owner's job is to get the business people to converge on the prioritized list of work.
In a healthy organization, Scrum is much less useful. Scrum combines three different cycles: defining work, executing work, and reviewing work. In a flow-based process like Kanban, you can split them up.
The product manager builds a prioritized backlog of work, and the dev team estimates tasks to help do business ROI calculations. It's a collaboration between product and development.
The dev team implements tasks from the backlog one by one. You can batch up work to make a release, deliver incrementally, or use tools like feature flags. You evaluate whether features are effective working based on metrics.
Scrum got popular but it doesn't fit in with most companies imperatives so the management modify or purposely fail to understand it or don't train anyone.
It's really about teams adjusting themselves to whatever behaviour and process works for them and managers hate not having control. So it's inevitable that any method which gets adopted in name at shitty companies will be "enshittified".
The good thing about Scrum is that it introduces frequent moments of accountability. They are not popular but much needed in many teams and better than the alternative of the traditional waterfall approach.
It should also very frequently reveal issues. In misunderstandings, planning, underestimation, dependencies. This is a good thing as you can then course-correct early.
That said, it is soul crushing. Some jobs/tasks just don't fit into SCRUM yet one is forced to adhere to it anyway. There's way too many meetings. The boundaries of roles are not respected. Quality is not rewarded, only story point delivery. There's typically no feedback loop from users/the market as to whether actual value was delivered because you're working on the next sprint. Product owners are not actual owners. Scrum masters act as project management.
A typical scrum team easily costs 1M to run even here in Europe. And yet they produce so little. If you'd hire 3 A-class players in a high trust environment they'd produce 10 times more at superior quality.
True comedy is found in "scaled agile". This is where the SCRUM elite of the company get the teams together and ask: tell me for the next 6 months which stories you will deliver and figure out all the dependencies.
Mind you, near-zero input is given. You might as well roll a dice. And still we're all here to pretend that this insanity is normal. I no longer fight it.
I actually feel bad for business owners. They're setting on fire some 50-70% of their hard-earned revenue on talking and book keeping.
It should also very frequently reveal issues. In misunderstandings, planning, underestimation, dependencies. This is a good thing as you can then course-correct early.
That said, it is soul crushing. Some jobs/tasks just don't fit into SCRUM yet one is forced to adhere to it anyway. There's way too many meetings. The boundaries of roles are not respected. Quality is not rewarded, only story point delivery. There's typically no feedback loop from users/the market as to whether actual value was delivered because you're working on the next sprint. Product owners are not actual owners. Scrum masters act as project management.
A typical scrum team easily costs 1M to run even here in Europe. And yet they produce so little. If you'd hire 3 A-class players in a high trust environment they'd produce 10 times more at superior quality.
True comedy is found in "scaled agile". This is where the SCRUM elite of the company get the teams together and ask: tell me for the next 6 months which stories you will deliver and figure out all the dependencies.
Mind you, near-zero input is given. You might as well roll a dice. And still we're all here to pretend that this insanity is normal. I no longer fight it.
I actually feel bad for business owners. They're setting on fire some 50-70% of their hard-earned revenue on talking and book keeping.
I don’t mind scrum, specifically the daily stand up. In an old job a couple non-contributors became obvious. And so has been my work ethic. I benefit from that because I’m naturally the kind of person to get things done. Despite my good feelings about it, I also see how often it’s used as a) an excuse to micromanage and b) a mechanism to feed leadership’s need for attention. I don’t know if this is accurate or not, but I’m inclined to think people that get into managerial positions are more social and that seems to come with an intrinsic need to be seen, recognized, and given some form of public accolades (like everyone laughing at thier funny jokes). And while I like the accountability of stand ups, you’re going to get my PRs anyway and your agile tickets/cards are getting moved to done whether I’m in a meeting or not. I think overall it’s a bit of a waste of time for me. That’s just my personal opinion though. Maybe I’m wrong, feel free to give feedback. I’m open to being convinced otherwise.
> I think overall it’s a bit of a waste of time for me
The company isn't trying to optimize for best use of your time individually or to make you happy. They are trying to get some kind of result. And it very well may be worth inconveniencing and annoying higher performers to improve the performance of lower performers to achieve the result they want.
The company isn't trying to optimize for best use of your time individually or to make you happy. They are trying to get some kind of result. And it very well may be worth inconveniencing and annoying higher performers to improve the performance of lower performers to achieve the result they want.
Huh, hadn’t thought of that. Thank you.
> but I’m inclined to think people that get into managerial positions are more social and that seems to come with an intrinsic need to be seen, recognized, and given some form of public accolades
I got into management because I like solving problems and I reached a point where solving purely technical problems is no longer what it takes to actually drive a product forward and improve things. The problems I try to solve now are more organizational so that dev teams can actually reach that creative state where they are talking with the customer directly and engaged in the overall process. I'm an introvert. The face time and accolades are draining, but it's important work that you've got to be in a leadership position to take on effectively.
I got into management because I like solving problems and I reached a point where solving purely technical problems is no longer what it takes to actually drive a product forward and improve things. The problems I try to solve now are more organizational so that dev teams can actually reach that creative state where they are talking with the customer directly and engaged in the overall process. I'm an introvert. The face time and accolades are draining, but it's important work that you've got to be in a leadership position to take on effectively.
> In an old job a couple non-contributors became obvious.
So your management wasn't doing their job? They're supposed to know who's working and who isn't regardless of what rituals are practiced.
So your management wasn't doing their job? They're supposed to know who's working and who isn't regardless of what rituals are practiced.
That’s exactly right! I’ve had that same exact thought. Had they been making any kind of effort to “manage” that would’ve been dealt with much sooner. We didn’t necessarily need daily stand ups, but they ended up being the mechanism management used to figure out who was not performing. I have often wondered if a simple cursory check in would’ve accomplished the same thing. All the meeting and processional hand waving might’ve been unnecessary.
Or they did their job by implementing scrum?
If he was force to use Scrum, they were GOD DAMM NOT DOING THEIR JOB!
Assume you need to build a chair. You barely have seen a chair in you life. You would naturally start naively with a first approach. That will fail to carry a person at first. But as your approach advances you’ll gain experience and eventually you will build the chair after some while.
That is my understanding of what people name scrum or agile. A management harness with fancy words. The real benefit is when you let people do their work, gain experience and make them self organize their problems.
That is my understanding of what people name scrum or agile. A management harness with fancy words. The real benefit is when you let people do their work, gain experience and make them self organize their problems.
Some developers are a cancer too of course - want to do things they way they choose, taking the time they choose. A lot don't want to lose their specialisation or ownership of some portion of the code.
You get the senior devs who have been a law unto themselves for years and they certainly don't like anything that distributes power across the team. It might mean they have to do work they don't like sometimes.
From the start they're out to sink the whole scheme and even one of those in a team makes it very difficult to achieve any change.
That's just ontop of the fact that middle management don't like a method that removes their ability to interfere with the details or put pressure on individuals.
And of course in the end there are those developers who expect to do nothing but write beautiful lines of code all day long and consider every other part of delivering software to be beneath them - reviewing other people's code, writing tests, working on requirements, maintaining old code.
You get the senior devs who have been a law unto themselves for years and they certainly don't like anything that distributes power across the team. It might mean they have to do work they don't like sometimes.
From the start they're out to sink the whole scheme and even one of those in a team makes it very difficult to achieve any change.
That's just ontop of the fact that middle management don't like a method that removes their ability to interfere with the details or put pressure on individuals.
And of course in the end there are those developers who expect to do nothing but write beautiful lines of code all day long and consider every other part of delivering software to be beneath them - reviewing other people's code, writing tests, working on requirements, maintaining old code.
I think the deeper reality is that people just suck at working together. There is always gonna be friction when a group of individuals try to achieve something together (time lines, slackers, miscommunication). We blame it on method X when at the end of the day its human nature and no magical method of working can completely remediate that.
The worst part of Scrum/Agile is that you formalize everything. Reducing technical debt, improving CI/CD, research and innovation sprints..
Oh, you fixed a typo? Where's the ticket for that?
Until, of course, the things you want to improve are never in the sprint and you have no free day to tackle anything you want (and the project needs), ever.
Bonus points for using Product Increments and abusing the Innovation and Planning Sprint as buffer that always gets used.
Until, of course, the things you want to improve are never in the sprint and you have no free day to tackle anything you want (and the project needs), ever.
Bonus points for using Product Increments and abusing the Innovation and Planning Sprint as buffer that always gets used.
I went on a road trip with my coworker last week. We were together and he had to attend to a retrospective meeting that was planned to last for 2 hours or so. The stand-in scrum master (their original SM was on vacation so someone stood in) said this would be an unusual retro because they had done 6 or 7 sprints and never did a retro on each of them.
I am in another section and we have retro meetings but they take 1 hour or less. Anyways, what caught my attention was two very stupid things introduced by their scrum master:
- estimating story points for completed tasks: they went over each ticket that was marked as done and asked how many days it took to complete the task. Me and the others on the car couldn't believe what we were listening to.
- making JIRA tickets for useless things like "how to install software X". We have a guide on Confluence with instructions on how to install said software and if you follow the guide from start to finish you can get it working and it shouldn't take more than 20 minutes. If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help.
This is not what happened in my colleague's team. They had to create a JIRA ticket to track individual progress on installing the tool. I talked to this other colleague that created the guide and he said he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people that apparently can't read a step-by-step guide on their computer. And then later they had to mark a JIRA ticket as completed.
This is very stupid and when I see this colleague of mine suffering with someone that is evangelizing SCRUM as any other meme scrum master out there just makes me hate it even more.
I am in another section and we have retro meetings but they take 1 hour or less. Anyways, what caught my attention was two very stupid things introduced by their scrum master:
- estimating story points for completed tasks: they went over each ticket that was marked as done and asked how many days it took to complete the task. Me and the others on the car couldn't believe what we were listening to.
- making JIRA tickets for useless things like "how to install software X". We have a guide on Confluence with instructions on how to install said software and if you follow the guide from start to finish you can get it working and it shouldn't take more than 20 minutes. If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help.
This is not what happened in my colleague's team. They had to create a JIRA ticket to track individual progress on installing the tool. I talked to this other colleague that created the guide and he said he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people that apparently can't read a step-by-step guide on their computer. And then later they had to mark a JIRA ticket as completed.
This is very stupid and when I see this colleague of mine suffering with someone that is evangelizing SCRUM as any other meme scrum master out there just makes me hate it even more.
I'm not sure whats wrong with second point.
Even with super-b detail guide you sometime get troubles/issues/errors that you unable to fix without outside help.
> If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help.
> he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people
Irony? Irony..
> If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help.
> he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people
Irony? Irony..
My company bought into the SAFe bullsh*t and it’s awful.
I look at the typical SAFe framework and laugh. https://scaledagileframework.com/wp-content/uploads/2023/03/...
SAFe is the next buzz word laden cancer to infect the enterprise. It will bring Business Agility(tm) to areas of the business beyond software development.
Consultants love it!
SAFe is the next buzz word laden cancer to infect the enterprise. It will bring Business Agility(tm) to areas of the business beyond software development.
Consultants love it!
Why would you hate spending 1 month out of 4 for “planning” and then 40% of the time in the remaining 3 months also for “planning” resulting in a massive destruction of productivity all so you can now claim that “yeah, you delivered a fraction of what the company was delivering pre SAFE, but at least we planned on delivering a fraction of what we delivered Pre-SAFE.”
Anecdote: When Intel's stock kept falling early this year they had to quit SAFE to speed up development... a bird said.
So you are saying that their development became... unSAFE?
Is there an alternative anyone would recommend.
It might not be the best question to ask given the complexity of the software and experience/culture of the team.
It might not be the best question to ask given the complexity of the software and experience/culture of the team.
It is a good question but the answer may be unsatisfactory: it depends. I think that the popularity of scrum is due to its catch-all nature and the way it sounds reasonable when you explain it to someone, especially a non-developer.
Here is an answer that (I believe) works well: Hire a team lead that is willing to shield a small dev team (less than about 7 people) from the politics above. The devs still talk to users and other people in the company but they do not necessarily have to be accountable to them. The team lead understands the company’s budget cycles, has a vision for the product being developed and, importantly, has the time to sit down with each developer on the team to look at what they are making. Not a code review but a regular show-and-tell kind of arrangement. The fine line in this approach is to make sure it doesn’t degrade to micromanagement and ego poking.
Here is an answer that (I believe) works well: Hire a team lead that is willing to shield a small dev team (less than about 7 people) from the politics above. The devs still talk to users and other people in the company but they do not necessarily have to be accountable to them. The team lead understands the company’s budget cycles, has a vision for the product being developed and, importantly, has the time to sit down with each developer on the team to look at what they are making. Not a code review but a regular show-and-tell kind of arrangement. The fine line in this approach is to make sure it doesn’t degrade to micromanagement and ego poking.
Agreed, diving into the "depends" is critical.
Sometimes a lot can be understood from the team and it's current process in terms of where it did, or didn't come from.
Having a team lead that is technical as a product manager can be very helpful as you are outlining. Being able to speak the language of and maintain the respect of both is so valuable in terms of "getting it".
Clearing the way for devs to learn and do with customers and each other is the other key thing I think about a lot.
Startups likely have less politics (hopefully) but the longer they operate as startups politics likely increase, or hides itself better.
When I see startups leaping to hire VP engineering, etc, I can't help but think of my own experiences where having the founders at those seats translating what is being learned from customers directly into the product was so critical.
For existing or larger organizations, I think what you're saying is very true.
Sometimes a lot can be understood from the team and it's current process in terms of where it did, or didn't come from.
Having a team lead that is technical as a product manager can be very helpful as you are outlining. Being able to speak the language of and maintain the respect of both is so valuable in terms of "getting it".
Clearing the way for devs to learn and do with customers and each other is the other key thing I think about a lot.
Startups likely have less politics (hopefully) but the longer they operate as startups politics likely increase, or hides itself better.
When I see startups leaping to hire VP engineering, etc, I can't help but think of my own experiences where having the founders at those seats translating what is being learned from customers directly into the product was so critical.
For existing or larger organizations, I think what you're saying is very true.
This is a very unsatisfactory answer - but you have to grow a culture. Working with people to match their personal goals with organizational goals. High degree of mutual trust. Cooperative design. Group ownership of the codebase and rotating responsibilities. Lack of 'magic knowledge'. Sufficient infrastructure development to reduce rote workload on developers.
All of these are organic rather than formulaic. They require limited rates of growth to enculturate the new hires, and a seed group that understands this.
That works. But you can't hire a consultant to build that, or write a book about it. And bad elements in the mix can mess up the whole thing.
All of these are organic rather than formulaic. They require limited rates of growth to enculturate the new hires, and a seed group that understands this.
That works. But you can't hire a consultant to build that, or write a book about it. And bad elements in the mix can mess up the whole thing.
No, you're totally right though - culture is everything, and the experience of being a part of a team how it works is everything.
I heard an interesting explanation the other day, hard skills are easy to measure, and soft skills are hard to measure, but developing soft skills can be are more important than hard skills.
I heard an interesting explanation the other day, hard skills are easy to measure, and soft skills are hard to measure, but developing soft skills can be are more important than hard skills.
We do a very loose agile process and everyone seems to like it. Basically, we have a standup every morning. Each team member has up to 1 minute to list (in very brief form) what they did yesterday and what they plan to do today.
It identifies if anyone will be stepping on anyone else's toes, or if anyone knows of something similar and can point you to it, and it lets the project manager know if anyone is working on something that can be traded for a higher priority task that just came up.
Most of the time, you work on what you say you're going to work on. Sometimes, the project manager will call you after standup to get more detail and/or adjust your priority to a different task.
This standup is the only formal meeting the developers go to, other than the odd department/company wide meeting. The project manager goes to all of the other meetings.
We are the most productive team in the company. I think the autonomy and the lack of formal meetings are the real magic. We're fully remote and talk to each other plenty throughout the day in an adhoc way, sometimes for fun and sometimes for technical discussions, problem solving, brainstorming, sanity checks (technical and personal), etc.
It identifies if anyone will be stepping on anyone else's toes, or if anyone knows of something similar and can point you to it, and it lets the project manager know if anyone is working on something that can be traded for a higher priority task that just came up.
Most of the time, you work on what you say you're going to work on. Sometimes, the project manager will call you after standup to get more detail and/or adjust your priority to a different task.
This standup is the only formal meeting the developers go to, other than the odd department/company wide meeting. The project manager goes to all of the other meetings.
We are the most productive team in the company. I think the autonomy and the lack of formal meetings are the real magic. We're fully remote and talk to each other plenty throughout the day in an adhoc way, sometimes for fun and sometimes for technical discussions, problem solving, brainstorming, sanity checks (technical and personal), etc.
Nice, though part of me wonders: if using version control why bother reading off yesterday's commits? Rest is pretty good and accurate imo.
"what they did yesterday and what they plan to do today" is not something you can read off people's commits
"I was figuring out how to add a doohickey that widgets foobar" is not a commit, but during the daily someone else might remember that there already is something that can widget foobars. Or they might know that widgeting foobars was tried before and it failed because X and Y.
Then they won't start debugging that during the daily, but will point it out and get in touch afterwards along with others that might care. Either on a $TEXTUAL_MESSAGING_APP thread or $VIDEO_CALL_SERVICE call.
"I was figuring out how to add a doohickey that widgets foobar" is not a commit, but during the daily someone else might remember that there already is something that can widget foobars. Or they might know that widgeting foobars was tried before and it failed because X and Y.
Then they won't start debugging that during the daily, but will point it out and get in touch afterwards along with others that might care. Either on a $TEXTUAL_MESSAGING_APP thread or $VIDEO_CALL_SERVICE call.
ACK
A standup every morning?
To my experience 10% of software developers think 7 am is morning, 60% something between 9 and 10. 30% not before 11 or 12. The first and the last group tend to be the most productive ones.
Forcing all of them to meet at 10 or even 9 is the best way to kill motivation and foster cynicism about useless meetings and processes.
To my experience 10% of software developers think 7 am is morning, 60% something between 9 and 10. 30% not before 11 or 12. The first and the last group tend to be the most productive ones.
Forcing all of them to meet at 10 or even 9 is the best way to kill motivation and foster cynicism about useless meetings and processes.
Each person is limited to 1 minute, and most people only use about 10-20 seconds. So, the meetings are usually done in less time than it takes to go to the bathroom. I think everyone sees the value in calibrating our trajectory for a few minutes every day -- it often saves more time than it consumes.
There is no best approach, but this article highlights some common aspects from a survey of 100+ tech companies’ approaches to project management:
“How Big Tech Runs Tech Projects and the Curious Absence of Scrum”
https://blog.pragmaticengineer.com/project-management-at-big...
“How Big Tech Runs Tech Projects and the Curious Absence of Scrum”
https://blog.pragmaticengineer.com/project-management-at-big...
Thanks so much for the link.
My own experience has been similar.
Start with keeping a very flexible core and codebase.. feed it with launched code from a plan that balances bug fixes, progress forward, and customer needs from the business.
This meant having a backlog, and by scoring each item on criticality where 1 was critical and 6 was someday/maybe, and whether it was internal facing, or external facing (customer is aware), you could almost start selecting what was done and ready.
Would love to hear anyone's processes they used that have worked well for them from start to growth.
My own experience has been similar.
Start with keeping a very flexible core and codebase.. feed it with launched code from a plan that balances bug fixes, progress forward, and customer needs from the business.
This meant having a backlog, and by scoring each item on criticality where 1 was critical and 6 was someday/maybe, and whether it was internal facing, or external facing (customer is aware), you could almost start selecting what was done and ready.
Would love to hear anyone's processes they used that have worked well for them from start to growth.
Personally, I think SAFE or Agile/Scrum are good starting points.
The key part, however, is teams, departments, and companies, then modifying their actual working by eliminating ceremony and process.
The way I think Agile/Scrum/SAFE should work is that you expose all the teams to all the ceremonies, and all the different alternatives to each of the ceremonies to start with, but you also mandate thst 6 months to a year from now you should have reduced 50% of the ceremonies you started with.
The goal should be expose people the universe of options and ideas available, and then once exposed, require them to pick and choose between all these options to tailor their own customized solution which works best with the people on their team and the working styles and the kind of work they’re doing.
The key part, however, is teams, departments, and companies, then modifying their actual working by eliminating ceremony and process.
The way I think Agile/Scrum/SAFE should work is that you expose all the teams to all the ceremonies, and all the different alternatives to each of the ceremonies to start with, but you also mandate thst 6 months to a year from now you should have reduced 50% of the ceremonies you started with.
The goal should be expose people the universe of options and ideas available, and then once exposed, require them to pick and choose between all these options to tailor their own customized solution which works best with the people on their team and the working styles and the kind of work they’re doing.
I heard an interesting perspective for startups - Kanban/Scrum is useful sometimes before launch, and not using scrum after is beneficial.
Mostly because launching changes so much.
Part of me does feel sometimes that ceremonies are for making sure the development practice is highly inclusive, including for new and less skilled developers still learning their ways. Another part of me thinks about how this also helps more people to be able to generally help with more of the codebase.
I think writing code for your future self or someone else, in a way you'd like to receive is critical to think about. This can include doing things the simpler way even if it's more verbose and more understandable. This isn't always possible, but more often than not, avoidable complexity also can encourage the engagement of a lot of ceremony around it. "Could this have been simpler?" is one useful question for code reviews.
Mostly because launching changes so much.
Part of me does feel sometimes that ceremonies are for making sure the development practice is highly inclusive, including for new and less skilled developers still learning their ways. Another part of me thinks about how this also helps more people to be able to generally help with more of the codebase.
I think writing code for your future self or someone else, in a way you'd like to receive is critical to think about. This can include doing things the simpler way even if it's more verbose and more understandable. This isn't always possible, but more often than not, avoidable complexity also can encourage the engagement of a lot of ceremony around it. "Could this have been simpler?" is one useful question for code reviews.
I developed an alternative called “Hot-Potato Agile” while at Google. I got buy-in to try it, but then was laid off in January just before we could start. So if you have a team that likes sprint cadence but hates the scrum busywork and is open to an experiment, let me know! I still want to flesh out this thing’s rough edges.
> We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
The ball feels a little gimmicky but otherwise in general I am in favor. The whole point of no laptops / standing / forced attention is to actually cut down on the meeting time by encouraging people to be present. When people can tune out and multitask, you get wasted meetings. If people are paying attention, they'll call out time wasting.
> I had to use t-shirt sizes to estimate software.
Why is this a problem?
> We spent more time estimating story points than writing software
This I just really don't believe. Perhaps it was meant in jest / hyperbole and does not actually represent a true accounting of time. If actually true, this is not a problem with scrum, but with your organization. Just because a process is misused doesn't mean the whole thing is useless.
> scrum is not for developers
Probably the biggest thing I definitely agree with. You know what else isn't "for developers?" The existence of the business itself.
The ball feels a little gimmicky but otherwise in general I am in favor. The whole point of no laptops / standing / forced attention is to actually cut down on the meeting time by encouraging people to be present. When people can tune out and multitask, you get wasted meetings. If people are paying attention, they'll call out time wasting.
> I had to use t-shirt sizes to estimate software.
Why is this a problem?
> We spent more time estimating story points than writing software
This I just really don't believe. Perhaps it was meant in jest / hyperbole and does not actually represent a true accounting of time. If actually true, this is not a problem with scrum, but with your organization. Just because a process is misused doesn't mean the whole thing is useless.
> scrum is not for developers
Probably the biggest thing I definitely agree with. You know what else isn't "for developers?" The existence of the business itself.
[deleted]
If an engineering organization is doing the equivalent of laying on the floor and kicking and screaming that they can't do anything, where signs of this include:
* Split up into multiple teams under different kingdom building directors/VPs
* More time is spent defending Jira SLAs and deflecting blame than actually solving problems
* Dev teams under different managers have an adversarial relationship
If the above is true, just adding a standup for a given initiative that includes all of the team members and just normal human behavior of exposure builds a little trust and collaboration is a miracle pill!
Albeit it's a 'miracle' pill that takes the org from laying on the ground kicking and screaming to slowly making code changes that no customer wants - but comparatively it looks like a miracle to legacy management!
The real solution is to fire 3/4 of the management staff and take the next 3 years to rebuild an effective organization. <-- however, this doesn't sell like a SCRUM Miracle Pill™
* Split up into multiple teams under different kingdom building directors/VPs
* More time is spent defending Jira SLAs and deflecting blame than actually solving problems
* Dev teams under different managers have an adversarial relationship
If the above is true, just adding a standup for a given initiative that includes all of the team members and just normal human behavior of exposure builds a little trust and collaboration is a miracle pill!
Albeit it's a 'miracle' pill that takes the org from laying on the ground kicking and screaming to slowly making code changes that no customer wants - but comparatively it looks like a miracle to legacy management!
The real solution is to fire 3/4 of the management staff and take the next 3 years to rebuild an effective organization. <-- however, this doesn't sell like a SCRUM Miracle Pill™
I've personally never been in a project where I've felt that the team was doing well thanks to scrum but in spite of it.
I think rapid iteration + kanban style documentation is indispensable towards good productivity for most dev teams. I think having quick dev cycles + good documentation benefits everyone: devs, managers, and the accounting team too. Where I think Scrum goes wrong is that turns documentation+rapid iteration into a cudgel to use against devs and pressure them.
"Why didn't you finish this story? You committed to us you'd finish in two weeks!!" Perhaps well documented rapid iteration processes naturally tends towards dev mistreatment, but I genuinely hope not.
My dream world is where devs can aim high, fail, and try again as many times as is needed without being judged/penalized.
"Why didn't you finish this story? You committed to us you'd finish in two weeks!!" Perhaps well documented rapid iteration processes naturally tends towards dev mistreatment, but I genuinely hope not.
My dream world is where devs can aim high, fail, and try again as many times as is needed without being judged/penalized.
Two employees of a company were suddenly approached by the CEO accompanied by the CTO.
- Death or Scrum? - asked the CEO
The employees knew nothing about this Scrum thing, but were to intimidated to ask and the other choice was one they were not ready to make.
The first one thus replied in a quavering voice: "Scrum"
In this moment the first employee was grabbed by the CTO and was put through horrors not many could withstand:
- Neverending sprint planning meetings
- Daily Scrums that lasted 4 hours
- The sprint reviews
- Sprint retrospectives
- The backlog refinements
After all this the employee was only able to say: "Still working on User Story XYZ. No impediments."
The CEO then asked the second employee what their answer was. The employee was fighting a tough fight in their head.
"I hate meetings, I would love to do some real work, but I'm not ready to die yet. On the other hand, I can't go through life after all that abuse; There's no way I could live with myself". So he answered: DEATH!
To this the CEO swiftly replied: Death ... by Scrum
- Death or Scrum? - asked the CEO
The employees knew nothing about this Scrum thing, but were to intimidated to ask and the other choice was one they were not ready to make.
The first one thus replied in a quavering voice: "Scrum"
In this moment the first employee was grabbed by the CTO and was put through horrors not many could withstand:
- Neverending sprint planning meetings
- Daily Scrums that lasted 4 hours
- The sprint reviews
- Sprint retrospectives
- The backlog refinements
After all this the employee was only able to say: "Still working on User Story XYZ. No impediments."
The CEO then asked the second employee what their answer was. The employee was fighting a tough fight in their head.
"I hate meetings, I would love to do some real work, but I'm not ready to die yet. On the other hand, I can't go through life after all that abuse; There's no way I could live with myself". So he answered: DEATH!
To this the CEO swiftly replied: Death ... by Scrum
Personally, I've experienced scrum only as a tool used by middle managers to control developers. It sounds good in theory, but power structures are a thing, and it gives too much influence in the way of metrics to malicious managing types who want to be in control. Scrum and agile are now red flags for me.
The level of scrum-apologism here is I suppose both unsurprising but also egregiously sad.
Scrum is garbage. Most software development methodology is garbage. And even if there are theoretically-good ones that are "only" garbage because people "implement them the wrong way", that too is the methodology's fault. If something is so hard to implement that most people get it wrong, with disastrous results, then that thing is indeed garbage, regardless of its merits when "done right".
We apply this principle to technical process: if someone manages to delete the production database, it's probably not that person's fault, but the fault of the processes around access controls and incident response. If everyone implements scrum catastrophically wrong, that's scrum's fault.
Scrum is garbage. Most software development methodology is garbage. And even if there are theoretically-good ones that are "only" garbage because people "implement them the wrong way", that too is the methodology's fault. If something is so hard to implement that most people get it wrong, with disastrous results, then that thing is indeed garbage, regardless of its merits when "done right".
We apply this principle to technical process: if someone manages to delete the production database, it's probably not that person's fault, but the fault of the processes around access controls and incident response. If everyone implements scrum catastrophically wrong, that's scrum's fault.
Agreed, however;
> We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
I think the no-laptop thing is good, and unsurprisingly, it has nothing to do with Scrum.
> Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.
Out of all the bullshit that makes up Scrum and (what has become) "Agile", this is the one that clogs the toilet. I can imagine a world where this idea of "complexity, not time" is done properly, but it's not this one.
Srumm is Agile™. Real Agile means working in incredibly fast feedback loops, to the point where you can't tell it's part of a process, because it's all working so fluidly. Trying to put that into a series of rigid set meetings is the antithesis of that.
> We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
I think the no-laptop thing is good, and unsurprisingly, it has nothing to do with Scrum.
> Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.
Out of all the bullshit that makes up Scrum and (what has become) "Agile", this is the one that clogs the toilet. I can imagine a world where this idea of "complexity, not time" is done properly, but it's not this one.
Srumm is Agile™. Real Agile means working in incredibly fast feedback loops, to the point where you can't tell it's part of a process, because it's all working so fluidly. Trying to put that into a series of rigid set meetings is the antithesis of that.
Some of this is due to Scrum but other parts of it would still exist in these companies even if they changed to Kanban. I think the problem is the kinds of companies that have these processes can't find an alternative. The companies I've worked at where it was like this were all sales-driven enterprise software where deadlines are the focus and being able to tell a customer it'll be there in X months was viewed as critical. So they put all of these processes in place to make sure they can consistently hit deadlines even if it means slowing everything down to a halt. It still doesn't work that well but just removing the process isn't going to work without changing how the rest of the company operates too.
I haven't done a ton of Scrum in my career, but my observation of it, in concept at least, is that it's supposed to be sort of like training wheels for agile, which seems innocuous enough. What I have found particularly horrifying about some orgs adopting it is that the agile part (the part that's trickier to execute) gets thrown out the window in favor of what is basically waterfall with sprints, and then people eat it up like there's nothing profoundly wrong with the picture. Something like that is definitely a cancer.
That is reality. Agile made a straw man out of waterfall. In reality, no one practiced waterfall the way the Agile Manifesto claimed that it did. In reality scrum is waterfall with a new name. There I said it. Now I will face the agile inquisition.
"Your software should be agile, not your process. Your process should be "disturb as little as possible". Either you code or you get out of the way and take responsibility for the people that code by slowing them down just enough to trust them."
Scrum fails when it is formalized and run Cargo-Cult style. "We must do all of these steps as in The Book." If you understand the reasons for the steps, and instead incorporate the function in the day-to-day activities, values, and norms of the team you get the benefits with very few drawbacks. But yes, you're no longer a "true Scotsman" doing "real Scrum."
Consultants suck the meat off the bones and resell the skeleton, then management wonders why the specimen doesn't appear to be the genuine animal.
Consultants suck the meat off the bones and resell the skeleton, then management wonders why the specimen doesn't appear to be the genuine animal.
Scrum is a descent way to get a relatively immature team to get work done. There are other more effective ways to get work done if you have an experienced and mature team.
This article from 2021 illustrates the different ways of running projects and the tradeoffs that are involved:
How Big Tech Runs Tech Projects and the Curious Absence of Scrum
https://newsletter.pragmaticengineer.com/p/project-managemen...
This article from 2021 illustrates the different ways of running projects and the tradeoffs that are involved:
How Big Tech Runs Tech Projects and the Curious Absence of Scrum
https://newsletter.pragmaticengineer.com/p/project-managemen...
Agile was introduced as a less-rigid and more efficient alternative to waterfall-like processes that were widely used in the 90s.
The new methodology was quickly pre-empted by middle managers as a new power tool, Scrum mostly replaced Agile because of all the weird cargo-cult rituals and sexy names.
My experience with it has been widely negative. People staring at the void during "standups", bullshit amplification, ticket misuse and misread by management.
Never seen any improvement from it, only overhead and demotivation.
The new methodology was quickly pre-empted by middle managers as a new power tool, Scrum mostly replaced Agile because of all the weird cargo-cult rituals and sexy names.
My experience with it has been widely negative. People staring at the void during "standups", bullshit amplification, ticket misuse and misread by management.
Never seen any improvement from it, only overhead and demotivation.
Clever management technique in a shop full of blunt knives will only get you so far.
With my team, we’ve focussed on developing talent just as much as we have on getting the work done. By improving skills through senior-to-junior coaching and code review we’ve built a much more cohesive team that’s better at what they do and can complete tasks which they couldn’t do before. Dexterity and fluency with code was more important to us than organisational skills.
Perhaps I’m missing the point and Scrum is only for people at the top of their game? It didn’t feel that way the few times I’ve seen it — to be a little bitchy, it appeared to be quite the opposite.
With my team, we’ve focussed on developing talent just as much as we have on getting the work done. By improving skills through senior-to-junior coaching and code review we’ve built a much more cohesive team that’s better at what they do and can complete tasks which they couldn’t do before. Dexterity and fluency with code was more important to us than organisational skills.
Perhaps I’m missing the point and Scrum is only for people at the top of their game? It didn’t feel that way the few times I’ve seen it — to be a little bitchy, it appeared to be quite the opposite.
I don't have a lot of strong feelings about 'process' stuff, but boy do I loathe self-important sounding talk like "ceremonies". I was explaining some work stuff to my mom, who knows BS when she hears it and I could practically hear her eyes rolling over the phone when I mentioned how they had started calling things "ceremonies" at work.
Things like weddings, graduations and funerals are important moments in life that cultures all over the world honor with ceremonies of some kind. Your quick morning meeting to discuss what you're working on isn't a @#(#(#( "ceremony".
Things like weddings, graduations and funerals are important moments in life that cultures all over the world honor with ceremonies of some kind. Your quick morning meeting to discuss what you're working on isn't a @#(#(#( "ceremony".
How long do we think it will be before a lot of the recent negative sentiment about Scrum bubbles up to exec-level consciousness?
I've seen (and managed) plenty of Scrum, good and bad. In general I prefer Kanban approaches, but I don't think it's the deciding factor in team performance by itself.
I'm interested to see when we reach the point where it's no longer the default methodology everyone reaches for because "Scrum is how you do agile".
I've seen (and managed) plenty of Scrum, good and bad. In general I prefer Kanban approaches, but I don't think it's the deciding factor in team performance by itself.
I'm interested to see when we reach the point where it's no longer the default methodology everyone reaches for because "Scrum is how you do agile".
Scrum means different things to people.
To one manager scrum was a 30 minute sit-down chat in the conference room. To another manager was 2 minutes stand in the hallway. To another manager was a waste of time and he will come to each dev cube and get a gist of what we were doing.
A software development is only a team only in name. If developers like to help each other and talk to each other without having to be rounded up like gerbils is more of a fellowship.
To one manager scrum was a 30 minute sit-down chat in the conference room. To another manager was 2 minutes stand in the hallway. To another manager was a waste of time and he will come to each dev cube and get a gist of what we were doing.
A software development is only a team only in name. If developers like to help each other and talk to each other without having to be rounded up like gerbils is more of a fellowship.
The common thread is that scrum always prioritizes the time of the managers over the time of the people producing the work.
Take this with a grain of salt, because I've only experienced aspects of scrum, and I didn't hate it.
I think it's a mistake to think in black-and-white terms about management approaches. It's a mistake to adopt scrum rigidly, and it's a mistake to reject it in full.
Instead, we should look at what works and what doesn't, and consider their merits on a per-project basis.
So at the risk of being a contrarian, here are the ideas that I personally think are valuable from scrum:
(1) Break down bigger projects into smaller ones. I'm not sure it's beneficial to rigidly define a spring as 2 weeks. But the opposite of this is endless scope creep, where there's no clearly defined finishing line. By my definition, some springs might take a day. Others, several months. It really depends on what we're trying to accomplish. The smaller the period of the sprint can be, the less risk there is of losing focus. To paraphrase Einstein: Sprints should be as short as possible, but no shorter.
(2) Sprint planning may have too narrow of a focus, since it's entirely focused on the upcoming sprint, rather than the big picture. But I prefer it to going into detailed monolithic plans (i.e. waterfalls). No plan survives contact with reality, and the further out you plan, the more fictional your plans become.
(3) While I don't like fixed meetings that repeat with a specific rhythm (i.e. what scrum calls "ceremonies"), there is value in at least considering them on a per-sprint basis. Not every sprint justifies a daily stand-up, iteration review, or retrospective. But they do have merit. I just think they should be evaluated on a case-by-case basis rather than applied across the board.
(4) I have mixed feelings about product backlogs. On the one hand, they spare you from trying to plan out how to implement every request under the sun. On the other hand, they encourage you to simply go to the backlog and pick things you feel like doing for the upcoming sprint, rather than being focused on the next most important things. Important things don't need backlogs to be remembered. Important things will keep coming up, over and over. You're not going to forget them.
(5) The term "scrum master" is icky for many reasons. But I do believe someone should be in charge. Search all the parks of the world and you won't find statues to committees. Leadership matters.
I think it's a mistake to think in black-and-white terms about management approaches. It's a mistake to adopt scrum rigidly, and it's a mistake to reject it in full.
Instead, we should look at what works and what doesn't, and consider their merits on a per-project basis.
So at the risk of being a contrarian, here are the ideas that I personally think are valuable from scrum:
(1) Break down bigger projects into smaller ones. I'm not sure it's beneficial to rigidly define a spring as 2 weeks. But the opposite of this is endless scope creep, where there's no clearly defined finishing line. By my definition, some springs might take a day. Others, several months. It really depends on what we're trying to accomplish. The smaller the period of the sprint can be, the less risk there is of losing focus. To paraphrase Einstein: Sprints should be as short as possible, but no shorter.
(2) Sprint planning may have too narrow of a focus, since it's entirely focused on the upcoming sprint, rather than the big picture. But I prefer it to going into detailed monolithic plans (i.e. waterfalls). No plan survives contact with reality, and the further out you plan, the more fictional your plans become.
(3) While I don't like fixed meetings that repeat with a specific rhythm (i.e. what scrum calls "ceremonies"), there is value in at least considering them on a per-sprint basis. Not every sprint justifies a daily stand-up, iteration review, or retrospective. But they do have merit. I just think they should be evaluated on a case-by-case basis rather than applied across the board.
(4) I have mixed feelings about product backlogs. On the one hand, they spare you from trying to plan out how to implement every request under the sun. On the other hand, they encourage you to simply go to the backlog and pick things you feel like doing for the upcoming sprint, rather than being focused on the next most important things. Important things don't need backlogs to be remembered. Important things will keep coming up, over and over. You're not going to forget them.
(5) The term "scrum master" is icky for many reasons. But I do believe someone should be in charge. Search all the parks of the world and you won't find statues to committees. Leadership matters.
I work for a web dev firm in the infrastructure team.
They are trying to apply scrum and agile to us. It is not working.
I've been told ot to work on anything without a ticket. Outages have gone up.
It's a disaster.
They are trying to apply scrum and agile to us. It is not working.
I've been told ot to work on anything without a ticket. Outages have gone up.
It's a disaster.
The original article is apparently on linkedin (ugh but hey)
https://www.linkedin.com/feed/update/urn:li:activity:7101572...
Not extraordinarily insightful but an amusing take on occult ritualism as engineering.
https://www.linkedin.com/feed/update/urn:li:activity:7101572...
Not extraordinarily insightful but an amusing take on occult ritualism as engineering.
Speaking of occult rituals, I think scrum started to go wrong when we were told to stop it with the chickens and pigs.
https://www.visual-paradigm.com/scrum/scrum-pig-and-chicken/
https://www.scrum.org/resources/chickens-and-pigs
That's when it stopped being about teamwork and started being about micromanagement.
https://www.visual-paradigm.com/scrum/scrum-pig-and-chicken/
https://www.scrum.org/resources/chickens-and-pigs
That's when it stopped being about teamwork and started being about micromanagement.
What's the alternative, where devs are motivated and productive, the team can react to the market quickly, and the business can rely on delivery dates for commercial and marketing?
I'm not saying scrum and agile achieve the above. But what does? Seems like a 3 things pick 2 situation, and the 2 that get picked will time and again be the last 2.
I'm not saying scrum and agile achieve the above. But what does? Seems like a 3 things pick 2 situation, and the 2 that get picked will time and again be the last 2.
> and the business can rely on delivery dates for commercial and marketing?
Agile/scrum is almost explicitly contrary to this goal. There is a chance every two weeks to change scope, requirements, direction. What happens when requirements change? Work is redone, new work is taken on, dates get pushed. Scrum does not provide predictability beyond one sprint, it is part of the point. The work of the next sprint is based on the outcome of the previous.
Agile/scrum is almost explicitly contrary to this goal. There is a chance every two weeks to change scope, requirements, direction. What happens when requirements change? Work is redone, new work is taken on, dates get pushed. Scrum does not provide predictability beyond one sprint, it is part of the point. The work of the next sprint is based on the outcome of the previous.
I know, I said:
> I'm not saying scrum and agile achieve the above.
Companies abuse scrum to try and achieve the last 2 objectives. Sprints become commitments, sprints are planned out in advance, story points become days etc
> I'm not saying scrum and agile achieve the above.
Companies abuse scrum to try and achieve the last 2 objectives. Sprints become commitments, sprints are planned out in advance, story points become days etc
Ah, thank you for the clarification! :)
I really did not read your statement carefully enough and I apologize for that.
I really did not read your statement carefully enough and I apologize for that.
> Scrum is not for developers; it's another tool for managers to feel they are in control.
Bad managers would certainly like to do this but this is not what scrum is about
Bad managers would certainly like to do this but this is not what scrum is about
I'm not sure if a process can be a cancer. Instead, an institution that uses processes, Scrum included, to hide their ineffectiveness and inefficiency is.
Erik Meijer has a beautiful video saying basically the same: “Agile is a cancer we have to eliminate from the industry”. I believe the original video also had this title.
https://youtu.be/2u0sNRO-QKQ?si=veqouWjAzIaUt5TG
https://youtu.be/2u0sNRO-QKQ?si=veqouWjAzIaUt5TG
How do I avoid this in my career?
I’m a solo consultant and have had many good client relationships based on agreeing on deliverables. To summarize according to the old “pick two” adage of delivered-fast, works-to-spec and cheap: I’m fast, reliable, and expensive. I deliver high value and I’m always available to answer questions.
Interestingly, me consulting solo at an hourly rate doesn’t scale. To solve this, about 5 years ago I started a side business of building an electron app for designing and printing labels. I feel like scaling up allows my customers to pick all 3. The app is immediately available, it works, and it’s inexpensive.
So there’s another way to avoid agile and scrum: solo entrepreneurship.
Good luck!
Interestingly, me consulting solo at an hourly rate doesn’t scale. To solve this, about 5 years ago I started a side business of building an electron app for designing and printing labels. I feel like scaling up allows my customers to pick all 3. The app is immediately available, it works, and it’s inexpensive.
So there’s another way to avoid agile and scrum: solo entrepreneurship.
Good luck!
Call it out as BS when it comes up in discussions. Spread the word. Stop going along to get along.
In a large organization, this will change nothing. All you can do is be in a trusted position with upper management, and spend your political capital to prevent it. Even then, it may not work if some exec has implementing it as a goal to help their prestige/career.
Problems aren't resolved unless people shine a light on the problems.
Sure, but "Stop going along to get along" is how all these agile processes spread in the first place.
Opponents were ridiculed and bullied by proponents for being boring, old, unmodern, not team players, not using best practice or whatever. And way too many programmers were actual believers for grumpy safeguards to be able to keep things in check.
I think a cooperative approach might be better to get rid of agile or it will just be replaced by some other dogmatic cult. Agile is more of a symptom than the root cause.
Opponents were ridiculed and bullied by proponents for being boring, old, unmodern, not team players, not using best practice or whatever. And way too many programmers were actual believers for grumpy safeguards to be able to keep things in check.
I think a cooperative approach might be better to get rid of agile or it will just be replaced by some other dogmatic cult. Agile is more of a symptom than the root cause.
I think it's just best to call out BS when it pops up. That would have put a stop to this before it ruined everything. Cooperation is good, but people need to be told they are wrong. It's ok to be wrong. Everyone makes mistakes.
Become a data scientist. They don't do Scrum.
In my last company, when the idea of T-shirt sizing came up, I legitimately thought whoever mentioned it was joking. As if the rest of the excruciating processes, and petulant passive-aggressive behavior of my managers weren't patronizing enough. "Ah yes, now I get it, it's like clothing! I have some clothing right here next to me, now we're speaking a common language"
As usual, the truth is somewhere in between. To say it is cancer is to exaggregate to say the least. But it is certainly no miracle pill either. Like most things, it works best in moderation. If you apply it keeping in mind the agile manifesto, it is not too bad. But if you apply it like a rulebook, it will not be efficient.
As an example, "Individuals and interactions over processes and tools". A standup is interaction between individuals. I believe it was invented to get away from the formality of heading to a meeting room and waste time with a long agenda. Instead, short and concise, stand up around the desks just where you work. Short, efficient, concise.
However, now it may have outlived itself in many teams. We work more remote, have other tools than 15 years ago. So if it doesn't work, don't do it. But if you don't know what to do, you can use Scrum as inspiration, and take it from there. There are certainly worse ways, because Scrum was not born from nothing. It was a reaction to a worse way of working.
As an example, "Individuals and interactions over processes and tools". A standup is interaction between individuals. I believe it was invented to get away from the formality of heading to a meeting room and waste time with a long agenda. Instead, short and concise, stand up around the desks just where you work. Short, efficient, concise.
However, now it may have outlived itself in many teams. We work more remote, have other tools than 15 years ago. So if it doesn't work, don't do it. But if you don't know what to do, you can use Scrum as inspiration, and take it from there. There are certainly worse ways, because Scrum was not born from nothing. It was a reaction to a worse way of working.
Lol, I was on a team that was required to stand during standups, even though we all sat together and could just swivel our chairs around.
One dev flat out refused to stand. I can still see the pulsing vein on the neck of the project manager who so wanted to scream ‘You will stand during the standup dammit!’
One dev flat out refused to stand. I can still see the pulsing vein on the neck of the project manager who so wanted to scream ‘You will stand during the standup dammit!’
> One dev flat out refused to stand. I can still see the pulsing vein on the neck of the project manager who so wanted to scream ‘You will stand during the standup dammit!’
There's no project manager role in Scrum so he was already doing it wrong.
There's no project manager role in Scrum so he was already doing it wrong.
The reason I have heard about this is that standing is fatiguing and discourages people from going on and on. I get it but I think it's strange.
SCRUM solves a problem the X poster is too young to know. I'm mildly amused, he has no idea what SCRUM is about and why the ceremony is a lot better than the sleepless nights and the crunch time spent rewriting the application in the last month before release.
Pepperidge Farm remembers!
Pepperidge Farm remembers!
[deleted]
The good thing about Scrum is that there are hundreds of little dials that can be modified if you're not getting any value from it.
Due to this level of flexibility, it's always the right approach.
Due to this level of flexibility, it's always the right approach.
Isn't that precisely one of the most glaring issues with Scrum?
Scrum tries to provide a measure of velocity in such a subjective manner, it is not useful to anyone involved.
Scrum tries to provide a measure of velocity in such a subjective manner, it is not useful to anyone involved.
Yes, sorry, that was sarcasm. It's incredibly funny that Scrum's most redeeming feature is for it to be so configurable. Scrum has the configurability of SAP.
Someone has the courage to speak h truth. I have to finish work within a deadline, or it would look ugly, and I am trying to work today with ill health.
Why doesn't Scrum be a thing for humans? I feel like I'm a robot who has to be predictable all the time.
Why doesn't Scrum be a thing for humans? I feel like I'm a robot who has to be predictable all the time.
[deleted]
It's interesting. I saw this post after reading today's post about about Jake Seliger, and his brave and philosophical approach to death from squamous cell carcinoma.
The title felt oddly hollow.
The title felt oddly hollow.
Typical immature bullshit where someone describes their own company's screwed-up incompetent so-called "Scrum" and "Agile" implementation, and then claims that that's universalizable amongst all companies everywhere.
Just because a so-called "Scrum Master" not worth the title is forcing you to do BS things that inhibit your flow does not mean it's emblematic of the species. I mean, how would you feel if someone generalized all developers as a bunch of fat neckbearded social cripples reeking of BO? Same thing here.
I ought to bookmark this post in case anyone thinks that people on HN don't try to farm karma Reddit-style. What a crap bunch of outrage bait.
Just because a so-called "Scrum Master" not worth the title is forcing you to do BS things that inhibit your flow does not mean it's emblematic of the species. I mean, how would you feel if someone generalized all developers as a bunch of fat neckbearded social cripples reeking of BO? Same thing here.
I ought to bookmark this post in case anyone thinks that people on HN don't try to farm karma Reddit-style. What a crap bunch of outrage bait.
Typical Scrum apologist who describes how someone else must have screwed up Scrum or Agile. They then claim that pure "Scrum" or "Agile" has never been implemented anywhere.
If only people weren't so ignorant, we could give pure Scrum a try and solve all the world's problems.
If only people weren't so ignorant, we could give pure Scrum a try and solve all the world's problems.
> They then claim that pure "Scrum" or "Agile" has never been implemented anywhere.
They are right, however the conclusion that should be drawn from this is that the most likely outcome of your organisations implementation of agile will be equally as poor, and that it should prolly be skipped.
They are right, however the conclusion that should be drawn from this is that the most likely outcome of your organisations implementation of agile will be equally as poor, and that it should prolly be skipped.
Typical argument from an engineer arguing from math and not understanding that math does not describe human beings and their social relationships.
The guy in the Twitter pretty much mentions every red flag implementing scrum.
What did you expect the parent commenter to say? "you've done well and have shown that scrum doesn't work"?
What did you expect the parent commenter to say? "you've done well and have shown that scrum doesn't work"?
This is like complaining that because the shittiest sports team you follow doesn't win that playing that sport well is ipso facto impossible.
This is a No True Scotsman argument. The guy enumerated a list of ways scrum failed in his experience; it's always interesting to hear honestly about failure modes from people who have actually used something a lot in their work.
It's interesting to hear about failure modes, and anyone whose job it is to teach stuff like this is interested in hearing about failure modes. It's the taking of one person's experience and extending it to encompass everything that's wrong.
Obviously the people charged with implementing this in OP's company are doing it wrong. That doesn't mean it's OK to insinuate that everyone who ever tries to implement Scrum or Agile is doing it wrong. For every clueless toxic manager who doesn't understand how to use Agile correctly, there's an egotistical or lazy dev who also wants to throw what the Brits would call a spanner in the works for purely personal reasons.
But to call it a No True Scotsman argument is a lazy rebuttal which won't engage with the argument. There are plenty of shitty Agile practitioners, and no one is trying to dispute this.
Obviously the people charged with implementing this in OP's company are doing it wrong. That doesn't mean it's OK to insinuate that everyone who ever tries to implement Scrum or Agile is doing it wrong. For every clueless toxic manager who doesn't understand how to use Agile correctly, there's an egotistical or lazy dev who also wants to throw what the Brits would call a spanner in the works for purely personal reasons.
But to call it a No True Scotsman argument is a lazy rebuttal which won't engage with the argument. There are plenty of shitty Agile practitioners, and no one is trying to dispute this.
> For every clueless toxic manager who doesn't understand how to use Agile correctly
Anecdata Of One: I have worked at many places since 2005 and the most successful projects have been those without any Agile[1]/Scrum imposed by management. In contrast, the places with the worst outcomes[2] have all had distinct Agile/Scrum imposed by micro-managers[3].
[1] Plenty of places with iterative development but solely due to the nature of the work (changes required by external QA, experiments, etc.), not imposed.
[2] Software quality and speed of development-wise. They're all still alive and limping along despite the horrific nature of their internal systems.
[3] Who have always been there in a place with Agile/Scrum. Only once in a place without. I don't think it's coincidental.
Anecdata Of One: I have worked at many places since 2005 and the most successful projects have been those without any Agile[1]/Scrum imposed by management. In contrast, the places with the worst outcomes[2] have all had distinct Agile/Scrum imposed by micro-managers[3].
[1] Plenty of places with iterative development but solely due to the nature of the work (changes required by external QA, experiments, etc.), not imposed.
[2] Software quality and speed of development-wise. They're all still alive and limping along despite the horrific nature of their internal systems.
[3] Who have always been there in a place with Agile/Scrum. Only once in a place without. I don't think it's coincidental.
The same thing works the other way. People see and experience shit Scrum and then they No True Scotsman it to mean that all Scrum must be shit.
It seems to me that most American software companies use Cargo Cult Scrum. They basically take the terms and maybe read a blog about the processes and just wing it from there.
The only way an Agile/Scrum process works if you bring in a consulting company that's expensive enough to make even the top brass buy into it. You can theoretically try to bring it in from the ground up, but it's really hard to do Agile when the rest of the company is either waterfall or flying by the seat of their pants.
It seems to me that most American software companies use Cargo Cult Scrum. They basically take the terms and maybe read a blog about the processes and just wing it from there.
The only way an Agile/Scrum process works if you bring in a consulting company that's expensive enough to make even the top brass buy into it. You can theoretically try to bring it in from the ground up, but it's really hard to do Agile when the rest of the company is either waterfall or flying by the seat of their pants.
Sheesh, no wonder everyone is doing it wrong.
Are you a scrum master and feel personally slighted that the popularity is slipping?
And there's the typical internet argument!
"I disagree with you and here's why!"
"I'm sorry that you're personally offended. See, you disagreed with my pure, sweet, logical opinion, which means you must be personally offended, because no REASONABLE person would disagree with me. And because you're offended, you operate on emotions, as opposed to my high-and-mighty self, who operates on pure, sweet logic. Thus I am right and you're a crybaby, because you dared to disagree with what I consider to be my pure, sweet logic."
"I disagree with you and here's why!"
"I'm sorry that you're personally offended. See, you disagreed with my pure, sweet, logical opinion, which means you must be personally offended, because no REASONABLE person would disagree with me. And because you're offended, you operate on emotions, as opposed to my high-and-mighty self, who operates on pure, sweet logic. Thus I am right and you're a crybaby, because you dared to disagree with what I consider to be my pure, sweet logic."
[deleted]
Are you a scrum master? Going to school for it? What is your experience with scrum? Have you tried it? What are the advantages and disadvantages?
Do you even code?
Scrum is good if you have moderately dysfunctional stakeholders or moderately dysfunctional developers. Otherwise it's not needed.
Arbitrariness, disconnection from purpose, jargon, standups being badly structured meetings, disempowered product "owners," etc. are reasons to call it "cancer."
Agile was needed, to replace waterfall management of software development projects. In particular, trying to do resource leveled critical path analysis for most software projects is the road to project hell.
But, yeah, Scrum, as too many Scrum Masters practice it, gives Agile a bad name.
Agile was needed, to replace waterfall management of software development projects. In particular, trying to do resource leveled critical path analysis for most software projects is the road to project hell.
But, yeah, Scrum, as too many Scrum Masters practice it, gives Agile a bad name.
I thought agile “fixed” waterfall because waterfall had all this effort go into a product only to get feedback at the end, which to me sounds like a failure of product not engineering. By having tighter feedback loops it was promised less man-hours would be spent. My impression is it’s changed what the man-hours are spent on. It’s harder to get an elegant architecture over 2-3 years of agile as opposed to waterfall where it can be more tightly controlled. That’s probably the limit of my perspective on the matter. I am positive there are others that know more and have a more accurate perspective on why and how things changed.
This "waterfall had all this effort go into a product only to get feedback at the end" was Winston Royce's own diagnosis of the problem with the waterfall model he formalized.
That's part of it. In more practical terms, assigning people to tasks tactically as a project progresses is probably 80% of the advantage of Agile.
You are also spot on that you can start an Agile project and find your architecture is a pile of poo 2/3rds of the way through, in part because you can start without the waterfall set of specs.
A lot of the dissatisfaction in the "Scrum is cancer" article is about estimation, and I agree: Trying to improve estimation is a fool's errand. Your highest risk tasks are generally what create the most value, solve the hardest problems, etc.
More emphasis on retrospectives, and accepting that estimation fails most of the time, is what a lot of Scrum-as-a-cargo-cult misses.
That's part of it. In more practical terms, assigning people to tasks tactically as a project progresses is probably 80% of the advantage of Agile.
You are also spot on that you can start an Agile project and find your architecture is a pile of poo 2/3rds of the way through, in part because you can start without the waterfall set of specs.
A lot of the dissatisfaction in the "Scrum is cancer" article is about estimation, and I agree: Trying to improve estimation is a fool's errand. Your highest risk tasks are generally what create the most value, solve the hardest problems, etc.
More emphasis on retrospectives, and accepting that estimation fails most of the time, is what a lot of Scrum-as-a-cargo-cult misses.
Here is Royce's statement on his own waterfall model's risks:
I believe in this concept, but the implementation… is risky and invites failure. … The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.
I believe in this concept, but the implementation… is risky and invites failure. … The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.
This is the crux of the issue. A CIO once asked me what I thought was the most important factor for a software project to be successful. I told him good requirements. The CIO proceeded to lecture me with Agile you don’t really need requirements. I thought he was full of shit. It is the same thing as answering a question in the SAT exam. If you don’t know the question (requirement), how can you answer the question? This is truly nonsensical Orwellian logic. It is communism.
Real Communists use Gantt charts. Henry Gantt's colleague Walter Polakov brought "scientific management" to Soviet 5 year plans.
I'm honestly surprised to see a post with a vitriol-to-insight ratio so bent in favor of vitriol getting such a positive response. I think the poster here is way, way off mark.
It's incredibly frustrating, because so many of the things he says suggest that he or his organizations truly don't understand scrum, yet he proactively goes on the offensive against anyone who suggests he's wrong and won't listen to any evidence that he is. (And yes, I get that this post is just a 'vent', but 'just venting' content is not usually the sort of thing I expect to see make the front page of HN.)
I have been on multiple teams, including my current one, where Scrum has been a massive success (as measured by products shipping on time and in-spec with positive reception by customers, as measured by the company making money off my work, as measured by my own and my team's performance assessments relative to my org). Absolutely none of the following happen on my team, or on any team I've been on where things were working in those terms:
> We spent more time talking than doing. > We spent more time estimating story points than writing software. > We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points." > We paid people who told us whether we were "burning down points" fast enough. > We brought professional Scrum trainers. We paid people from our team to get certified. > We spent years [continuing to try things that didn't work].
Absolutely none of this happens on my current team and absolutely none of this is required to do Scrum "right" or at all. I've been on three teams in my current organization and five+ teams overall that used Scrum over a period of more than eight years and while all of them had issues, none of them did any of the above. I'm sorry this person has had so many bad experiences, but at a certain point, you've got to ask whether your attitude and approach are part of the problem. I see a lot of things in this person's attitude that make me think they could be.
For example, he makes comments where he just whines about not liking terminology, like:
> 1. They tried to convince me that Poker is a planning tool, not a game. > 5. I had to use t-shirt sizes to estimate software.
He also phrases sentences which are not arguments (or at least, are not really relevant without some explanation) as though anyone should understand why he's mad:
> 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
and then finally, spends lots of time asserting (with no evidence) things like:
> [Scrum] fails everywhere, every time, but they tell you “you aren’t doing it right.”
while simultaneously talking down anyone who tries to suggest he's maybe, legitimately not understanding Scrum.
If this is the approach he took with the people who were trying to help him implement Scrum, no wonder it didn't work. It was probably never going to.
By the way, this person offers a service where you can pay him to present "learnings" about your content on Twitter, or wherever. Without disclosing that the content is sponsored. Pretty scummy. See https://www.svpino.com/
It's incredibly frustrating, because so many of the things he says suggest that he or his organizations truly don't understand scrum, yet he proactively goes on the offensive against anyone who suggests he's wrong and won't listen to any evidence that he is. (And yes, I get that this post is just a 'vent', but 'just venting' content is not usually the sort of thing I expect to see make the front page of HN.)
I have been on multiple teams, including my current one, where Scrum has been a massive success (as measured by products shipping on time and in-spec with positive reception by customers, as measured by the company making money off my work, as measured by my own and my team's performance assessments relative to my org). Absolutely none of the following happen on my team, or on any team I've been on where things were working in those terms:
> We spent more time talking than doing. > We spent more time estimating story points than writing software. > We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points." > We paid people who told us whether we were "burning down points" fast enough. > We brought professional Scrum trainers. We paid people from our team to get certified. > We spent years [continuing to try things that didn't work].
Absolutely none of this happens on my current team and absolutely none of this is required to do Scrum "right" or at all. I've been on three teams in my current organization and five+ teams overall that used Scrum over a period of more than eight years and while all of them had issues, none of them did any of the above. I'm sorry this person has had so many bad experiences, but at a certain point, you've got to ask whether your attitude and approach are part of the problem. I see a lot of things in this person's attitude that make me think they could be.
For example, he makes comments where he just whines about not liking terminology, like:
> 1. They tried to convince me that Poker is a planning tool, not a game. > 5. I had to use t-shirt sizes to estimate software.
He also phrases sentences which are not arguments (or at least, are not really relevant without some explanation) as though anyone should understand why he's mad:
> 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.
and then finally, spends lots of time asserting (with no evidence) things like:
> [Scrum] fails everywhere, every time, but they tell you “you aren’t doing it right.”
while simultaneously talking down anyone who tries to suggest he's maybe, legitimately not understanding Scrum.
If this is the approach he took with the people who were trying to help him implement Scrum, no wonder it didn't work. It was probably never going to.
By the way, this person offers a service where you can pay him to present "learnings" about your content on Twitter, or wherever. Without disclosing that the content is sponsored. Pretty scummy. See https://www.svpino.com/
I think the biggest risk to scrum as a methodology is the fact that when it so frequently fails, its defenders constantly fall back on "but that wasn't true scrum". Like, that's 90% of all the posts here defending scrum. Yet the things this guy describes are recognizable to many of us, perhaps it's an extreme case but not that extreme.
there's a very strong selection bias. we don't really hear about the cases where a team does so-so sprints, it's not great agile/scrum/paganism, but the product evolves, development goes in an okay-ish manner, and there's just not much to talk about.
the whole structure gives enough support, retros surface problems and give sufficient pushback against "features only, no bugs" management style, sprints gave some sane cadence to both devs and product, daily status checks help to detect folks who are stuck, "refinement" forces both sides to actually commit to some kind of written stuff, and "grooming" provides much needed priorization and black comedy relief as the team tries to come up with a non-pedo expression for the activity.
of course, there are valid criticisms of scrum/agile. mostly that it fails to teach developers to realize their need to set boundaries with regards to interaction with "the client", aaand that most managers and projects are non-ideal, underfunded, and devs should leave it, and look for better ones (even with possibly lower pay).
the whole structure gives enough support, retros surface problems and give sufficient pushback against "features only, no bugs" management style, sprints gave some sane cadence to both devs and product, daily status checks help to detect folks who are stuck, "refinement" forces both sides to actually commit to some kind of written stuff, and "grooming" provides much needed priorization and black comedy relief as the team tries to come up with a non-pedo expression for the activity.
of course, there are valid criticisms of scrum/agile. mostly that it fails to teach developers to realize their need to set boundaries with regards to interaction with "the client", aaand that most managers and projects are non-ideal, underfunded, and devs should leave it, and look for better ones (even with possibly lower pay).
Testimony from dozens upon dozens of developers that think that scrum is useless, toxic bullshit:
https://github.com/rayfrankenstein/AITOW/blob/master/README....
https://github.com/rayfrankenstein/AITOW/blob/master/README....
Data from lots of people who think Scrum is great and love it:
> https://www.parabol.co/resources/agile-statistics/#agile-eff...
It's the Internet. You can find a few thousand (or few million) people who love or hate anything.
What's your point?
> https://www.parabol.co/resources/agile-statistics/#agile-eff...
It's the Internet. You can find a few thousand (or few million) people who love or hate anything.
What's your point?
> 78% of Scrum practitioners would recommend the framework to colleagues, friends, or other professionals. (Source: Scrum Alliance)
It’s a joke that writes itself.
It’s a joke that writes itself.
If a cancer is merely something that I don't like and can opt out of, suddenly cancer doesn't seem so bad.
Finally, by far, most people hate Scrum with passion.
I got so tired of hating Scrum with passion, that I pulled a 179 and wrote a comic book about it.
In your honor for your courage and honesty, adrianmsmith, it's free, today only. All enjoy!
https://eddiots.com/1700
I got so tired of hating Scrum with passion, that I pulled a 179 and wrote a comic book about it.
In your honor for your courage and honesty, adrianmsmith, it's free, today only. All enjoy!
https://eddiots.com/1700
> Scrum is a cancer that will eat your development team. Scrum is not for developers; it's another tool for managers to feel they are in control.
Agile and Scrum are for managers who don't know what they want, but they'll "know it when they see it". (Or more likely, they'll declare that they wanted is what they've got when the money runs out.)
Just stay away from it, if at all possible.
Agile and Scrum are for managers who don't know what they want, but they'll "know it when they see it". (Or more likely, they'll declare that they wanted is what they've got when the money runs out.)
Just stay away from it, if at all possible.
Putting Agile and Scrum in the same bucket is right only if you know only waterfall in your comfy corporate/government job
agreed, Agile and Scrum are not the same, and if you read person's followup comments, even he says "he believes in Agile" but hates Scrum.
Yeah, most aspects of Agile (iterative development, MVP...) are fantastic and it has made most types of engineering lighter, more team-focused and well more agile.
Yeah, most aspects of Agile (iterative development, MVP...) are fantastic and it has made most types of engineering lighter, more team-focused and well more agile.
This looks like nothing but engagement bait for twitter's new monetization program. If I tweeted "Capitalism is cancer" or "Socialism is cancer" I'd get a lot of dumb responses too, but that wouldn't be evidence of anything except that constructive debate involves nuance and asking thoughtful questions and defining terms.
agile is fine (ie delivering features incrementally) but the scrum process around it is useless.
So what is an alternative process?
Kanban is one alernative[1]
[1] https://en.wikipedia.org/wiki/Kanban_(development)
[1] https://en.wikipedia.org/wiki/Kanban_(development)
My question is - how DO you convince management to let you try Kanban?
We would like to try but we can't, as "everyone else here does Scrum so the problem is in you, not in the process".
We would like to try but we can't, as "everyone else here does Scrum so the problem is in you, not in the process".
In my case, it was a few managers in the org who decided to change over from scrum to kanban.
If there are some teams in your organization or company using kanban, you can use them as an example. If issues brought up in the retrospectives are not being addressed and those issues are related to the scrum process, then that might be a way to get something to change.
If there are some teams in your organization or company using kanban, you can use them as an example. If issues brought up in the retrospectives are not being addressed and those issues are related to the scrum process, then that might be a way to get something to change.
Spoken like a true scrum master.
You don't have to produce an alternative to critique something. In fact making such a requirement makes problems linger.
You don't have to produce an alternative to critique something. In fact making such a requirement makes problems linger.
You absolutely do. If you are going to critique something, be sure to present what's in your view a better alternative, otherwise what's the point of complaining about a way of doing things other than being negative?
it's very religion like...
The say they are doing scrum, but they aren't really doing scrum
He says he's a christian but it's clear to me that he wasn't one all along.
The say they are doing scrum, but they aren't really doing scrum
He says he's a christian but it's clear to me that he wasn't one all along.
Lots of people claim to be Christians but don't forgive, turn the other cheek or love their neighbors because it doesn't suit them to but it does suit them to claim to be Christian.
So any successfully communicated methodology is going to be claimed by lots of hypocrits and then perverted while they simultaneously boast how much they love it.
And then you'll get the opposite kind of person who doesn't believe in forgiveness or loving their neighbors and sees a great chance to attack those ideas by supporting the hypocrits deception and claiming that their perversion is the real (evil) religion.
None of this helps software get built but is just a power struggle between developers who don't want to reduce the bus factor or despecialise or write tests or do maintenance or change their great plans to suit circumstances.
So any successfully communicated methodology is going to be claimed by lots of hypocrits and then perverted while they simultaneously boast how much they love it.
And then you'll get the opposite kind of person who doesn't believe in forgiveness or loving their neighbors and sees a great chance to attack those ideas by supporting the hypocrits deception and claiming that their perversion is the real (evil) religion.
None of this helps software get built but is just a power struggle between developers who don't want to reduce the bus factor or despecialise or write tests or do maintenance or change their great plans to suit circumstances.
the problem is, it's hard to prove that someone is not a true "_____". Because the definitions are not well defined.
Scrum gives me the same impression as liberal economics. An intellectual tradition centered around quantifying things that can't reliably be quantified, as well as projecting incomplete models on top of reality in service of economic interests and insisting that they are correct.
Any good alternatives?
Oh, it's the kiddo who thinks they are very smart and adult for being a proud-to-be-misinformed gratuitous anticommie again.
It's sad that posts like these get so many points.
A sad take that's based on a sad experience with a great framework.
A sad take that's based on a sad experience with a great framework.
Then the individual goes on the dumber-than-life anti-communist rant. I love how he tries to create a bunker with "if you disagree you're into Scrum".
I dislike Scrum quite a bit, but oh gee ain't that a full plate for Scrum apologists to have a point.
I dislike Scrum quite a bit, but oh gee ain't that a full plate for Scrum apologists to have a point.
The individual was born in the unitary Marxist–Leninist one-party socialist republic of Cuba and lived there for a bit under three decades. He might have some expertise on the topic.
Don’t blame scrum/agile for bad decisions made to appease business executives. A product owner’s role is to seek input from stakeholders and then make decisions to satisfy those stakeholders and the company’s business directives.
Companies were making poor technical decisions for short term business reasons long before agile became popular.
The cancer you seek is actually called capitalism.
Companies were making poor technical decisions for short term business reasons long before agile became popular.
The cancer you seek is actually called capitalism.
However, the management insisted that we adopt Scrum and get a Scrum Master to help us.
I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now).
The management response was: "that is not real Scrum, you had bad experiences because you weren't doing it right previously".
After three months, the progress slowed to a crawl, star dev abandoned ship, and customers started complaining for the first time.
Now I will just wait for someone to tell me that this wasn't real Scrum either, because we were supposed to have Product Owner talk to the client instead of Scrum Master :)