I don't understand why we're still talking about SCRUM.<p>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.<p>I used to be one of these process experts selling methodologies to whoever was ready to pay, from SCRUM to lean startup.<p>After doing this full time for 2 years the only conclusion is that none of these processes hold long enough. Why?<p>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<p>anyway. I could go on.<p>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
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.<p>But, trying to distill all the formalistic nonsense into usable points, they actually do have a few. My personal takeaways:<p>- try to ship faster (try daily for a webapp), but do what feels right for you<p>- have some task board and scrub it regularly (once every week or two, whatever)<p>- 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)<p>- have short meetings about blockers, but schedule stuff for later the moment someone starts banging on for too long<p>- yeah, and try to break stuff down into smaller, more manageable pieces, the spec, the PR's, pretty much everything<p>No idea if this is "SCRUM" or not, but this has worked for me so far...
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.
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.<p>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.
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.<p>In reality it has been used by management to export their responsibilities onto developers while not ceding control.<p>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.<p>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.
There was nothing wrong in SCRUM originally.<p>When it appeared it was a breath of fresh air: minimal, explainable in 5 minutes, just accumulation of common sense.<p>You don't even need to declare "We're working in SCRUM" - the important feature is possibility to do "SCRUM in stealth".<p>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.
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”.
Honestly. Software at Big Co is more like building a house.<p>If you’re in a high uncertainty environment with loads of market risk, by all means Agile away.<p>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.
I would like to propose a different perspective in Scrum and Agile: they're really actually reasonably good.<p>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.<p>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.<p>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.
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.<p>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.<p>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.<p>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.
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.
What does NASA do to develop new code for Mars?<p>What do people writing realtime flight control systems do?<p>What do quants writing investment strategy code do?<p>Do they all do the same thing? Would they call their process a ritualised behaviour?
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.<p>I would like to break the cycle and end my fellow developers’ misery by helping willing teams and orgs work better.<p>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.<p>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”
My firm is making a big deal of "We're going agile/scrum" as of the start of the year.<p>I'm not sure I quite understand how it makes sense.<p>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.<p>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?
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.
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.
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.<p>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.<p>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.<p>* Narcistic Personality Disorder
I've never been in an environment where Scrum was used to create real pressure.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
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).
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.
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.<p>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.
Scrum wasn't implemented in Scrum shops <i>for</i> the developers. It was implemented for the executives, so that they have constant visibility into, and control over, all phases of the SDLC.