[js8]

We use Scrum at work and I have to say, I am pretty annoyed by it. I think it is fundamentally rooted in the idea that ideal software development is just a continuous production of small improvements to the code. And from this come all its micromanagement failure modes (which there are plenty).

I think in reality, SW development done right is nothing like that. It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time. It's more like mathematics, where it takes time to discover that things are actually rather easy (this quote comes to mind https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-d...).

Of course, if you look at the project from the longer time perspective, it can appear as continuous production of improvements. But it has a kind of quantum nature, if you decrease the scale of time, you will see less continuity and more discrete bursts of code production. There is something like uncertainty principle that on certain scale, it's pointless to try to predict things, because making the correct prediction (which is needed at least to define thing DONE) will take as long as doing the thing in the first place.

I don't consider myself special, but it is possible that Scrum ruins great minds because they seek conceptual clarity (we sometimes humbly call it "lack of technical debt"). I am not sure how to make that work with Scrum. Perhaps if everything was done three times, punctuated by a team discussion, each time with shorter code.

Second thing that I dislike the most about Scrum is that it threw away (or at least "conveniently" renamed) pretty much everything that was ever known about project management. Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss. (I think it comes from the fact they actually realized the quantum nature of development is a problem.) To me, that is a huge red flag that it is, in fact, a snake oil.

P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.

[fxtentacle]

I remember we had a discussion about 10x developers a while ago and how some developers are perceived as moody divas.

My guess would be that the 10x-ers have are independent enough from any given employer that they can reject Scrum even if everyone else has to follow it. And later on, their ability to work on their own terms is what then makes them 10x more productive than the poor scrummers.

[js8]

I am definitely a "moody diva", I think because daily standup in particular forces me to admit more failures than I would have to otherwise (you need to fail before you succeed). And it's ultimately pointless and more stressing for everyone, because lot of these failures get resolved the next day.

In some sense, standup is a nocebo, a mood killer for me. I am there, in the morning, ready for work, my mind firing up, geared towards working the problem, but no, I have talk and listen about something unrelated. It's like going to a movie and having to suffer the trailers for other movies first.

(There was also this funny psychological research that showed that when you tell someone you will do something, you're less likely (less motivated) to do it. Not sure if true, but if it is then standups alone have caused billions of loses in productivity.)

In any case, I think the discussion about individual productivity is somewhat sidetracking the core issues. What I wrote applies to the whole team as well. In my experience, the best design decisions come from individuals working alone, understanding the problem, and then these design decisions are vetted (and possibly changed) by everyone in an open discussion. This cycle can happen on almost any timescale, depending on the nature of the problem. So one doesn't need to be in an ivory tower for this to work.

Timeboxing as such is not a bad idea. But I think conflating it with "being done" is just wrong.

[toomanybeersies]

Some standups, I feel like I'm back in primary school doing show and tell, as I get regaled with tales of whatever meeting someone had (even better when several people feel the need to bring up the meeting that literally the whole team attended), or their progress on a completely unrelated project/feature which may as well have been what they had for dinner last night, for all relevance it has to me.

They do have their benefits though, especially when well run. A team member may encounter something they're having difficulty with that another developer has encountered and solved in the past. You might want to share a problem you encountered or findings that are relevant to others.

I suppose that most of those things could just be done as a slack message. Sometimes I feel like a meeting helps ideas flow better though. There's been occasions where having an actual verbal conversation with the team has yielded better results than a slack conversation would've.

Either way, I've never had a huge issue with them, as long as standup is the start of my working day and not like 10 AM or something where I'm going to get interrupted.

[eindiran]

> A team member may encounter something they're having difficulty with that another developer has encountered and solved in the past. You might want to share a problem you encountered or findings that are relevant to others.

IME this has been the biggest boon of standups. If they are kept short, and further conversation is done outside the meeting, they are a good way of matching your problems to other people on your team who may have a solution.

> Sometimes I feel like a meeting helps ideas flow better though.

I generally prefer when protracted conversation/problem solving is taken up between the concerned parties after the meeting, as otherwise the meeting drags on for everyone else who doesn't really need to know about your particular issue. But I do definitely agree with your assessment that "actual verbal conversation[s]" are better for me with regard to figuring a problem out.

[irrational]

> and then these design decisions are vetted (and possibly changed) by everyone in an open discussion

But don’t you dare try to have an open discussion at a stand up meeting. The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it. Honestly, that just kills the flow of communication. I have never scheduled a separate meeting to continue the discussion. We just end standup, go back to our desks, and don’t talk to anyone.

[mindcrime]

The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it.

Have you considered that if this didn't happen, it would be one of your co-workers on this thread, instead of you, and they'd be complaining that:

"Our scrum standups are supposed to be 15 minutes long, but they always take an hour or more, because people start going down some rabbit hole that doesn't concern half the team, and the scrum master won't politely interrupt and ask them to schedule a separate meeting. So much time has been wasted by this that it's unbelievable."

I have never scheduled a separate meeting to continue the discussion.

Why not?

[username90]

If a useful discussion happens during a standup the people discussing can just leave and let the others continue the standup without them. There is no point in being strict with these things.

[mindcrime]

Agreed. I was just curious about why, specifically, the parent poster never schedules follow-ups. If the discussion in question was actually valuable, it seems like they would want to pick it up later (or use your approach of just forking off immediately. I look at those two things are being approximately equivalent).

[seer]

That sounds overly harsh. What we do in our team is "postpone" those discussions. When people have went through their updates, anyone who wants to stay is free to do so and can continue that discussion, usually in the same channel. This way you're not forcing people who _don't_ want to listen to that discussion to sit through it twiddling their thumbs - best of both worlds :).

[geochronology]

This. When I structured the standups for our own team, I budgeted 15 minutes for updates and 15 minutes for open conversation.

The result has worked almost exactly as intended: there's breathing room to discuss issues or ideas that come up in the course of conversation, but discipline around keeping those conversations brief enough to stay on the rails.

IMO at previous companies getting told "this isn't the time for that discussion" really frustrated me. As the OP stated, these conversations never happened, and it's healthier to allow some time and space for people to talk off-script when they're all meeting together.

[KSteffensen]

Would moving the standup to sometime where you are naturally interrupted, e.g. just before or after lunch, work better for you or is it the nature of the standup itself that's the problem?

[jariel]

1) Communicating is part of the job 2) Don't think about it in terms of 'failure'. You're just doing work. Sometimes the route is direct, sometimes it's not. 3) 'Time boxing' really has to be done, because products are not made in a vacuum. Time is money and it's a huge constraint. So everything really does have to be boxed up and parameterized by 'time' in the most reasonable means possible that doesn't screw everything up.

[brailsafe]

1) They were disputing scrums, not necessarily communication. 2) It's hard to not think of something as failure, if it's treated as failure, which is often the case. This is like telling someone who's being mistreated in a relationship to not think of it as abuse, just think of it as your way of life. 3) Time boxing may be important if a number of different types of schedule conflicts may arise, but I think it can place an undue importance on the measurability of how something gets done, often at the cost of it actually getting done well.

[jariel]

1) Scrums are literally communicating. 2) Just because someone feels there is a failure does not mean other people perceive it that way. If you describe it as a step towards the finish, then it is. 3) Time-boxing is inevitable. If there is a side-step due to some other issue, then you describe why the time boxes must be moved.

[WalterBright]

You just gotta trust that your top guys know what they're doing and let them do it.

It's how Lockheed let Kelly Johnson run the Skunkworks however he wanted to. Johnson delivered the impossible again and again, and Lockheed was smart enough to not interfere.

[ckastner]

I'm not entirely convinced that Johnson's example generalizes well. He might just represent an instance of survivorship bias.

Some people can be brilliant at something while at the same time being toxic, with the toxicity ultimately winning. Kalanick at Uber might be an example.

[WalterBright]

Lots of companies have tried to establish a skunkworks, but with "improvements". None have done particularly well. (The "improvements" were taking away the autonomy of the skunkworks.)

https://en.wikipedia.org/wiki/Skunkworks_project

[meheleventyone]

I've also seen it fail the other way where the Skunkworks becomes the preserve of "high achievers" not producing a lot that's useful. Almost every 'Office of the CTO' I've seen has suffered that failure mode. Lot's of things get built but none are more than fluffy experiments and there's no path to actually putting any of those things into production. Once in a while they'll be forced through and the production team has to spend a lot of effort fixing and making the project actually work.

[ricardobeat]

Isn't that just a lack of clear goals? Skunkworks had extremely ambitious deliverables and was not a science lab, even though they helped develop a lot of new technology.

[ckastner]

I'm not arguing against the autonomy part, on the contrary: I join you in arguing in favor of it, and also that such an autonomy requires a brilliant personality at the head of it.

However, while the combination of autonomy and brilliant personality might be a prerequisite of outstanding success, I'm not yet convinced that it's an overwhelming indicator of it. I believe that a brilliant but toxic personality with autonomy can lead to an ultimately fatal instability.

[C1sc0cat]

Which is not orthogonal from SCRUM done well

[toomanybeersies]

I definitely fit into the "moody diva 10x developer"

I've given up trying to estimate how long a task will take and more or less just pick an arbitrary (usually comfortably large) number of points.

The thing is, it isn't even about estimating the scope of work, which is often unknown until it's complete, especially if I'm battling technical debt. A given task might take me an afternoon on a good day, or half a week on a bad week. Case in point, I got more work done on Monday than all of last week. That's the joy of having ADHD I suppose.

At least my manager is very understanding, and recognises that on a macro scale I get a lot of high quality work done. I think that's the key to being a good manager, understanding that your subordinates have different working styles and managing them with that in mind. I'm sure there are "10x developers" out there who work in a more consistent manner, or benefit from more hands-on management than I do.

[rawoke083600]

>that ideal software development is just a continuous production

This ! Can't agree more... Scrum always made me feel like a production-line-worker making shoes... No craft nor space to discovery/explore problem solving. Urg and all those damn meetings and pulling numbers out of thin air ! What a waste of time those meetings were !

[xtracto]

One think I havent read being mentioned on this thread is how Scrum discrete sprint units allow the dev team to focus in a task for some time.

I have been in both "sides" of scrum (dev and manager) and it is good not to have objectives changed every days. As a manager I even have had to split a scrum team in two (scrum and kanban) to maintain devs sanity.

Kanban is my preferred PMing process but only if there are defined "cutout" periods to perform releases or a CI/CD cycle.

[MattGaiser]

> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason)

This has benefits and downsides. One of the one hand, the development team getting to control the estimate helps to control the workload.

On the other, I agree. Why are we pulling estimates of effort out of thin air? Why are we being asked how long it will take to do work in sections of code we have never seen?

Planning could be far more accurate if we just got a proposed task list a day before planning.

[tragic]

> Why are we being asked how long it will take to do work in sections of code we have never seen?

It is common enough for those packs of estimation cards to include one with a question mark on it, to denote the "I can't estimate this sight unseen" scenario. The reason it's common is because often people are presented with stuff that isn't well-understood enough, and it's a very good idea not to pull a number out of one's rear in those situations. Don't be afraid to use that card (or do the equivalent and just say so).

If you are afraid because you will be marked as 'not a team player' or whatever, you have management culture problems that neither Scrum nor any other imaginable software development process will fix on its own. They will all end up feeding an idiotic garbage in/garbage out cycle of overpromising, crunch, burnout and general misery, with the superficial appearance of whatever process it was supposed to be.

[js8]

> One of the one hand, the development team getting to control the estimate helps to control the workload.

I think that's a kind of waterfall strawman. In every other discipline, you would ask engineers for an estimate. It's insanity to do otherwise.

[MattGaiser]

> In every other discipline, you would ask engineers for an estimate. It's insanity to do otherwise.

I studied engineering in university and profs had plenty of stories about bosses sending business analysts to look at similar projects, generating a time estimate from those projects, and then send that estimate to the engineers as their deadline for completing the project.

It being insane doesn't stop people.

[Scarblac]

That's a pet peeve of mine. A perfect estimate is one without bias. It can't be without variance because there is always uncertainty involved in what needs to be done exactly.

So if you take an estimate and turn it into a deadline, in the perfect case, the deadlines can only be made 50% of the time.

Of course, in practice there is bias, there are things you forgot to include in the estimate.

[sergeykish]

It is to inform Product Owner. Quickly estimate with "trivial", "small", "medium", "big" and move on. Wrong estimate should not hurt. Managers are not allowed.

[jay_kyburz]

>Planning could be far more accurate if we just got a proposed task list a day before planning.

Why don't you work that in to your process. It's called Agile for a reason.

[js8]

Why don't they put it into Agile books? They're called books for a reason.

Snark aside, that's the difficulty. The fix for everything in Agile is - instead of adopting some sensible practice (that could actually have been discussed in academic literature), have an argument about this with your team members, maybe they will get it.

It's a return to medieval times, where all the expertise was just the experience of the master.

[Supermancho]

> Why don't they put it into Agile books? They're called books for a reason.

Agile books are hilarious because they are trying to not be prescriptive about process, while being prescriptive about process. Within that dichotomy, is the assertion that you can create your own process. So, in fact, it is usually in those books that you can make your lists for your team.

In the end, Agile/Scrum are a bunch of hand-waving rituals, which is close to what ends up happening within every software development team everywhere anyway.

[jay_kyburz]

I think the value of Agile is that everybody is different, and every problem posses unique challenges. You don't want to just follow some process in a book and expect it to work with your unique group of developers and designers, or for the unique problem you are trying to solve.

You could start with something suggested in a book. But you need to be ready to adjust your process when you identify when something is not working.

[mathw]

If you have no idea what the task list is before the planning meeting I'd say you definitely need to get your process changed. That's astonishing.

[Scarblac]

I want to add that the tasks we get at the planning meeting are just titles of tickets, nothing more. Working out all the details is the responsibility of the dev working on the ticket during the sprint.

Still estimates are considered extremely important...

[jasonbourne1901]

Scrum is being applied like a shiny new hammer to everything that might have seen or heard of nail a once.

The primary reason scrum should be used for software development is when iterating closely with a knowledgeable customer. The pattern basically outsources the discovery of what to build onto the customer - and if the customer can tell what good looks like, shazam! scrum is downright magical!

Guess what, most software teams are isolated from the customer, or the customer/product owner doesn't know what good looks like, so no wonder scrum is getting a bad name as teams struggle to get value out of scrum activities.

There is a reason why teams need to have flexibility to modify their R&D patterns and processes. Without that flexibility you get to do scrum and the results make you wonder if you are doing it wrong.

[C1sc0cat]

I think the obsession with tickets /Jira as the be all and end all of SCRUM is the main problem.

What is lacking in a lot of cases is an overall vison and plan for the desired end state -

I have seen doing a classic waterfall design stage with a RAD/AGILE/DSDM/SCRUM development stage right at the end work well.

[tragic]

> P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.

If somebody complains that Scrum is bad because e.g. every day you have to update management at stand-up (as mentioned in TFA), but the Scrum Guide, every book ever written on scrum, the websites of the Scrum Alliance and scrum.org, and more or less every advocate of scrum great and small, states explicitly that this is not the purpose of the stand-up but instead to highlight obstructions and opportunities for collaboration, then I don't see what more there is to say than "you're doing it wrong" - because you are doing it wrong, in letter and in spirit. It may not be your fault that you're doing it wrong (it's my guess that the widespread perception that scrum is management-heavy is a function of scrum's market penetration combined with the inherently dicatorial culture of corporate governance). But doing it wrong you most certainly are.

This is not one of your complaints of course, but you do complain about estimation, which - as a sibling comment mentions - is simply 'out of scope' for Scrum, which is a smaller package than people think. (Plenty of scrum thought-leadery types are part of the 'No Estimates' thing, for example.) It does, however, mandate that you occasionally meet for the explicit purpose of working out how to improve processes that are not working properly (such as estimation) - in other words, that the team takes seriously as a collective all the things that scrum does not talk about in itself.

[ricardobeat]

Despite what every book says, despite having three agile coaches run workshops with the team, despite this issue being specifically addressed with everyone involved, and being acknowledged as wrong, it still becomes the purpose of the standup.

No amount of "this is not the purpose of a standup" and "you're doing it wrong" can fix human nature. Management is mostly interested in progress and timelines, and will give unintentional (or not) feedback, even through body language, whenever a task is delayed or impacted in any way. They have some authority over team members' performance eval. Hence people will end up reporting to them no matter how hard you try. The only possible fix is to remove management or product from the standup, which is how it was originally supposed to be - but that seems unthinkable in the "agile at scale' format most companies have adopted today.

[cutemonster]

> it still becomes the purpose of the standup.

Also, the meetings are a bit useless for the developers -- they can just chat directly instead, and look in Trello/sth to see what the others are doing.

So the for oneself most meaningful thing to do, during the meetings, is to impress the managers / others listening?

Since the meetings barely hello with getting real work done anyway

[mindcrime]

inherently dicatorial culture of corporate governance

Exactly. There's no point in blaming scrum for problems that are ultimately rooted in your corporate culture.... because those problems are going to (re)-appear no matter what methodology you adopt!

[wirrbel]

> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason) are the biggest loss.

Curious about that point because for many engineering tasks the variance in the estimates is so big that I wonder whether any formal way of estimation actually works. I did some analyses on the correlation between estimate and actual development time in a project I worked in and the correlation wasn't really there. Sure, there was a difference for the very large work items and the very small one but overall the estimates were fairly useless, especially when it came to anything that touched operations. I just googled formal methods for estimation in order to see what you might mean by that and nothing appeared to be something I'd assume to be more powerful (a priori) due to my lack of confidence in workload estimation overall.

Note, btw. that the Scrum Guide doesn't make any mention of estimation at all, neither prescribes it nor disallows it, just says that the team should plan a sprint (roughly speaking). Even the typical "story point estimation" stuff that people think is attached with Scrum, its more of an XP practice that has been carried over.

Personally I think that Scrum took a weird turn in its lifetime with Sprints becoming shorter and shorter to the point where there can be no meaningful work (with customer benefit / demoable in the sprint review) be completed within a Scrum. Maybe its possible to ship a couple of CRUD-website-features within 2 weeks, but for the B2B software I am working on a feature is too complex for 2 week cycles. And if your tasks are small enough to fit into two week cycles, why aren't you doing Kanban?

[js8]

> I wonder whether any formal way of estimation actually works

I agree that it is a legitimate concern, I certainly do not advocate a position that software cannot be estimated or planned at all. I think it can be, but only up to certain time granularity, where the attempt to gain understanding for a sensible estimate (and describing what needs to be done) becomes essentially comparable to writing the code in the first place.

I actually have an underdeveloped idea how we could have a completely formal approach to tackle uncertainty in SW development, but it is purely theoretical so far (using a combination of functional programming and information theory).

[jay_kyburz]

>idea that ideal software development is just a continuous production of small improvements to the code.

Many of us do believe this. Absolutely.

>It is highly discrete when it comes to output, because it takes time and experimentation to come up with the correct way to approach a problem, but if you do it right, you save yourself an incredible amount of time.

But on the flip side, if you get it wrong you waste an incredible amount of time.

The smaller the steps you take, the smaller the risk you step in the wrong direction.

I can't really comment on the rest of your comment because as far as I'm aware SCRUM means something different everywhere. I have no idea, for example, why a scrum team would not use formal estimation methods and rely on intuition.

Agile project management should mean you can examine your process and improve it. If your intuitive estimates are not accurate, you should be able to suggest a different method and see if you get better estimates.

[js8]

> Many of us do believe this. Absolutely.

I think it is empirically not true, if you look at your Github history for example, sometimes you produce less change and sometimes a lot more. It corresponds to the fact (or at least a feeling) that some things are clear and can be easily done while some require some thinking or experimentation before they can be done.

And it's even less true if you restrict the requirement to only functional changes to the code (not just refactorings or productivity improvements or code reduction with preservation of the functionality). These things have to be mentally planned even more and that requires even longer periods of apparent inactivity.

> The smaller the steps you take, the smaller the risk you step in the wrong direction.

I don't think that's how it works. Risks are risks, whether you're taking small steps or not. If you don't know if your DB will break at 1000 users, it's a risk regardless how small steps you take to introduce the DB to your code.

Personally, I prefer to attack the biggest known risks first (for example, make prototype, measure it). But that flies in the face of other Scrum requirements, like getting some feature completely done in smaller chunks.

[aliante]

I am fine with the small improvements to code part, but I at least want an idea of where I am going. Small improvements to solve the problem? Sure. But I at least want an idea of what the entire problem is, not just the two weeks of problem shards I am given.

[jay_kyburz]

Absolutly agree, if you don't know where you are going, how can you possibly move towards it. At the end of every milestone its super important to take a step back and ask, are you on the write track.

If nobody can clearly tell you the end goal, your project management process is not the problem.

[sergeykish]

I have seen project made three turns based on users feedback until it found niche. SCRUM has not denied our vision but made it possible to continuously roll out to tighten feedback loop. Something else wrong in your case. In SCRUM you should be able to voice your concerns, to work with Product Owner.

[KSteffensen]

If Product Owner is not providing you with the bigger picture he is not doing his job. Product Owner should make sure the end result is crystal clear at all times.

[dogecoinbase]

> The smaller the steps you take, the smaller the risk you step in the wrong direction.

This is the route to local maxima.

[someguyorother]

>>idea that ideal software development is just a continuous production of small improvements to the code.

>Many of us do believe this. Absolutely.

Isn't Jeffries' attempt to do Sudoku with TDD pretty much the prime example that it's not always so?

Jeffries tried to write a Sudoku solver by starting from tests and incremental improvement, and got nowhere. Norvig knew about constraint propagation and did it in one go.

[jay_kyburz]

I'm not familiar with the story, but it sounds like he started with a solution, (the tests) and tried to find some code that would satisfy them. Perhaps Norvig started with the problem, then tried to find a solution.

[someguyorother]

As I understand it, TDD works by that you say what your problem is, find the smallest thing that will get you there, and then implement a test for it. The test will naturally fail, so you then write code to make it pass, and finally refactor. It's fundamentally iterative.

But Jeffries didn't know how to get to the solution, i.e. what mechanism to make use of to get the computer to automatically solve Sudokus. So he wrote a few tests for the obvious things (like I/O and data structure) and then got stuck.

In contrast, Norvig knew considerably more CS and so knew that the right way to implement a solver is to use constraint propagation. So he did so in about a screen of Python code, all at once, job done.

The lesson of the story, as I read it, is that you can't iterate yourself out of a problem if you don't know how to attack it. If you're making a symbolic calculus program to solve integrals, it's unlikely that you can start off by going "okay, the integral of x is 1/2 x^2..." and somehow, through a series of small steps, end up at the Risch algorithm.

Similar arguments could probably be made about design. The less CRUD-y your application is, the more careful thinking is required. You have to know enough about the domain to know where the pitfalls are, and what the proper tools are.

[mindcrime]

I think in reality, SW development done right is nothing like that.

I would argue that it's more correct to say something like "Not all software development done right is like that." Or in other words, some software development is closer to that model.

Some teams are doing work that involves real "invention", things that require using cutting edge C.S. research, implementing algorithms from papers, or using just-released open source libraries, etc. Other teams are building the nth iteration of some CRUD application that amounts to a database, some REST API's built using Spring Boot, and a UI built in React, where today's work isn't (usually) that different from yesteday's work.

Depending on which end of that spectrum your project falls on, it would make sense that the details of the methodology you use would need to vary.

I've also long thought that the details of your development methodology need to vary throughout the lifecycle of the project. Early on, there may be less clarity, and more "unknown unknowns", so it makes sense to focus more on experimentation and learning. Later on you (hopefully) start to converge towards a deep understanding of what you're doing, and can move more into the "gradual refinement" mode of work.

Unfortunately, I have found that few shops take either of these factors into account.

[dragonwriter]

> I've also long thought that the details of your development methodology need to vary throughout the lifecycle of the project. Early on, there may be less clarity, and more "unknown unknowns", so it makes sense to focus more on experimentation and learning. Later on you (hopefully) start to converge towards a deep understanding of what you're doing, and can move more into the "gradual refinement" mode of work.

I think this is basically true but incomplete; early and late are misleading a bit, because it can be early in the life of a product that is in a well-explored space and it will look “late”, while a product can experience change in requirements or external context which makes it look “early”. A product should expect to move between modes multiple times if it is long-lived.

[seer]

Maybe I've been lucky up to this point myself, a kind of survival bias or something, but a "lightened" version of Scrum has always made so much sense to me when it comes to developing software.

Our requirements change, they often change daily, from forces outside of our control. Fickle clients are one thing, but even things as predictable as implementing protocols can be uncertain. Many times you'll design and implement the perfect solution to the problem at hand, and then hit a nasty bug mid way of some tool / lib you're relying on that would make you rethink your whole approach. This can drive you into a rabbit whole in itself. Its always nice to consult with your team at that point to see if its actually worth it.

As far as I understand "Scrum" is just a collection of practices that helps us actually ship something in a reasonable amount of time. Each standup can be a "battle plan meets the enemy" kind of moment. And as we know, "no battle plan survives first contact with the enemy". Yes its uncomfortable sometimes, but it should force us to deal with reality a bit more often and I think that's a good thing.

And scrum and it mutations has survived to this day for a reason. Teams that employ it are much faster to adopt to changing conditions, and thus "outevlove" the competition. I really hope that we can codify a more humane way of dealing with those problems, but at its heart, I think scrum is better suited for software development than its predecessors. We need time (and willingness) to "evolve" it as well.

[greatgib]

I agree with this point of view. In my opinion, one of the greatest fallacy of Scrum and some agile methods is:

"Another note on breaking down tasks into chunks"

This is the management trick of "divide and conquer".

But for real good dev, that is not a good development process.

Imagine you are an experienced dev and you need to refactor a 20 files low level code to change the way errors are returned:

If you were in an agile/scrum setup, it would be asked to do that file by file, function by function, problem/code change type by type code change. And possibly not break the rest so that there is something 'runnable' at least every week or some other people can work on another file/function.

But that does not make any sense for a great dev. What you would do if you were experienced is to know the overall direction but rework the code line by line progressively, fixing side things on the way and maybe regularly fixing in other files/functions pattern that are similars. And maybe at some point decide to change again something you did until the point where you achieve your goal.

In my mind, it works more like a path searching algorithm in action.

The scrum concept is probably good for the devops/web script kiddy devs, where you just change hundreds of individual small items without too much interdependance. For example, change the style of button, reorder blocks on a page, change the icons, increase the font size.

Also, something that makes great dev become average is this concept that every dev should be exchangeable and a commodity. Dev become workers on a factory production line where they have no value than to follow process and apply patterns.

They say "what if something happen to your autonomous great dev?" but this argument is not used for the rest of the intellectual society: you don't see 2 doctors at a time, 2 lawyers for your case, 2 CEO in the company, 2 main architects. This thinking is just applied to low level replaceable workers.

Normally, if you lose a great dev and you find another great dev, the new one should be able to understand the problem and the code in a short time and be operational quite fast.

One example we can easily see of efficient dev are the great open source projects. Most of them were not created and led by an army of dev clones but by a few efficient ones: linux, python, php ... In these cases, most of the time we don't consider people to be interchangeable. Some people are keys to topics/code/features and that leads to great dev. But in case of problem, there is almost always someone smart capable to take over after a short time.

[sergeykish]

You know you've described the opposite of agile approach, right? "management", "file by file, function by function", "exchangeable and a commodity"... at least not what agile was ten years ago. Actually the points in favor of agile were:

* utilize persons strong points

* reduce management

* reduce burden

* improve working environment

[greatgib]

I agree also with your point. The real agile as of the "Agile Manifesto" has the spirit of what is good dev in my previous message.

But was is used today as "agile", "agile in business", agile in real use, and especially Scrum is not what the Manifesto asked for, quite of the opposite in the end.

That is even why some of the creators of the agile manifesto backed off when they saw what it became.

In fact, at the moment a company or a people say "we will create an agile team here" (maybe with a specific process scrum/...), you know that it is failed. It should be like "we have experienced software engineers, we trust them to be autonomous and smart enough to do it how they individually want to be the most efficient/adequate. Also they have responsibility and their opinion is taken into account for business decisions"

[sergeykish]

I've seen it in work. It was very emotional when our Scrum Master left, we've got another one and he was great, but it has not felt same. This may be the biggest Scrum issue.

I've seen unreal Product Owner, it was so much pleasure to work with. Ever since I've found a joy in filling this niche if it was empty.

Yes, Agile Manifesto, Scrum is just some tools. It is like blaming axe [0] in Armenian cartoon.

[0] The Axe (1994), no speech https://www.youtube.com/watch?v=mA7H5KnyzJk

[greatgib]

As a follow up, nothing in the Agile Manifesto says that the process is important to ensure that a "developers" is not essential and can easily be replaced:

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

[sergeykish]

Agile builds on the premise that developers like to build. That we self organize our teams and don't like slackers. Bring transparency for business so it can trust us. Give estimates and accept priorities. Ship from time to time so all can see that process works.

It is really easy to screw. I've seen far to many broken versions. Community building is harder than management. And for management there is no benefit beside budge. So they say SCRUM and change nothing but cosmetics. It sells.

[etripe]

> Bring transparency for business so it can trust us.

The problem is no methodology can make them trust us. Software development is one of the few professions where to the business it's simultaneously "magic" and they think we - as experts - don't know what we're doing. Management is supposed to empower employees and remove obstacles, not disempower and introduce them.

At the same time, there's this illusion that as long as we developers change the way we operate, the rest of the enterprise will magically be affected. A cultural shift without management buy-in won't work.

[KSteffensen]

You'd think products shipped on time as agreed with the customer was a benefit for management.

[sergeykish]

I thought same. I fought for roll out in time, velocity and quality. Now I'm burned out. PM had his own agenda - introduced a men who, he was like 1/10x developer on senior position, promised to fire in a few month, have not happened in a year and a half, this destroyed velocity and as tech lead I was blamed. I stayed so long because our customers were awesome, could not leave them.

Managers are not friends. The moment I've said I'm leaving I become nothing. Time to learn.

[AnimalMuppet]

> P.S. I am tired of the YADIW excuse. Let's have a nice honest discussion about how it can be fixed.

Well, I think that Scrum (or, more widely, agile) can in fact be done "right" - done in a way that works well. So in one sense, "you aren't doing it right" is in fact a correct statement.

But then you look around, and you see how often it isn't done "right". If something is almost impossible to do "right", then yes, there may in fact be a problem.

[remontoire]

what does YADIW mean?

[usrusr]

"You are doing it wrong", the first and last thing any scrum believer will say to someone for whom it does not work.

[mindcrime]

And in a great many cases, when you dig into the details, it turns out that they are - in fact - doing it wrong. Or at least blaming scrum for things that scrum does not actually entail. Or blaming "agile" for things that are 100% contrary to both the letter and spirit of the agile manifesto.

[nnevala]

I think it stands for You Are Doing It Wrong.

[augustk]

YADIW = You Are Doing It Wrong.

[jariel]

This is a very good point, but often for established code bases, many things are just incremental. If the architecture is in place and well understood, especially if it's more of a business app ... then it's not Math ... it's more like Carpentry.