"When you finish a task, you simply pull the next one from the top of the backlog”
Please, no. When you've finished a task see if you can help with a blocked or in-flight task.
Teams win points for finishing work, not starting new work.
> Please, no. When you've finished a task see if you can help with a blocked or in-flight task.
This is the kind of thing that should pop up in dailies.
But Jira only prominently shows the final owner /s
A lot of problems get solved by talking to each other and bouncing ideas. Don’t underestimate the power of rubberducking.
Probably the biggest disservice done by Scrum was changing our thinking and language around methodology. It made it so that if something was going to displace it, it had to start with a capital letter, be a "real" version of something, and have a lot of institutional momentum behind it. It acted like some kind of social exploit--one we had no immunity to.
So, we ended up stuck with it, suffering untold millions of hours wasted in useless meetings and untold creativity crushed since it didn't fit into the process. We should've just tossed the notion that there's some kind of planning structure that makes sense across all possible projects, then done whatever made sense for our specific environments, not put a name on it, or even talked about "methodology" much at all.
This was Scrum's greatest hack - the whole idea of a prescriptive methodology is anathema to agility. As soon as a process solidifies, all exploitable niches will be exploited to the detriment of the system itself.
I don't get how endless meetings are related to scrum. This is just poor management, which happened before scrum too.
Agile instead of agile, Scrum, Kanban, Scrumban, “shift left”, etc are all words that indicate the place has not only drank the kool aid but tried to drown any voices of reason with it.
All of these screeds ultimately come down to one thing: "I don't like being managed".
It's the height of arrogance to say these frameworks like scrum are popular purely because managers are morons hell bent on destroying productivity.
If you don't like it, you've options. You can try get promoted to management and do a better job, but of course you don't like that - you'd rather burn countless hours playing with the next hottest framework. Or you can start your little LLC and go it alone, but of course you'll quickly find out what that's like as a programmer. Or you can spend all day programming unmanaged, on your own projects or open source - and find out the monetary value of that.
Where is the advocacy for the only tried and true method of organizing with your fellow coworkers and collectively bargaining together to better your work environment?
Why is the onus on a single individual to solve all the problems and not you know… as a cohesive group working together.
Telling people that if they don’t like it they should basically create their own company with their own methods is just unrealistic.
No, please tell us what that’s like as a programmer.
The subtext of the article seems basically to be that the author does not want to estimate tasks. Which is nice when someone else pays. It is less nice when you have to pay however.
Despite what they have told you, that's never a real issue. If the project is divided into small tasks, if progress is not being made on these tasks, the management always has the right to steer the direction of the project or to reassign the staff tasked to it. This is how management can continue to control the expenses. As for estimates, even an AI can give those, probably better than what a human can, and without any stress.
So if you would hire someone to redo your bathroom or kitchen, you would hire them without an estimate and quote as long as they divide the project into small tasks?
How often carpenter needs to study while constructing what is the correct method to build to wall, and while doing that, try to find out whether the client wanted the wall or a floor, or even both of them?
Try to give any proper estimations before actually starting that kind of project, when the scope is not known and there is no buy-in to spend half of the time just to plan all little details.
It is not just "give an estimation", but a whole procedure to complete.
If you don't know what you are going to do, of course you can't estimate. Then you timebox a research phase and let that outcome be the basis for the estimate.
That's not a fair comparison at all. A bathroom or kitchen is something they have worked on a hundred or more times before, with little variation. In contrast, software is almost always original. If you ask me to implement the same software a hundred times with minor variations, of course I can give you good estimates without stress.
THIS exactly is what Software “professionals” have amazingly successfully been able to convince everyone. That somehow what we do is “special” and we just cannot possible tell you how long XYZ is going to take… Software “is almost always original” is the same argument as if an incompetent carpetner would say “sorry, no two kitchens are alike and while I use same sh*t to build them I have never built yours exactly and hence I’ll send you the bill when I am done.”
Some changes to software are simple, but even simple changes can at times have unintended consequences, triggering the need for substantial refactoring or abstraction or performance tuning. It is all case by case, and it's not fully possible to fully predict what's needed ahead of time.
And carpenter never experiences surprises after he opens the walls and sees wiring from Civil War era, lead pipes, etc...? Surely that never happens
Scrum only gives an estimate for the next sprint and maybe the sprint after. In many cases you're talking about 4 weeks horizon at most. I would not be happy if a contractor told me they can only estimate the work on the kitchen, but not the bathroom.
I'm a big fan of estimating beyond two sprints, because the business' horizon is often a quarter or beyond that. Obviously initial estimates are very rough and uncertain, which you can show by using bandwidths. Then just keep updating the estimate depending on the work done, the requirements getting clearer and the technical challenges becoming known. It's a great tool to steer the scope conversation.
It also allows the engineering effort to be without day-to-day estimations. Just pick up the work that is most important and trust that people will put in their best effort.
If I'm hiring them without telling them in detail what I'd like them to do, yes. Try calling a contractor and asking "how much to redo my kitchen?"
In the real world I can demand an estimate because I'm giving them an architect's plan showing every dimension and material and the location of every counter, fitting, and electrical outlet.
You could call it a "specification document"...
> So if you would hire someone to redo your bathroom or kitchen, you would hire them without an estimate and quote as long as they divide the project into small tasks?
I love these general contractor analogies because it tells me that these people don't understand software engineering.
Here's an answer for you: the vast majority of software engineering is less like repetitive contracting and more like unpredictable lab experimentation.
It is up to management and business to decide if they are skilled and willing to accept the nature of software engineering.
"Here's an answer for you: the vast majority of software engineering is less like repetitive contracting and more like unpredictable lab experimentation."
I kind of doubt this, but have no numbers to back me up. Do you have any numbers or actual facts to support that statement?
> I kind of doubt this, but have no numbers to back me up. Do you have any numbers or actual facts to support that statement?
I don't have a measure of it but Google and Facebook did - and they found that estimation is BS and never achieved. They never institute scrum/kanban/agile nonsense as a result.
Without data, the constant and persistent failure to estimate projects - over 40 years - should be good enough data.
Yeah, the real world needs costs, estimates, timelines.
And you can help make them as good as possible.
I'm no fan of Scrum, but some of these alternatives are completely inaccurate/outdated.
Spotify stopped following the "Spotify model" barely a year or two after the famous video released. The Valve handbook is from over a decade ago and (from what I've read online) is no longer relevant (if it ever even realistically was).
Would have loved to see the author include a section on Extreme Programming.
Still my favorite.
This reads like someone which had bad management using effort estimates as hours and bugged the team about it. I'm saying that having seen plenty of environments where they do Scrum wrong.
> Because there are no sprints, you don’t have to worry about whether something fits into a sprint
I like fitting things into sprints. It forces tasks to be broken down into manageable items. If it's too big to fit, it's also probably ill-defined. Sometimes it goes over the sprint; it's alright; discuss during retro and learn from it.
> If an emergency arises, everyone pauses their work
You can still do that with Scrum. Scrum is a framework to estimate the effort and measure at fixed points in time. That's not an excuse to dismiss issues. Unless all of your work is unplanned, you can handle surprises AND estimate your leftover velocity.
I thought they debunked the "Spotify model" as something being promoted by a few consultants but also being phased out at the same time as being exposed to the public (nearly 10 years ago in 2014).
There are dozens of articles about the problems with matrix management that it introduced.
> Can you feel the energy of a software industry eager to break free from the low-trust environments we’ve grown used to?
I beg your pardon, but Scrum did not fail because "it does not work", it fails because low-trust environment won't make room for an agile mindset. An I really hate the term "agile mindset", because it is overused. But if you give people responsibility and accountability, you can get a powerful, creative environment. Which, in turn, means that you need less management. Interestingly enough, middle management is usually not happy about that - so Scrum fails.
This is a weird and unbalanced selection... I expected to see waterfall or some variation on here, but nothing like it, even though it is very common. Lots of mentions of evolving & fully-autonomous engineering structures without even mentioning how this interfaces with all the other parts of every company larger than a few people. Valve's approach is not really a methodology vs. a perk from generating ridiculous per head revenues for a pretty small company. Shape up can only work as described when your company is small and run by a benevolent dictator will complete control.
All these frameworks and still Common Sense reigns supreme yet rarely applied.
Common sense is not common. Common sense is more akin to wisdom.
Common sense is already here. It's just not evenly distributed.
I like how kanban and agile are "alternatives" as if they're not very similar to how scrum it's defined.