11 ms·

Scrum has failed the developers

111 points by ghuntley 4y ago

shagymoe 4y ago
This thread is all problems a no solutions. I also don't like traditional scrum and meaningless ceremonies but there is value in some of the methodology. There is one thing in particular that no one here is addressing. Underperforming developers. Every comment assumes that all developers are fully equipped to excel if management would just get out of their way. Um, no. I've seen extremely knowledgeable and talented developers who, left to their own devices, fail miserably. You "empower" them to do amazing thing and set them up for success and they get almost nothing done. If there's no one holding them accountable, they just coast. The truth is that some people and teams need the extreme rigidity and process that comes with scrum or they will simply not ship. Other teams will die in a fiery explosion or wither quietly into attrition if you force process on them. The best you can do is set a foundation and course-correct as the team succeeds or fails. You might end up with very little meetings or 2x scrum ceremonies. Whatever it takes for the team to be productive and happy. There is no "One Process to rule them all" and leaving developers total freedom to do whatever they want is definitely NOT the answer. The best process for a team will likely change over time due to many factors like company stage, # of members, their experience levels, their commitment levels, their personalities, etc... The job of a manager is to tailor the team's process to what achieves both the business goals and keeps people happy. It's a difficult and thankless job which few do well.
- s1k3 4y ago
  Poor performing developers cannot be fixed with a process. This is a management problem. It’s up to the developers manager to properly motivate and course correct flagging devs. Trying to push off HR problems on a software delivery process is the most dev take I’ve ever heard.
  - shagymoe 4y ago
    You're missing the point. Some people NEED daily standups and some people will literally quit if they have to do it. That's process. It becomes more difficult when those two individuals are on the same team and then you have to micro-manage the the under-performer who can't be trusted to give accurate updates and make progress. Sure, managers need to motivate and course correct when necessary but process can help with that.
deleted 4y ago
[deleted]
WheelsAtLarge 4y ago
Fine, scrum sucks! I agree. What's the alternative?
- rawgabbit 4y ago
  We can start by recognizing that scrum and agile cannot replace actual development talent. When companies throw additional scrum masters and project managers into a failing project, the project only fails faster. People first, tools second, and then process.
  - pempem 4y ago
    ^ this is agile. at least "people first" - then its process and tools. Tools are last, because there are always new tools and the way you do something should be somewhat consistent within a team/org even if the tools aren't While scrum/agile does not = more developers, it can be leveraged to actually grow a developer's career and skills when done well.
    - rawgabbit 4y ago
      As a technophile, I always disagree with that sentiment. Michelangelo cannot sculpt the Pieta with a sledgehammer and sticks. These days we need highly specialized tools to do our work. These highly specialized tools require specialized developers. The only alternative to this is low code/no code tools. Low code/no code is great for green field projects, as you can ensure a steady pipeline of such developers.
      - pempem 4y ago
        oh my. In a world of continously created saas pursuing bits of walletshare and department budgets endlessly I would say there is a small % of tools that are specialized and uniquely required. There's also a TON of tools that are preference based selection. Michelangelo sculpted with one set of tools and painted with another. Klimt may have had some overlap with one and none with the other set. Neither was being doggedly pursued by salespeople or having decisions about tools made by their bosses. IMO: Its not an apt metaphor in the slightest.
drewcon 4y ago
Honestly. Software at Big Co is more like building a house. If you’re in a high uncertainty environment with loads of market risk, by all means Agile away. But if you’re designing and developing something fairly well understood… something more oriented towards a better understanding up front with bigger customer delivery increments is completely fine.
- prpl 4y ago
  Architects, permits, contractors, hazmat anbatement, inspectors, etc…?
  - Gravityloss 4y ago
    As a person who has not actually built a house but has done some renovation and designed and built some temporary structures, the amount of unexpected things coming up is surprisingly similar to software development! I have a large amount of respect to people who have built a house. And even more for those who have built a bridge or a skyscraper.
- Lio 4y ago
  > But if you’re designing and developing something fairly well understood… There in lies the problem; building software is not like building a house. I've seen many projects at Big Co fail to deliver on time, budget or quality because senior managers believed that everything is "fairly well understood" up front when just wasn't true. That mistake leads to treating estimates as concrete delivery times, scaling the development team before it's ready and a refusal to fix things that hurt productivity because they're not on the unchangeable timeline. The author is correct Scrum is usually sabotaged by outside influences trying to turn it into waterfall. If IBM couldn't make waterfall work in the 1970s it's very unlikely that will work anyone's big project today either.
- mmcnl 4y ago
  Fairly well understood and "Big Co" don't really go together.
patothon 4y ago
I don't understand why we're still talking about SCRUM. People saying they're using SCRUM (by this I mean "literally saying 'SCRUM'") are a dying breed and if they're not then they're cargo culting and I'm not sure why this is more of a big news than management cargo culting waterfall or kanban. I used to be one of these process experts selling methodologies to whoever was ready to pay, from SCRUM to lean startup. After doing this full time for 2 years the only conclusion is that none of these processes hold long enough. Why? 1/ every product / team / output is different. some teams should be ticket driven, other exploratory driven, and each of these methodologies apply to one situation only 2/ high turnover in the industry. meaning that new people come and organically change the new flavor of the day, the dynamic of the teams and the throughput of the team 3/ all of the best teams I've worked in the industry (from seed stage to FAANG through late stage startups, and even F50 companies), just do WHATEVER that works for them and don't comply with the flavor of the day (except for the looks of it). They all use a shared core set of values (deserves it's own blog post), and you can find this core set of values in most agile methodologies, buried behind ritualistic behaviors anyway. I could go on. Just let it go, and if you're working in one of these last companies applying SCRUM unironically, you're probably not in a high performing team. Time to move
- deleted 4y ago
  [deleted]
- siva7 4y ago
  So you sold methodologies to companies as a process expert and none of them ever hold up? Maybe you reached the wrong conclusion after all.
  - scott_w 4y ago
    Honestly, this isn’t surprising. Typically external process change struggles to take root because the person isn’t there long enough to really understand the team, the problems, the culture, etc. I don’t think this is the consultant’s fault, either. Usually the company doesn’t want to pay the money or time to do this.
ramesh31 4y ago
Anything that gets between what me, the designer, and the PM want to do needs to go. There’s an entire industry of bullshit around framing and tracking that fundamental working unit which actually builds software. Project managers, Scrum masters, whatever. If you really need acountability to the bean counters, let them define their own KPIs and give me and the PM an interface to them. Anything else is a total waste of time and effort.
- drewcon 4y ago
  - SgtBastard 4y ago
    This comment is beneath HN. AMZN (amongst numerous other household name brands) ships world class products with 2-pizza teams where a dev, a designer and a product manager are having the conversations that need to be had to ship. Do better.
vegetablepotpie 4y ago
I completely agree with the author, it’s the environment. Scrum was intended to empower developers by allowing them control over when new work got scheduled. In reality it has been used by management to export their responsibilities onto developers while not ceding control. With scrum, planning and estimation are now done by developers. But management still reserves the right to reschedule mid-sprint for the all so urgent pop ups they need handled. The only thing developers can do to make scrum work is be completely devoted to the process and not the business, but that is a career limiting move; scrum masters are put in positions to either be ineffective or be ablative armor for their teams.
NAHWheatCracker 4y ago
I've never been in an environment where Scrum was used to create real pressure. I've been in environments where it creates fake pressure. Standups where you have to say something for fear that you'll be axed if you say nothing. Questions about whether a ticket is going to get done by Friday. I call these fake pressure because it becomes obvious that there is no teeth to them. People get away with doing nothing and making up a few sentences at standup. People say a ticket is going to be done, but it roles over through two or three sprints. It's always been a sham for me. You can't point at the Agile Manifesto and say that we're focused on process over interactions. You can't point out that we need a Product Owner who is focused communicating the needs of real users. You can't point out that standups should be for the team's benefit and not status updates to project managers who are barely involved. Still, I'm a firm believer that the Agile Manifesto makes some good points. I believe that there are elements of Scrum that are really beneficial if implement well. I believe all of it is subverted by management that wants a semblance of control/power. Most of the workers don't care whether it's subverted, they're just there to be paid while doing as little work as possible. So, who's left to change it? A few righteous agitators? Who are they going to agitate? The managers who have control aren't going to give up the reins. The hoi polloi will ignore anything that takes extra effort. Saying the scrum master needs to be accountable is true. Everyone should be accountable for something. However, there's simply no way for that to happen in many environments. I've had scrum masters that were basically just required to gather status updates and report them back to the CTO. I've had contractor scrum masters that were hired because Scrum said they had to have that role but they ignored the part of Scrum that said there was a product owner role. I've had scrum masters that were just engineering managers who ignored their engineering manager roles to be the one who screen shared the Jira during standups, including one who was a Director of Engineering. All of those scrum masters were installed by the people in power not to be held accountable for anything. Most of those scrum masters, like all the other workers, just want to get by with doing as little as possible while being paid.
- icedchai 4y ago
  I worked at a place that ran sham sprints all the time. If you couldn’t finish something, your ticket would get marked complete, and a new one opened to finish the work (“integrate [component]”) next sprint. This was so the points would be booked and the team stats wouldn’t look bad. I saw one ticket roll over for a good 2 or 3 months like this.
jboy55 4y ago
I think the blog mentions this, and I'm glad its not just another complaint listing the failings of Scrum as it exists at an unnamed company. But I would put forth that no process can save developers from pathological management with poorly conceived products and even not "having a process" will help. As long as NPD* continues to be a great indicator of success in gathering VC funding and upper management success, developers will be exposed to horrific work environments. These environments will be label 'Agile', 'Extreme' or whatever label can attract talent. No manner of 'Process X sucks' blog posts will change this. If the Hacker-News Scrum hating community comes up with a "better named process", or a successful manifesto advocating the 'end of processes', organizations led by sociopathic management will quickly adapt these slogans and then distort the environment to their likings. If management is beating you with sticks because you missed getting your story points done by end of sprint, the problem isn't a process that measures stories by points, and has biweekly sprints where velocity can be measured; its having management that is willing to beat developers with sticks. * Narcistic Personality Disorder
studifi 4y ago
Scrum is not for developers, it’s for anxious leaders.
- jacknews 4y ago
  Yes it can be, a way for teams to self-document their failings etc, and allow management to 'inspect' everything with little effort. If it really worked, managers would also be subject to it.
- Haga 4y ago
fatneckbeardz 4y ago
why do i feel most of whats good about "agile" was actually already being done in the open source world before Agile was even a thing?
- JohnFen 4y ago
  Because it was. "Waterfall", as described by agile evangelists, was a very rare practice. Good shops had a process that already incorporated most of the best features of agile.
KingOfCoders 4y ago
We should have stayed with XP.
- tempodox 4y ago
  XP is maybe the purest example of the basic problem. If you're good enough to actually practice XP, you don't need a methodology at all. You'll do the right thing in each situation. Methodologies are for those who aren't good enough. And apparently they always find a way to pervert it into its opposite, because people never get tired of exerting power and maintaining an illusion of control.
  - KingOfCoders 4y ago
    Yes, if everyone is good you don't need processes. I do think Scrum took off because it is the opposite of XP, it doesn't tell developers any development practices (Pair programming etc.) so developers didn't feel bullied and said "Yeah, ok, lets do your Scrum". But it backfired.
twelve40 4y ago
Yeah I had to suffer through the full-blown training from a "Senior Agile Coach" like the author - taken extremely seriously by the management at the time, so I can see how a bunch of people who took this stuff literally - including the "coaches" - are a bit heartbroken now. My employer who ordered that expensive training collapsed several months after that. But, trying to distill all the formalistic nonsense into usable points, they actually do have a few. My personal takeaways: - try to ship faster (try daily for a webapp), but do what feels right for you - have some task board and scrub it regularly (once every week or two, whatever) - learn to use ballpark estimates (1 hour, 1 day, 1 week - or whatever else floats your boat. Fibonacci, none of this stuff will ever be realistic - just get the order of magnitude) - have short meetings about blockers, but schedule stuff for later the moment someone starts banging on for too long - yeah, and try to break stuff down into smaller, more manageable pieces, the spec, the PR's, pretty much everything No idea if this is "SCRUM" or not, but this has worked for me so far...
- praptak 4y ago
  That could also be kanban. Which is actually great - it means that what you described is a set of tools, which can be used for whatever purpose the team decides. That's agile, as opposed to forcing a process on the team.
  - blub 4y ago
    It’s not Kanban, because that revolves around minimizing work in process, balancing ins and outs at each step of the process and making work visible.
- mmcnl 4y ago
  Yeah that's very much like scrum.
- voxl 4y ago
  Using estimates has not and never will be a useful idea. You are in one of two worlds, either your work is predictable and easy to estimate, in which case you could just count the number of tasks/stories and get a sufficient estimate anyway, or your work is very unpredictable in which case your estimates are a lie.
tjpnz 4y ago
I've seen it work well when practised by small, mature and highly independent teams. Where things start to fall apart is when management gets interested or heaven forbid, the company decides to spin off its own bastardized version of the process (often by bolting on the worst aspects of waterfall).
xedrac 4y ago
Scrum is the bane of my existence as a developer. It sucks all creativity and enjoyment out of software development, and replaces it with anxiety, shame and mountains of tech debt. And don't get me started on the velocity metric that so many managers can't seem to live without (see Goodheart's Law). For whatever reason, I'm 10x more productive when I have the autonomy to bounce ideas off my team and proceed in the best way I see fit.
- bladelessninja2 4y ago
  Just like there are companies who say they are Agile, but they are not, there are teams who think they have Scrum, but it is not Scrum. If you say that Scrum encourages tech debt and you had no autonomy then probably it wasn't Scrum. The other option is that you were using Scrum where it doesn't fit. By Pareto principle: 80% of times when I see "The tool X sucks" it is because people are using wrong tool or they are using tool wrong.
  - pydry 4y ago
    I was told this once by a scrum trainer when I told him it sucked. I then challenged him to figure out which part we were doing wrong. He couldn't coz we pretty much did it to the letter - following the directives from another scrum trainer. I call it the no true scrumsman fallacy. Doing it "properly" means doing a series of mini waterfalls. Thats just how it was designed. I'd say it functions as a poor but semi functioning compromise between an intransigent waterfall management and an agile team.
  - xedrac 4y ago
    We can debate the purity of scrum, but in practice, every company I've worked for has modified it to suit management desires, and those modifications have almost always been to the detriment of developers. For example, the "complexity" of a story is inevitably interpreted as "time". And the end of every sprint is often turned into a deadline that leads to tech debt. Creative development is not always a linear process, which scrum somewhat enforces. I think it could work if every story was treated as a spike, and every spike could be pre-empted by new spikes as you discover new things. If it was able to truly flow the same way software devs actually think and work, then it could work. The result of a spike could be a finished work, or perhaps many other spikes. This would model creative development better. But companies don't go for this because they cannot easily estimate time and schedules.
dc_ist 4y ago
Ashamed to admit I was once a Certified ScrumMaster. I’ve grown to realize that it’s too difficult to implement. The gains, if any, aren’t worth the effort and overhead. As the agile manifesto says: “Individuals and interactions over processes and tools”.
ggm 4y ago
What does NASA do to develop new code for Mars? What do people writing realtime flight control systems do? What do quants writing investment strategy code do? Do they all do the same thing? Would they call their process a ritualised behaviour?
- pjmlp 4y ago
  Basically high integrity computing processes, very waterfall like, and with quality process verification that most companies will only ever adopt when liability becomes a common legal requirement in software delivery.
- twelve40 4y ago
  It'd be nice to summon someone from that side of things, but I'd venture to say it's just built really differently. Like, how a bursting bathroom pipe in an apartment is different from the same purpose plumbing on SpaceX. Humans actually keep building both, somehow.
plaguepilled 4y ago
I would like to propose a different perspective in Scrum and Agile: they're really actually reasonably good. Or rather, they do go wrong, but they go wrong for reasons outside of the scope that a development process considers. Instead, I argue the issue is related more with the way that managers and employees interact, and the expectations they both bring to the table. More explicitly, I am arguing that if the development process changed at a company with a manager running agile processes, the manager won't necessarily suck less if they were already bad. Likewise to the employee. My suggested action is to treat this as a question around social environment, and tweak accordingly. This would be different for each company I would expect.
- MattPalmer1086 4y ago
  I had great success using scrum in central government. It freed us from the whole "get a document approved by lots of external parties before you can do anything" mentality. . It helped that because it was such a different process, they largely left us alone. They loved the regular retrospectives. They were awed to see feedback from the previous retrospective made real by the next one. By the end we delivered more for less and it actually did what the stakeholders cared about (not what people thought they wanted when we started and didn't understand it).
- bladelessninja2 4y ago
  Exactly. I saw employees who said they have Agile implemented, but for example they were too weak to speak up, take responsibility and pursuit technical excellence. Same with managers: they say they are Agile, but trusting your employees that they will get the job done was a joke to them.
pjmlp 4y ago
Having gone through all the management fads for the last 30 years, Scrum in practice might not be agile, but it is definitely better than any other alternative in big corporations. I for one am glad that there are Scrum masters and POs to deal with all the politics and project nonsense that I don't have any interest in being part of.
mrjin 4y ago
Have been using scrum/agile for over a decade now. To most of the companies if not all I worked for, agile/scrum was nothing but just a fancy buzz word to the management team. They just did what they were already doing under the name of agile. Put all that aside, scrum/agile is actually pretty good on tracking small and simple tasks. So if the whole project can be broken down to nice and small tasks and the estimates were accurate, agile/scrum will work perfectly. Unfortunately all the project I've ever involved were complicated, some were even super large. We humans are pretty bad at estimating and no surprise most estimations were way off. Also, there were huge tasks that could not be broken down. That's exactly where the short coming of scrum/agile. Also, in most projects there were for sure huge, hard and important tasks that needed to be solved as soon as possible. But in scrum/agile, the team tends to pick the small, simple and easy tasks first as it would make the metrics nicer. So when they finally have to pick those important hard and huge tasks, it would be most likely way too late as there were already too much done in the wrong way.
- pydry 4y ago
  >Also, there were huge tasks that could not be broken down. I've come across tasks that were difficult to break down and required a bit of creativity. Never come across one that was impossible though.
ornornor 4y ago
I’m sick and tired of the way software is nuit and how developers are almost always at the bottom of the food chain. We have to accept pressure from the whole org and deliver on things promises to others regardless of reality. I would like to break the cycle and end my fellow developers’ misery by helping willing teams and orgs work better. How could I do this? How is it called? I certainly don’t want to be another Agile(tm) peddler. But I also can’t go back to being a code monkey. And before people here reply that I have to find better orgs to work at: while I believe they exist, they’re so rare that this isn’t possible for 99% of people. In my over 10 years in software, I have never interviewed with or worked at one of these elusive better orgs. I’m also not in the US which might be a factor. Anyway, I’d rather have a different solution to this problem than “work somewhere exceptionally hard to find”
- bladelessninja2 4y ago
  I'm surprised, I've never had problems with org pressure, it was easy for me: either we do agile and you trust our judgement or I quit, because I know that this project will fail and I'm not interested in contributing to projects that are doomed to fail. Do you think I was unemployed for long in the second case?
sys_64738 4y ago
It exists to give management and PMs control of development again. Without it they can't control what developers do. It might be OK for web development but for most other areas it's a disaster.
Ingaz 4y ago
There was nothing wrong in SCRUM originally. When it appeared it was a breath of fresh air: minimal, explainable in 5 minutes, just accumulation of common sense. You don't even need to declare "We're working in SCRUM" - the important feature is possibility to do "SCRUM in stealth". SCRUM went wrong when it became "process", when SCRUM masters/evangelists appeared. They started to teach "right SCRUM practices" and SCRUM became a bureaucratic ritual not distinguishable from RUP.
end_of_line 4y ago
One big point which hasn't been resolved by scrum in many companies. Manual testing - until it's tested by the QA tested you shouldn't mark it done. However, it is very seldom to finish testing and implementing in one take in exactly 2 weeks. Also business analysts, together with QA testers there is virtually no control in most companies what they do and how they do. All the blame is shifted always on developers because they are at the bottom of SDLC chain but business analysts and QA testers take never responsibility for all inaccuracies and omissions of their work.
codaphiliac 4y ago
Rally a team around a single goal, get out of the way and let them move fast. If you don't trust your people, you have bigger problems that no methodologies will fix.
hakfoo 4y ago
My firm is making a big deal of "We're going agile/scrum" as of the start of the year. I'm not sure I quite understand how it makes sense. From my personal perspective, the sprint model is an okay idea if you're working greenfield, or at least in full control of your deliverables. I'm wondering how it fits into any sort of dev process where third parties are involved. For the same conceptual change, some will be "send us an email with the ID from the test API call you made, and we'll tell you if it looks right" taking a few hours. Others will demand a huge stack of formal test cases, weekly meetings, and a cycle time of two weeks to even get back what they didn't like about your test requests. How do you possibly slice that into two week intervals?
- Viliam1234 4y ago
  If you can't do the sprint planning - if you can't decide on the list of things that need to get done during the next two or three weeks - then you obviously can't have scrum. So it probably means that you will have daily meetings and jira tickets...
bitwize 4y ago
Scrum wasn't implemented in Scrum shops for the developers. It was implemented for the executives, so that they have constant visibility into, and control over, all phases of the SDLC.

111 points by ghuntley 4y ago

This thread is all problems a no solutions. I also don't like traditional scrum and meaningless ceremonies but there is value in some of the methodology. There is one thing in particular that no one here is addressing. Underperforming developers. Every comment assumes that all developers are fully equipped to excel if management would just get out of their way. Um, no. I've seen extremely knowledgeable and talented developers who, left to their own devices, fail miserably. You "empower" them to do amazing thing and set them up for success and they get almost nothing done. If there's no one holding them accountable, they just coast. The truth is that some people and teams need the extreme rigidity and process that comes with scrum or they will simply not ship. Other teams will die in a fiery explosion or wither quietly into attrition if you force process on them. The best you can do is set a foundation and course-correct as the team succeeds or fails. You might end up with very little meetings or 2x scrum ceremonies. Whatever it takes for the team to be productive and happy. There is no "One Process to rule them all" and leaving developers total freedom to do whatever they want is definitely NOT the answer. The best process for a team will likely change over time due to many factors like company stage, # of members, their experience levels, their commitment levels, their personalities, etc... The job of a manager is to tailor the team's process to what achieves both the business goals and keeps people happy. It's a difficult and thankless job which few do well.

s1k3 4y ago
Poor performing developers cannot be fixed with a process. This is a management problem. It’s up to the developers manager to properly motivate and course correct flagging devs. Trying to push off HR problems on a software delivery process is the most dev take I’ve ever heard.
- shagymoe 4y ago
  You're missing the point. Some people NEED daily standups and some people will literally quit if they have to do it. That's process. It becomes more difficult when those two individuals are on the same team and then you have to micro-manage the the under-performer who can't be trusted to give accurate updates and make progress. Sure, managers need to motivate and course correct when necessary but process can help with that.

deleted 4y ago

[deleted]

WheelsAtLarge 4y ago

Fine, scrum sucks! I agree. What's the alternative?

rawgabbit 4y ago
We can start by recognizing that scrum and agile cannot replace actual development talent. When companies throw additional scrum masters and project managers into a failing project, the project only fails faster. People first, tools second, and then process.
- pempem 4y ago
  ^ this is agile. at least "people first" - then its process and tools. Tools are last, because there are always new tools and the way you do something should be somewhat consistent within a team/org even if the tools aren't While scrum/agile does not = more developers, it can be leveraged to actually grow a developer's career and skills when done well.
  - rawgabbit 4y ago
    As a technophile, I always disagree with that sentiment. Michelangelo cannot sculpt the Pieta with a sledgehammer and sticks. These days we need highly specialized tools to do our work. These highly specialized tools require specialized developers. The only alternative to this is low code/no code tools. Low code/no code is great for green field projects, as you can ensure a steady pipeline of such developers.
    - pempem 4y ago
      oh my. In a world of continously created saas pursuing bits of walletshare and department budgets endlessly I would say there is a small % of tools that are specialized and uniquely required. There's also a TON of tools that are preference based selection. Michelangelo sculpted with one set of tools and painted with another. Klimt may have had some overlap with one and none with the other set. Neither was being doggedly pursued by salespeople or having decisions about tools made by their bosses. IMO: Its not an apt metaphor in the slightest.

drewcon 4y ago

Honestly. Software at Big Co is more like building a house. If you’re in a high uncertainty environment with loads of market risk, by all means Agile away. But if you’re designing and developing something fairly well understood… something more oriented towards a better understanding up front with bigger customer delivery increments is completely fine.

prpl 4y ago
Architects, permits, contractors, hazmat anbatement, inspectors, etc…?
- Gravityloss 4y ago
  As a person who has not actually built a house but has done some renovation and designed and built some temporary structures, the amount of unexpected things coming up is surprisingly similar to software development! I have a large amount of respect to people who have built a house. And even more for those who have built a bridge or a skyscraper.
Lio 4y ago
> But if you’re designing and developing something fairly well understood… There in lies the problem; building software is not like building a house. I've seen many projects at Big Co fail to deliver on time, budget or quality because senior managers believed that everything is "fairly well understood" up front when just wasn't true. That mistake leads to treating estimates as concrete delivery times, scaling the development team before it's ready and a refusal to fix things that hurt productivity because they're not on the unchangeable timeline. The author is correct Scrum is usually sabotaged by outside influences trying to turn it into waterfall. If IBM couldn't make waterfall work in the 1970s it's very unlikely that will work anyone's big project today either.
mmcnl 4y ago
Fairly well understood and "Big Co" don't really go together.

patothon 4y ago

I don't understand why we're still talking about SCRUM. People saying they're using SCRUM (by this I mean "literally saying 'SCRUM'") are a dying breed and if they're not then they're cargo culting and I'm not sure why this is more of a big news than management cargo culting waterfall or kanban. I used to be one of these process experts selling methodologies to whoever was ready to pay, from SCRUM to lean startup. After doing this full time for 2 years the only conclusion is that none of these processes hold long enough. Why? 1/ every product / team / output is different. some teams should be ticket driven, other exploratory driven, and each of these methodologies apply to one situation only 2/ high turnover in the industry. meaning that new people come and organically change the new flavor of the day, the dynamic of the teams and the throughput of the team 3/ all of the best teams I've worked in the industry (from seed stage to FAANG through late stage startups, and even F50 companies), just do WHATEVER that works for them and don't comply with the flavor of the day (except for the looks of it). They all use a shared core set of values (deserves it's own blog post), and you can find this core set of values in most agile methodologies, buried behind ritualistic behaviors anyway. I could go on. Just let it go, and if you're working in one of these last companies applying SCRUM unironically, you're probably not in a high performing team. Time to move

deleted 4y ago
[deleted]
siva7 4y ago
So you sold methodologies to companies as a process expert and none of them ever hold up? Maybe you reached the wrong conclusion after all.
- scott_w 4y ago
  Honestly, this isn’t surprising. Typically external process change struggles to take root because the person isn’t there long enough to really understand the team, the problems, the culture, etc. I don’t think this is the consultant’s fault, either. Usually the company doesn’t want to pay the money or time to do this.

ramesh31 4y ago

Anything that gets between what me, the designer, and the PM want to do needs to go. There’s an entire industry of bullshit around framing and tracking that fundamental working unit which actually builds software. Project managers, Scrum masters, whatever. If you really need acountability to the bean counters, let them define their own KPIs and give me and the PM an interface to them. Anything else is a total waste of time and effort.

drewcon 4y ago
- SgtBastard 4y ago
  This comment is beneath HN. AMZN (amongst numerous other household name brands) ships world class products with 2-pizza teams where a dev, a designer and a product manager are having the conversations that need to be had to ship. Do better.

vegetablepotpie 4y ago

I completely agree with the author, it’s the environment. Scrum was intended to empower developers by allowing them control over when new work got scheduled. In reality it has been used by management to export their responsibilities onto developers while not ceding control. With scrum, planning and estimation are now done by developers. But management still reserves the right to reschedule mid-sprint for the all so urgent pop ups they need handled. The only thing developers can do to make scrum work is be completely devoted to the process and not the business, but that is a career limiting move; scrum masters are put in positions to either be ineffective or be ablative armor for their teams.

NAHWheatCracker 4y ago

I've never been in an environment where Scrum was used to create real pressure. I've been in environments where it creates fake pressure. Standups where you have to say something for fear that you'll be axed if you say nothing. Questions about whether a ticket is going to get done by Friday. I call these fake pressure because it becomes obvious that there is no teeth to them. People get away with doing nothing and making up a few sentences at standup. People say a ticket is going to be done, but it roles over through two or three sprints. It's always been a sham for me. You can't point at the Agile Manifesto and say that we're focused on process over interactions. You can't point out that we need a Product Owner who is focused communicating the needs of real users. You can't point out that standups should be for the team's benefit and not status updates to project managers who are barely involved. Still, I'm a firm believer that the Agile Manifesto makes some good points. I believe that there are elements of Scrum that are really beneficial if implement well. I believe all of it is subverted by management that wants a semblance of control/power. Most of the workers don't care whether it's subverted, they're just there to be paid while doing as little work as possible. So, who's left to change it? A few righteous agitators? Who are they going to agitate? The managers who have control aren't going to give up the reins. The hoi polloi will ignore anything that takes extra effort. Saying the scrum master needs to be accountable is true. Everyone should be accountable for something. However, there's simply no way for that to happen in many environments. I've had scrum masters that were basically just required to gather status updates and report them back to the CTO. I've had contractor scrum masters that were hired because Scrum said they had to have that role but they ignored the part of Scrum that said there was a product owner role. I've had scrum masters that were just engineering managers who ignored their engineering manager roles to be the one who screen shared the Jira during standups, including one who was a Director of Engineering. All of those scrum masters were installed by the people in power not to be held accountable for anything. Most of those scrum masters, like all the other workers, just want to get by with doing as little as possible while being paid.

icedchai 4y ago
I worked at a place that ran sham sprints all the time. If you couldn’t finish something, your ticket would get marked complete, and a new one opened to finish the work (“integrate [component]”) next sprint. This was so the points would be booked and the team stats wouldn’t look bad. I saw one ticket roll over for a good 2 or 3 months like this.

jboy55 4y ago

I think the blog mentions this, and I'm glad its not just another complaint listing the failings of Scrum as it exists at an unnamed company. But I would put forth that no process can save developers from pathological management with poorly conceived products and even not "having a process" will help. As long as NPD* continues to be a great indicator of success in gathering VC funding and upper management success, developers will be exposed to horrific work environments. These environments will be label 'Agile', 'Extreme' or whatever label can attract talent. No manner of 'Process X sucks' blog posts will change this. If the Hacker-News Scrum hating community comes up with a "better named process", or a successful manifesto advocating the 'end of processes', organizations led by sociopathic management will quickly adapt these slogans and then distort the environment to their likings. If management is beating you with sticks because you missed getting your story points done by end of sprint, the problem isn't a process that measures stories by points, and has biweekly sprints where velocity can be measured; its having management that is willing to beat developers with sticks. * Narcistic Personality Disorder

studifi 4y ago

Scrum is not for developers, it’s for anxious leaders.

jacknews 4y ago
Yes it can be, a way for teams to self-document their failings etc, and allow management to 'inspect' everything with little effort. If it really worked, managers would also be subject to it.
Haga 4y ago

fatneckbeardz 4y ago

why do i feel most of whats good about "agile" was actually already being done in the open source world before Agile was even a thing?

JohnFen 4y ago
Because it was. "Waterfall", as described by agile evangelists, was a very rare practice. Good shops had a process that already incorporated most of the best features of agile.

KingOfCoders 4y ago

We should have stayed with XP.

tempodox 4y ago
XP is maybe the purest example of the basic problem. If you're good enough to actually practice XP, you don't need a methodology at all. You'll do the right thing in each situation. Methodologies are for those who aren't good enough. And apparently they always find a way to pervert it into its opposite, because people never get tired of exerting power and maintaining an illusion of control.
- KingOfCoders 4y ago
  Yes, if everyone is good you don't need processes. I do think Scrum took off because it is the opposite of XP, it doesn't tell developers any development practices (Pair programming etc.) so developers didn't feel bullied and said "Yeah, ok, lets do your Scrum". But it backfired.

twelve40 4y ago

Yeah I had to suffer through the full-blown training from a "Senior Agile Coach" like the author - taken extremely seriously by the management at the time, so I can see how a bunch of people who took this stuff literally - including the "coaches" - are a bit heartbroken now. My employer who ordered that expensive training collapsed several months after that. But, trying to distill all the formalistic nonsense into usable points, they actually do have a few. My personal takeaways: - try to ship faster (try daily for a webapp), but do what feels right for you - have some task board and scrub it regularly (once every week or two, whatever) - learn to use ballpark estimates (1 hour, 1 day, 1 week - or whatever else floats your boat. Fibonacci, none of this stuff will ever be realistic - just get the order of magnitude) - have short meetings about blockers, but schedule stuff for later the moment someone starts banging on for too long - yeah, and try to break stuff down into smaller, more manageable pieces, the spec, the PR's, pretty much everything No idea if this is "SCRUM" or not, but this has worked for me so far...

praptak 4y ago
That could also be kanban. Which is actually great - it means that what you described is a set of tools, which can be used for whatever purpose the team decides. That's agile, as opposed to forcing a process on the team.
- blub 4y ago
  It’s not Kanban, because that revolves around minimizing work in process, balancing ins and outs at each step of the process and making work visible.
mmcnl 4y ago
Yeah that's very much like scrum.
voxl 4y ago
Using estimates has not and never will be a useful idea. You are in one of two worlds, either your work is predictable and easy to estimate, in which case you could just count the number of tasks/stories and get a sufficient estimate anyway, or your work is very unpredictable in which case your estimates are a lie.

tjpnz 4y ago

I've seen it work well when practised by small, mature and highly independent teams. Where things start to fall apart is when management gets interested or heaven forbid, the company decides to spin off its own bastardized version of the process (often by bolting on the worst aspects of waterfall).

xedrac 4y ago

Scrum is the bane of my existence as a developer. It sucks all creativity and enjoyment out of software development, and replaces it with anxiety, shame and mountains of tech debt. And don't get me started on the velocity metric that so many managers can't seem to live without (see Goodheart's Law). For whatever reason, I'm 10x more productive when I have the autonomy to bounce ideas off my team and proceed in the best way I see fit.

bladelessninja2 4y ago
Just like there are companies who say they are Agile, but they are not, there are teams who think they have Scrum, but it is not Scrum. If you say that Scrum encourages tech debt and you had no autonomy then probably it wasn't Scrum. The other option is that you were using Scrum where it doesn't fit. By Pareto principle: 80% of times when I see "The tool X sucks" it is because people are using wrong tool or they are using tool wrong.
- pydry 4y ago
  I was told this once by a scrum trainer when I told him it sucked. I then challenged him to figure out which part we were doing wrong. He couldn't coz we pretty much did it to the letter - following the directives from another scrum trainer. I call it the no true scrumsman fallacy. Doing it "properly" means doing a series of mini waterfalls. Thats just how it was designed. I'd say it functions as a poor but semi functioning compromise between an intransigent waterfall management and an agile team.
- xedrac 4y ago
  We can debate the purity of scrum, but in practice, every company I've worked for has modified it to suit management desires, and those modifications have almost always been to the detriment of developers. For example, the "complexity" of a story is inevitably interpreted as "time". And the end of every sprint is often turned into a deadline that leads to tech debt. Creative development is not always a linear process, which scrum somewhat enforces. I think it could work if every story was treated as a spike, and every spike could be pre-empted by new spikes as you discover new things. If it was able to truly flow the same way software devs actually think and work, then it could work. The result of a spike could be a finished work, or perhaps many other spikes. This would model creative development better. But companies don't go for this because they cannot easily estimate time and schedules.

dc_ist 4y ago

Ashamed to admit I was once a Certified ScrumMaster. I’ve grown to realize that it’s too difficult to implement. The gains, if any, aren’t worth the effort and overhead. As the agile manifesto says: “Individuals and interactions over processes and tools”.

ggm 4y ago

What does NASA do to develop new code for Mars? What do people writing realtime flight control systems do? What do quants writing investment strategy code do? Do they all do the same thing? Would they call their process a ritualised behaviour?

pjmlp 4y ago
Basically high integrity computing processes, very waterfall like, and with quality process verification that most companies will only ever adopt when liability becomes a common legal requirement in software delivery.
twelve40 4y ago
It'd be nice to summon someone from that side of things, but I'd venture to say it's just built really differently. Like, how a bursting bathroom pipe in an apartment is different from the same purpose plumbing on SpaceX. Humans actually keep building both, somehow.

plaguepilled 4y ago

I would like to propose a different perspective in Scrum and Agile: they're really actually reasonably good. Or rather, they do go wrong, but they go wrong for reasons outside of the scope that a development process considers. Instead, I argue the issue is related more with the way that managers and employees interact, and the expectations they both bring to the table. More explicitly, I am arguing that if the development process changed at a company with a manager running agile processes, the manager won't necessarily suck less if they were already bad. Likewise to the employee. My suggested action is to treat this as a question around social environment, and tweak accordingly. This would be different for each company I would expect.

MattPalmer1086 4y ago
I had great success using scrum in central government. It freed us from the whole "get a document approved by lots of external parties before you can do anything" mentality. . It helped that because it was such a different process, they largely left us alone. They loved the regular retrospectives. They were awed to see feedback from the previous retrospective made real by the next one. By the end we delivered more for less and it actually did what the stakeholders cared about (not what people thought they wanted when we started and didn't understand it).
bladelessninja2 4y ago
Exactly. I saw employees who said they have Agile implemented, but for example they were too weak to speak up, take responsibility and pursuit technical excellence. Same with managers: they say they are Agile, but trusting your employees that they will get the job done was a joke to them.

pjmlp 4y ago

Having gone through all the management fads for the last 30 years, Scrum in practice might not be agile, but it is definitely better than any other alternative in big corporations. I for one am glad that there are Scrum masters and POs to deal with all the politics and project nonsense that I don't have any interest in being part of.

mrjin 4y ago

Have been using scrum/agile for over a decade now. To most of the companies if not all I worked for, agile/scrum was nothing but just a fancy buzz word to the management team. They just did what they were already doing under the name of agile. Put all that aside, scrum/agile is actually pretty good on tracking small and simple tasks. So if the whole project can be broken down to nice and small tasks and the estimates were accurate, agile/scrum will work perfectly. Unfortunately all the project I've ever involved were complicated, some were even super large. We humans are pretty bad at estimating and no surprise most estimations were way off. Also, there were huge tasks that could not be broken down. That's exactly where the short coming of scrum/agile. Also, in most projects there were for sure huge, hard and important tasks that needed to be solved as soon as possible. But in scrum/agile, the team tends to pick the small, simple and easy tasks first as it would make the metrics nicer. So when they finally have to pick those important hard and huge tasks, it would be most likely way too late as there were already too much done in the wrong way.

pydry 4y ago
>Also, there were huge tasks that could not be broken down. I've come across tasks that were difficult to break down and required a bit of creativity. Never come across one that was impossible though.

ornornor 4y ago

I’m sick and tired of the way software is nuit and how developers are almost always at the bottom of the food chain. We have to accept pressure from the whole org and deliver on things promises to others regardless of reality. I would like to break the cycle and end my fellow developers’ misery by helping willing teams and orgs work better. How could I do this? How is it called? I certainly don’t want to be another Agile(tm) peddler. But I also can’t go back to being a code monkey. And before people here reply that I have to find better orgs to work at: while I believe they exist, they’re so rare that this isn’t possible for 99% of people. In my over 10 years in software, I have never interviewed with or worked at one of these elusive better orgs. I’m also not in the US which might be a factor. Anyway, I’d rather have a different solution to this problem than “work somewhere exceptionally hard to find”

bladelessninja2 4y ago
I'm surprised, I've never had problems with org pressure, it was easy for me: either we do agile and you trust our judgement or I quit, because I know that this project will fail and I'm not interested in contributing to projects that are doomed to fail. Do you think I was unemployed for long in the second case?

sys_64738 4y ago

It exists to give management and PMs control of development again. Without it they can't control what developers do. It might be OK for web development but for most other areas it's a disaster.

Ingaz 4y ago

There was nothing wrong in SCRUM originally. When it appeared it was a breath of fresh air: minimal, explainable in 5 minutes, just accumulation of common sense. You don't even need to declare "We're working in SCRUM" - the important feature is possibility to do "SCRUM in stealth". SCRUM went wrong when it became "process", when SCRUM masters/evangelists appeared. They started to teach "right SCRUM practices" and SCRUM became a bureaucratic ritual not distinguishable from RUP.

end_of_line 4y ago

One big point which hasn't been resolved by scrum in many companies. Manual testing - until it's tested by the QA tested you shouldn't mark it done. However, it is very seldom to finish testing and implementing in one take in exactly 2 weeks. Also business analysts, together with QA testers there is virtually no control in most companies what they do and how they do. All the blame is shifted always on developers because they are at the bottom of SDLC chain but business analysts and QA testers take never responsibility for all inaccuracies and omissions of their work.

codaphiliac 4y ago

Rally a team around a single goal, get out of the way and let them move fast. If you don't trust your people, you have bigger problems that no methodologies will fix.

hakfoo 4y ago

My firm is making a big deal of "We're going agile/scrum" as of the start of the year. I'm not sure I quite understand how it makes sense. From my personal perspective, the sprint model is an okay idea if you're working greenfield, or at least in full control of your deliverables. I'm wondering how it fits into any sort of dev process where third parties are involved. For the same conceptual change, some will be "send us an email with the ID from the test API call you made, and we'll tell you if it looks right" taking a few hours. Others will demand a huge stack of formal test cases, weekly meetings, and a cycle time of two weeks to even get back what they didn't like about your test requests. How do you possibly slice that into two week intervals?

Viliam1234 4y ago
If you can't do the sprint planning - if you can't decide on the list of things that need to get done during the next two or three weeks - then you obviously can't have scrum. So it probably means that you will have daily meetings and jira tickets...

bitwize 4y ago

Scrum wasn't implemented in Scrum shops for the developers. It was implemented for the executives, so that they have constant visibility into, and control over, all phases of the SDLC.