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.

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.

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.

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.

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.

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?

That can be hard -- many / some people would be worried it'd be impolite to leave and in a way say "the things you're talking about aren't interesting to me".

And they'll stay and feel frustrated, in silence.

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.

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.

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.

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

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.

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.

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 !

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.

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.

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.

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.

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.

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.

Why don't you work that in to your process. It's called Agile 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.

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.

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.

Still estimates are considered extremely important...

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.

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.

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.

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.

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

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!

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?

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).

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.

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.

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

This is the route to local maxima.

>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.

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.

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.

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.

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.

"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.

* utilize persons strong points

* reduce management

* reduce burden

* improve working environment

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"

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

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

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.

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.

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

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.