Scrum disempowers developers | Hacker News Reader

Scrum disempowers developers

lambdacambridge.com

332 pointsRobin_Message376 comments

Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sell books and consulting, so it evolved into a field of its own.

The fact that there is so much B.S. in Scrum doesn't mean that it has nothing of value to offer, though.

Here's what I get out of it:

1. Sprints are a better way to organize than Waterfalls. I've experienced this over and over again personally, so I'm sold on this.

2. It's important to stop what you're doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line.

3. Ship functional products as frequently as possible. This is better than waiting until everything is done, because you can get feedback early and often from the end user.

Okay, so that's 3 ideas. It's better than most.

You also missed the trade off's for increased speed compared to traditional wf projects.

One of the problems with the Scrum model is its used for every thing - just like they used to try and do every project with WF and IS9000/BS5750

Are you suggesting Waterfall projects are faster? I don't think you are, but that's how I read your sentence.

Also I don't know what IS9000 or BS5750 are but they sound like they had amazing naming committees.

Oh bum I meant ISO9000 BS5750 is the Uk equivalent (and I worked at my first job on a joint project with the BSI on BS5750)

But and its a big but some times you need the rigor a properly done waterfall process provides Air traffic control for example.

You seriously don't understand the trade offs you make with "agile" vs waterfall? I have done both very successfully.

Nope, don't understand the trade offs if you're suggesting scrum is slower than waterfall. That just doesn't line up with my experience. "Results may vary," though.

The issue I've had with every other project management approach is the illusion of structure. I'm not an expert on all or any approach. But my experience is that everyone wants me to be able to project, since absolute certainty, what my team can get done in 12, 24, 36 months. And I can't. No one can. It's all bull shiitake.

Scrum does not solve this problem. But it's honest about it.

It says: "We can't tell you what could be done in 2 years. But we can probably tell you fairly accurately what we can do in the next 2 weeks. And if you let us proceed in these honest 2 week intervals, we'll probably get way more done than if we all agreed to the collective insanity of the waterfall lie."

If you've done waterfall successfully, meaning you delivered a project on time, on budget, and on scope based on your original estimates for all three, then congratulations, you're a mythical beast.

I, for one, cannot do that. I've failed every time. Every team I've worked with has failed every time. I've never seen it work.

> Nope, don't understand the trade offs if you're suggesting scrum is slower than waterfall. That just doesn't line up with my experience. "Results may vary," though.

The idea is that if you have a well defined problem domain and you know exactly what the software is that you have to deliver, you don't need the short cycles, and all the meetings and pokering and whatnot would just be a waste of time. You know what you need to make, so you can just continue working.

I suppose that makes sense "if you have a well defined problem domain and you know exactly what the software is that you have to deliver".

I don't have a lot of experience in such areas though, and i can't help but wonder how often that's the case. If my problem domain was well defined, the problem would probably already be solved by someone and I'd use their code. Why reinvent? Am I being too simplistic?

> If my problem domain was well defined, the problem would probably already be solved by someone and I'd use their code.

Not necessarily. Look for example at the team that made the code for the central computers of the Space Shuttle. They knew exactly what their code had to do, how fast, etc et.

I don't think he was saying that waterfall is faster; I've never heard anyone say that. But WF is more rigorous and probably better suited for safety-critical software like avionics; the trade-off is that it lacks speed and flexibility.

The scrum manifesto is not overly verbose. It explains the value and concepts in a manor that does not lend itself to misrepresentation.

There is definatly a lot of companies peddling hype around scrum but it has a very lean and strong core which is in no way pulling in that direction.

What's the scrum manifesto?

Paraphrasing: The Agile Methodology is to argue about The Agile Methodology.

Source: Certified Scrum Master training. Three times. Still have no idea what these charlatans are talking about.

Which is a higher distinction, Scrum Master, Web Master, or Dungeon Master?

Dungeon Master. They're the only ones that can do something as simple as place an apple on a table, and tear apart your entire team.

Maybe they meant the Agile Manifesto? It’s short and hopefully not controversial: http://agilemanifesto.org

But... my eyes. They burn. Thank heavens for developer tools and the ability to delete backgrounds.

Jokes aside, good call linking that. Super short, super influential, super relevant to the conversation at hand.

> This does not sell books and consulting, so it evolved into a field of its own.

It's funny how it turned into UML

UML comes out of a different culture of development, that of the Rational software crew. They had their own much more heavyweight process than the Agile folks: RUP, or the Rational Unified Process: https://en.wikipedia.org/wiki/Rational_Software#UML_and_RUP

There was a little overlap; in particular, Martin Fowler wrote an intentionally thin book called "UML Distilled". But the UML world was generally heavy on both up-front architecture and formal, heavyweight design process. The Agile world at the time was energetically opposed to that, thinking that the main value of UML was in having a consistent language for us to all sketch on whiteboards together.

Too bad people didn't bother reading the Unified Process book, which clearly specifies the use of iterative and incremental development and the creation of just enough UML diagrams to communicate and document a system design. It even argues that working software should be used to describe an architecture in the Elaboration phase rather than a 10000 words document. It can actually be considered as one of the first agile methodologies. RUP and other flavors of UP just added tools and guides aimed to facilitate the implementation of UP, but it was misunderstood that every template and section must be filled out instead of actually thinking what to use depending on the project. Unfortunately the whole thing was ultimately bastardized by the non-technical template zombies that thought software development is like building a skyscraper.

The CASE motivated tooling got in the way.

My go to joke: RationalRose is like an 800lb angry gorilla sitting between you and your work.

Alistair Cockburn did a great post mortem about that era.

Characterizing people as non-linear, first-order components in software development [1999] http://alistair.cockburn.us/Characterizing+people+as+non-lin...

During that time, I strongly preferred lo-fi paper prototyping for UI. And I'd scratch out UML diagrams. Worked fine for intra-team. But it just didn't fly with management. We had to make everything more formal and pretty.

Oh well.

It’s funny looking back at what we used to call software development methodologies. Booch and Rumbaugh were primarily focused on modeling. Any talk of process meant a dynamic description of the program.

Jacobson was a little more method focused. You can see how his introduction of use cases started the idea of talking to your customer about what they need.

I remember seeing Rose and thinking this will make a huge improvement only to be repeatedly confused and frustrated that it seemed to make everything take longer.

Finally! I get share my Booch story:

At OOPLSA 98, Booch convened the first society of software architects (or some such).

Having read all his writing (ditto Yourdon, Brooks, Rumblaugh, etc), I was super excited.

During the Q&A I finally got to ask “What is software architecture?”

Booch replied “Software architecture is what software architects do.”

Bubble popped.

I gave up seeking the council of the priesthood and blazed my own path.

Wow. In some ways, that's the worst possible answer. In my view, software architecture is what every developer contributes to, which means we have to be thoughtful about how we collaborate on it.

Every time I see a shop with designated Software Architects who hog the architecture work, it's a fucking mess. Because then Software Architects don't get rewarded in their careers for making software. They get rewarded for writing white papers and coming up with "brilliant" architectures and impressing executives who know less than them about technology. Which is mostly inversely correlated with actually making it easier for developers to get real work done.

I totally agree that it was taken over by zombies, and also agree it had some good ideas.

But I don't think it was quite as incremental and iterative as all that. One, it was more a "process framework" than an actual process, so iteration length could be whatever the grand poobahs wanted. They were entirely fine with multi-month iterations. Two, as the "RUP hump" chart shows, it was always pretty waterfall-ish. And three, whatever the words in the book, the RUP adopters were generally large-company shops, and he who pays the piper calls the tune.

I definitely remember the RUP people coming to the early Agile conferences and being very suspicious of our wild ways. So I'm not sure even its originators would have called it an Agile process.

Thanks for your misc comments in this thread.

This particular comment, the "UML Distilled" reminder, triggered a few hindsight notions.

Much like XML and J2EE tainted Java, I'm now having trouble distinguishing between UML and OOAD. Though I preferred Fusion to UML, I'm now wondering if any OOAD based methodology had a chance.

"...thinking that the main value of UML was in having a consistent language..."

Guilty. For a long time, I very much wanted executable models, roundtripping. I got over it. Now I place more weight on concision, DSLs.

But here's the new (to me) notion:

Maybe UMLs (and RUP) greatest benefit was the idea of having a list of questions to ask. You know, a methodology.

Writing this out, it sounds stupid, so please forgive my stumbling.

But two things stand out from the 90s, which I'm missing terribly today.

I miss Joel Spolsky's 12 steps to better code. What's today's equivalent? I haven't found it.

I miss strategy, strategic thinking. With all this agile stuff, I have no idea what anyone's talking about. Yes, UML & RUP were terrible. But at least we were trying to bring order to chaos. With agile, it feels like we forfeited, that we should just accept the chaos.

I don't think the gist of successfully developing software has changed that much since the early 90s, at least in consultancy: You work in iterations where the team and client develop, refine and prioritize the features of the system until the system is good enough to be considered finished. There is an initial vision and strategy that needs to be developed in the first iterations. The UP implementations describe ways on how to do this, though the agile community has come up with more creative frameworks: design sprint, product vision box, customer service map, etc. The strategy is reviewed each iteration with the re-priorization of the features. For this it's important to have revisions on the documents created on the first iterations.

The challenge as I see it is that clients usually don't buy into this and they believe that developing software is like making sandwiches or turning buttons on and off when in fact is a discovery process of abstract things. They then demand a fixed budget, fixed time and fixed milestones for a fixed scope ("You are the expert, you should know how much time this takes."). To sell the project the salespeople from software companies deliver this, those who don't are considered incompetent. In this conditions agile methodologies are prone to fail but not for the methodology, but because most of the time those sold promises are done with incomplete information or tailored to be optimistic to sell the project. Metrics from agile methodologies show from the beginning that the project won't meet the expectations and then chaos ensues: they stop collaborating with the client to hide the reality of the project, "managers" pressure the team to do more in each iteration, they stop doing the disciplines altogether, iteration and daily reviews are treated as long meetings where people commiting errors are shamed and scolded and frictions start to emerge between all persons involved. This is where I believe the whole notion of "agile sucks" comes from.

Much agreement. Been there, been done like that.

What’s more waterfall than the sales team throwing a poorly baked contract over the wall to the dev team and telling them “make it work”?

I think "accepting the chaos" is fair. We've accepted it because it works - or rather, Scrum is about doing the minimum amount of "bringing order" necessary to move forward, and no more. Which makes sense - people like the idea of tidiness, but you shouldn't put more effort into organisation than you're getting out of it.

My experience is that a good team does a good job. A bad team doesn’t.

I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice.

There are no quick fixes. People can improve but it takes time, dedication, and support.

I really dislike agile. A product owner asked me once if I get some benefit from them...and no, I don't. Thry get a lot of benefit from me sharing what I'm doing because they can then keep track of it and communicate it to other people, but I don't get any benefit personally.

I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the middle of that. It just complicates everything and makes me less connected and known in the company.

I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them.

How exactly does agile prevent you from talking to your teammates and getting feedback from them?

If I have a full and well-groomed backlog waiting for me at my desk, what's there to talk about? Sure, you can, but the the whole point of the PM is to take that off your shoulders and the parent is saying he doesn't want that lifted from him.

A well-groomed backlog is not working code. So I don't get how that somehow means there's nothing to talk about. If there's an agile MVP, it's "write some working code, get feedback on it, then repeat until everyone's happy within some tolerance." Scrum is designed to increase feedback, but it's a floor, not a ceiling.

Sure, but the PM is there for a reason and the PM has roles. There is overlap with what developers can be doing, but we are trained/encouraged to punt to the PM for such decisions, questions, and suggestions.

I get it, but it's now how I do my best work, proxying questions and discussions through a gatekeeper.

We do agile, but also use Slack and email, and walking across the room. If your organization is actively discouraging communication within the team unless it goes through the PM, that's bizarre. On the other hand, if the PM is acting as a gatekeeper with customers, that's not unusual. The reality is that you can't have everyone on the team talking directly to the customer, for a whole host of good reasons.

Regarding decision-making, that can be a problem---some PMs and product owners are micromanagers, hamstringing their team. But they would be micro managers with or without agile.

IME the PM works best when acting as a shield from random questions or future things or other not-important-this-instant distractions, but shouldn't block direct clarifying questions or feedback from you to a stakeholder. I'd keep them in the loop, but the ones I've worked with haven't wanted to just be a glorified "I deal with the goddamn customers so the engineers don't have to!" middleman for basic things like that.

As a tech lead in a Scrum team, this shield causes more problems than it solves in my experience. We often get questions missing context or find out about a decision too late to provide meaningful input on a technical level.

Team mates are the ones I'm working with all the time. I don't need scrum processes to talk to my team. A good team knows how and when to share information.

> Team mates are the ones I'm working with all the time. I don't need scrum processes to talk to my team. A good team knows how and when to share information.

Scrum processes are just a way to ensure that no stakeholder, including team members, is left out of those talks, left in the dark, or left unheard. Having a clique single-handedly and unilaterally dictating changes without communicating them or listening to any stakeholder doesn't serve anyone's interests. That's how projects fail.

A good team knows how and when to share information.

True. Scrum is a floor, not a ceiling. Nothing prevents the team from going above and beyond the daily standup and the sprint review in terms of communication, and I've never been on a team that didn't communicate a lot more than that. But doing that standup every day ensures that there is at least a minimum of communication, every day.

I'm pretty sure that when he says "the rest of the employees" he means what Scrum calls stakeholders, not members of the development team.

For a long time I felt that way as well. There are days when I still do, and this is from my current perspective as a tech lead who spends ~50% of their time in meetings with other parts of the company.

Sadly once a team scales up past a certain size its not practical to have developers also going out, finding out what people want built, and handling all the feedback on that. You need someone (or a team of someones) gathering the often conflicting requests coming in, and prioritising them against each other.

Having said that, I do believe once a piece of work makes it to a point where people are likely to start working on it the developers who will be doing that work should be involved in the process. They should understand not only what is being requested, but also why its being requested, in my experience that often results in them suggesting alternative solutions that either bet solve the problem, or provide a 90% solution with significantly less cost. It also gives them the context needed when deciding on technical trade-offs involved in different design choices.

I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the middle of that.

Part of little-a agile is making changes and adapting -- it's literally in the name. If you have a process in place that prevents you talking to the people you need to talk to, change or delete the process.

"I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them"

I am the same way. I much prefer talking to users directly and come up with a solution instead of having a middle man. But I have noticed that a lot of devs much prefer somebody filtering things for them. I guess to each his own...

Why haven't you told your manager that you are willing to do your job plus the product owner's job for only your pay plus half the product owner's pay?

Because that just doesn't work. It sounds clever, but in reality, it would get you laughed out of the office. And then the PO finds out that you offered to get him fired, and now the working relationship is ruined.

My experience is that a good team does a good job. A bad team doesn’t.

Of course that's your experience. If you judge teams based on outcomes, then you're going to conclude that teams that succeed are good, and teams that don't must be bad. Unfortunately that offers no guidance in how to become a good team. The goal of software management as a practice is to find patterns of positive behavior that make good teams. Agile, in general, is a collection of those patterns.

The observation is more about people. You take random people from good teams, mix em up and put them in a very different environment, they're still going to do a good job.

What if there is no reasonable and reliable way to become a good team, and the only way to go from a bad team to a good team is to replace most of the team?

How do you know they are coming from "good" teams? And if so, isn't it reasonable to suppose that they might carry over good practices in their new environment?

I don't doubt that there are bad developers---I've definitely encountered them. But software development is a team sport, and it makes no more sense to just "recruit good people and leave them alone" in software than it would to do the same in basketball. Great teams have both talented people and winning strategy.

Because people regularly do "recruit good people and leave them alone". At my first job I was the only developer working on the project and I rarely spoke with my boss. He came back from a month long vacation and I had not noticed he was gone.

That's surprisingly common across the field. Most developers work on small teams doing small but often very long lived projects. Code staying in production for 30 years is surprisingly common outside of SV.

Those people, in those positions, probably don't need much in the way of process. If you really can just sit down with the owner of the business, hash things out with them, and then go build something that does what they need then you're golden. And guess what, you're probably doing agile without even knowing it, because agile is attempting to reproduce that in organisations where you can't just put a single developer and a the CEO in a room and expect that to happen.

They also regularly "recruit good people and leave them alone" and they fail. And then we look on those people as "bad" people. Which was my original point above.

Look at sports... I've seen both cases, players that are good within one system horribly underperforming in others, and players that don't look that great meshing with other castouts and creating a surprisingly good team.

I suspect the same can happen with software developers.

Of course, there are people that will be bad anywhere and top guys that will be great anywhere.

I wrote more in my sibling comment. I generally agree that there aren't any strict guidelines for becoming a good team, but I disagree that replacing most of the team is the solution in any but the most extreme cases. I would venture a guess that, most of the time, there's one person to remove and one person to add: a new leader. If that doesn't solve the problem, potentially looking at developer contributions and seeing if there's someone who isn't pulling their weight and has no interest in learning how to. (I've only encountered these types of people a handful of times in my career. Most of the time it was shoddy leadership)

Then it would be good to figure that out, measure that, and then at least we can put the best people on the most important projects. It's perfectly possible to imagine a world where e.g. developer IQ was the only thing that mattered and the quality of software that got produced was simply proportional to the average IQ of the developers who worked on it, sure.

I don't think that's the world we live in though. I've seen smart, sociable, effective developers fail in misorganised teams, and I've seen teams of ordinary people produce very good software by getting their processes right.

I accept that he's polarizing to some, but Jocko Willinck's book "Extreme Ownership" has some interesting stories on this topic. One of them is at Navy Seal training camp, where there's 6 teams involved in a multi-stage boat race exercise. Half-way through, team 2 is destroying everyone and team 6 is losing pretty badly. So, to teach a leadership lesson, the instructors decide to switch the leaders from teams 2 and 6.

At the start, team 2 continues doing awesome, and while team 6 doesn't win, they improve. Next round Team 2 isn't doing quite as well, but still good. Team 6 has improved a bunch. After a couple of rounds, team 2 is falling apart and team 6 is now winning (or 2nd place, I forget).

My experience, admittedly anecdata, is that great teams perform well when they're in an environment where they're allowed to succeed. I've worked with great teams who did terrible work, and it was pretty much always due to a bad environment (e.g. an owner who would redirect their efforts every few days, so no feature ever got to done-done). I've also seen (but not personally led) teams that I had originally somewhat written off, who under good leadership managed to do some pretty damned impressive work.

And don't get me wrong, I'm not devaluing the potential contribution from a single amazing person, or a team full of amazing people. My clients hire me because I have a (locally) rare set of skills that their team doesn't have, and help them get over hurdles that their team can't (currently) tackle on their own. But if you take a great set of individuals and put them together in a shitty environment with a shitty leader, you're going to get what you get.

My quip on scrum/agile is that it "ensures mediocre results from mediocre teams." Its just a methodology in the end. It can help keep those that tend to have wandering minds focused, but for high performing teams the overhead slows them down.

The assumption of a standard programmer is just never a reality as well. I actually saw a startup try to go full religious agile and only hire "full stack" developers to try to homogenize them so that they would fit the agile mold better. It didn't seem to work very well, people are people and naturally gravitate towards data modeling, or UI, etc.

My quip on scrum/agile is that it "ensures mediocre results from mediocre teams."

And honestly that is all that most companies actually want/need. Most teams are mediocre and most projects only need a mediocre result. Getting something as good as a mediocre results out of your mediocre teams would be a massive improvement for a lot of place.

I would rephrase it from "mediocre results" to "good enough results" - not everything needs to be a work of art. Especially in the startup world, where there's never enough people to go round, there's a huge value in knowing when you've done enough that the project you're working on is no longer the thing that'll deliver the most value.

What agile does when executed right is to fully embrace that, and wrap it in a process that ensures that when you reach that point you're able to finish the current iteration, ship what you've got, and move on leaving things in a good enough state. For me that's the core of agile, and in my experience at least you can't pull that off with a mediocre team. You need a team where at least some members have the experience and the pragmatism to know the difference between delivering a minimum viable product and cutting corners in a way that'll hurt in the future.

When I learned about the concept of "just barely good enough" I was thrilled by it. Lots of people been using the expression "good enough" and to me it feels like a defeatist idea. "They did their best! It's good enough, isn't it?"

http://agilemodeling.com/essays/barelyGoodEnough.html

Given the constraints of the estimate we've made for a story that could really go much longer, except that we've only allocated two days... I think the problem you're hinting at is that different people have different ideas of what the Minimum Viable Product should look like.

Accordingly, on my team where we're all under-trained with respect to Project Management and mostly just making this shit up as we go along, we've identified several other points on the curve.

It's suggested that one should make some nominal efforts to identify, and stop for a sniff along the way to JBGE:

"that's definitely not good enough, try again"

"I'll know it when I see it, but I'm sure that isn't it"

"kinda-sorta good enough"

"that's nearly good enough, except for this one thing..."

Identifying some of these points along the way (and making sure you notice when you've arrived at them) in my opinion is a great way to help ensure you're not actually aiming for points somewhere deep on the wrong side of the curve.

The mediocre team also may have trouble getting to Just Barely Good Enough because of overshooting. But in my experience that's usually not the problem. Nobody is working far past JBGE into the wee hours of the "OMG this is too much, I love it but how long did it actually take?"

If anything, the feature has to be shelved or scrapped, or handed off to someone else, because it's taking too long due to an error in calculation of trajectory. Spending too much time on the wrong things. Incremental progress is the goal, and perfect is the mortal enemy of good.

To be honest, that wouldn't be a problem if more companies were up front about it. But every company out there has this idea that they have to hire "the best".

every company out there has this idea that they have to hire "the best".

Maybe in Silicone Valley, but most companies are happy if they can just find a programmer that knows how to program.

"Agile" is completely independent concept from "full stack" or "homogenized" development.

This is true. With the emphasis that Agile puts on "blockers" though it becomes apparent that the typical model of having a simple person own a component with maybe a backup person or two is problematic. "Only Amy knows that code, and she is working on X which is also critical" is one of the more frequent types of issues that comes up in standups.

To combat this, this individual decided to try to reduce the specialization as much as possible. Everyone would do everything was the thought process, so no one could ever hold anything up.

This was a non-technical founder of a now dead startup, but it died of the much more typical problem of market fit- they did launch, and the site worked. It may be interesting to mention he was also using entirely offshore development teams.

My experience is that a good team does a good job. A bad team doesn’t.

My experience is that sprints interrupt my workflow to such an extent that I can no longer get anything done. In other words, they make a good team bad.

How so? I'd be keen to hear just in case I'm unwittingly inflicting similar pain on my developers.

Perhaps it's just me, but I need long periods uninterrupted to work. It's not just the regular status meetings, but other meetings which break up the day to an extent that I can no longer get that.

Yeah, but that's not a scrum thing. Most days, I have the daily stand up (which occurs right after I get to work), and that's it. The one day where we do all the grooming and retro and demo every two weeks is more or less lost, but that's not much of a problem.

What about code reviews?

Code reviews are very important, so I don't complain about time spent doing them.

Agreed. I've seen a lot of "good practices, methodologies, processes, etc", but none of them even tries to address what is, often times, the most critical issue: a team of good software engineers. Instead of endless meetings and bullet points about how to handle a Jira ticket, maybe focus on how to handle pointers?!. I've really had colleagues who don't know how to program in C and when asked about it said "I don't even want to learn it, we have all this tools and methods", but their title says "C embedded engineer" or thereabout.

I can also see the business point of view in this. You want switchable puzzle pieces. Take this developer from this project and move him to that project. This developer knows X, Y, Z and that project needs X, Y and Z. So it's all nice and well. Only it doesn't seem to work in practice.

You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management".

But you have to include 'estimates', which ruins everything (in non-trivial cases, yadda, yadda).

Estimating is my Achilles heel. Always has been. I'm way too optimistic.

My workaround was to do jelly bean estimating. Get guesses from everyone, then use the average. Worked surprisingly well.

We did other things to meet that target date, honor that estimate, of course. But that's a longer story.

> I'm too optimistic

Have you ever thought much about why, though? When I was young, I was super optimistic - and I got burned by all of the surprises (including the underspecified or unstated requirements), so I started to estimate pessimistically based on experience. But then I got stuck in this loop: "How long will this take?" "Probably two weeks" "What? Why two weeks? Why not two days? We only have two days. Say it will only take two days, or tell me everything you're going to be doing on an hour-by-hour basis to justify this high estimate!" So now I've just gotten really good at figuring out how long they want me to say it will take, say it will take that long, and shrug my shoulders when it takes longer. Since everybody else is doing the same thing (as they don't have any choice), it doesn't surprise anybody.

I have thought about it. A lot.

I'm told I work too slow, dive too deep. Now I'm trying to figure out how to do just 80%, "good enough".

When I was a kid, I published shareware. After getting a few 3:00am wake up calls from irate customers, I said "never again". I spent 15 years designing, engineering away technical support calls. It mostly worked. Later on... When my team(s) burned a CD, we rarely had to issue patches, hot fixes.

Customers loved us.

I thought that was the pinnacle of human achievement.

Now, I feel like I'm still fighting battles over things no one cares about any more.

This. Figuring out how to stop at 80% is a skill I'm struggling to learn. And I don't mean "learn to half-ass things"; in the vast majority of cases 80% is more than good enough to get the job done.

Customers may talk about hating bugs, but when you ask them to put their money where their mouth is, 95% of the time they'll buy buggier software with more features.

> Estimating is my Achilles heel. Always has been. I'm way too optimistic.

That's kinda the whole point. Everyone sucks at estimating. Scrum proposes a way to do "what greybeards call project management" in a way that deals with this universal inability.

I'm having trouble articulating this, please forgive:

I didn't explain "the other stuff" for why jelly bean estimating works.

The number doesn't matter. It's the shared hallucination (consensus) for the deadline. It short circuited, resolved the debate about "how long". It secures the team buy-in.

Once we had a deadline, we managed the work to match. Closest analog I can think of is Kickstarter: initial goal and stretch goals. We had the must haves (stuff listed in the draft press release). We also had dozens of nice to haves we'd sneak in, time permitting.

Agile, Scrum, sprint style estimating is too fine grained, the horizon too near, to do effective estimating.

What I've learned in engineering (any form, including software) is take the estimate (acquired in any decent enough way like averaging) and multiply by PI (or 3 if that suits you) to get a reasonable amount. In practice it works more accurately for larger sums than smaller ones so your mileage may vary. I guess it is easier for everyone to guess smaller workloads more accurately.

In my practical experience, I multiply the amount gathered from the previous statement by two to have sufficient negotiation space for people 'higher up the chain' who have no idea about anything of this and simply pull estimates out of thin air or their rear without any proper experience except "previous time it was xxx so it should be the same" (which it almost always is not).

edit: I prefer to have some time left on larger projects to avoid overrunning, even though that might be common practice. Usually though time is cut short due to delivery constraints or selling a product before asking the development and you get the 'wasn't it done yet?' speech.

Here is the "chart" that I use when determining how accurate an engineer's estimate will be. The left column is the hour estimate to look up the volatility from. The right column represents the potential volatility (probability of increasing in time) of the work item based on the hour estimate.

Hour Estimate : Volatility Level

    1 - 5 : Little to no volatility.

    5 - 15 : Small volatility (a day, maybe two).

    15 - 30 : Medium volatility (multiple days).

    30 - 60 : Medium to High volatility (days to weeks).

    60+ : High volatility (multiple weeks).

The reason behind this chart is that when determining what goes into a release there is a tendency to treat all items as static in size. What I mean is that most people will say, "Three 15 hour work items are equal to one 45 hour work item." or "Six 5 hour work items are equal to one 30 hour work item." The worst offender, "Four 15 hour work items are equal to one 60 hour work item."

Additionally, as a work item increases in size the amount of "knowable things" increases as well. Of those "knowable things" there are many known knowns, known unknowns, unknown unknowns (thank you DR for that gem). There's a near 0% chance that a team will get all of the requirements in place up front on a 60 hour case.

If a scoping team is told that they have 240 available hours to work with, then they will pick a combination of items that fit within the 240 hour box. If they have four high priority 60 hour estimate items then they may pick all four for the release. In the event that four 60 hour items are chosen I would place a near 100% guarantee that the release will not go out within the 240 hour time frame. I would even wager that will be up to four weeks late.

Nothing protects against toxic management.

"Evidence Based Scheduling"

https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

I go one step further: Get guesses from everyone, then use the average multiplied by 3. That lets management talk me down by 1/3rd so they feel they've won something, and I still end up with a little wiggle room.

Everyone tacitly assigns a time value to "points" anyway.

Which is fine. The point (heh) is that the mapping can be adjusted in a feedback loop based on what you actually did in the past.

I've always seen there being a maximum size of a ticket for one sprint. So effectively 8, or, 13, or 21, or whatever, is two weeks, and all the other sizes are some fraction of that, and you end up trying to calibrate how you vote for points based on how long things take.

> You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management".

That's not true at all. The whole point of organizing projects around scrums is precisely that there is no well defined goal nor can one exist. What exists are the client's needs, and those needs do and will change frequently and radically as projects move on.

Therefore, the classical project structure followed by grey beards does not make any sense in software development. What does make sense is to acknowledge that requirements specified by the client do and will change, and it's better to adapt to the client's needs and get everyone involved in the project. Therefore, projects are organized in small bite-size units of work that gradually contribute to implement a product based on the feedback received by all stakeholders, and that these small bite-size units of work are implemented in small time windows. These units of work are short-lived and the amount of effort invested in planning is limited to the goals set forth for that unit of work, which need to be manageable.

"...there is no well defined goal nor can one exist."

Consulting is the pejorative we gray beards used for that activity.

You reminded me of another pithy throwaway line:

Agile didn't improve outcomes, it just reduced the cost of failure, allowing teams to fail many more times with the same budget.

So, agile improved outcomes? I'd love to have 1 big win a year and 11 cheap losses, than 5 expensive losses and then bankrupt before a big win.

> Consulting is the pejorative we gray beards used for that activity.

Those hypothetical gray beards may come up with all the pejorative terms they need, but that only hides the fact that they are entirely oblivious to the reality of running a successful software project, one which actually meets the client's requirements and delivers working products. Therefore, they spend their time coming up with pejorative terms while they insist in wasting their time and effort forcing the proverbial square peg (waterfall) in a round hole (software development projects)

> Agile didn't improve outcomes,

That statement is patently false. No one can make that claim with a straight face in a world where paying customers make it their point to change fundamental requirements on a weekly basis.

In the old timey's waterfall world, a waterfall project that's executed flawlessly is a project that ends up delivering the wrong product that fails to meet the client's basic needs, thus leading to a very unhappy client that may even feel that he has been played.

> it just reduced the cost of failure

A sequence of small failures that converge to the client's needs is a whole lot better than a single unmitigated major failure that's ensured by following Waterfall methodologies.

You and I have very different expectations. Long ago I decided to walk away from work lacking clarity. I’m a dev, not a therapist.

re Outcomes, my data is old, I’d love to proven wrong.

I’ve read (elsewhere) that high(est) functioning orgs like google, facebook, netflix have made great progress. But the rest of us are just banging the rocks together.

PS- PMI & critical path, as I’ve done it, is the opposite of waterfall. One hard earned trick is proper ordering of the work. eg, after a project kickoff, first deliverable is the press release, second deliverable is a demo (even if its entirely faked).

>but that only hides the fact that they are entirely oblivious to the reality of running a successful software project

Wow, amazing that the shoulders of the giants you stand on was never a successful software project.

>In the old timey's waterfall world, a waterfall project that's executed flawlessly is a project that ends up delivering the wrong product that fails to meet the client's basic needs, thus leading to a very unhappy client that may even feel that he has been played.

Waterfall was iterative as well, when the needs changed, so did the project plan. You bought that line, but that's not how it ever was in my experience. You know those version numbers software has? Those are the iterations. We'd cut a release about every 3 months.

Based on your comment, I suspect you've never done anything outside of scrum / agile, so you are comparing it to some mythical way of doing things you heard about (undoubtably from scrum consultants.)

> Wow, amazing that the shoulders of the giants you stand on was never a successful software project.

Those giants you're referring to made a lot of mistakes along the way.

One of those mistakes was blindly trying to force project management practices that were driven by the need to allocate material resources into projects where the only resource that's allocatable is man-hours. In projects whose success is determined by how well are material resources spent, redesigning something midway is something that's entirely unthinkable and can even dictate the project's death. That's not the case in software development projects, where the only resource is the fixed amount of man-hours that's at the project manager's disposal. With the development and adoption of a couple of software engineering practices aimed at preserving the project in a deliverable state, redesigning entire modules is essentially free. Therefore we end up with project management challenges that superficiality may appear to be the same but are actually fundamentally different.

Therefore, different types of constraints result in different optimization problems that lead to different solutions and require different approaches.

> Waterfall was iterative as well, when the needs changed, so did the project plan.

The keyword you've used is "needs". You're assuming that changes are exceptional. They are not. In software projects, requirement changes are the norm, not the exception. Changes aren't needed, they are constant. If your goal is to meet the client's needs then you need to meet the client's needs, and not some line in the sand that has no bearing with the paying customer's goals.

> Based on your comment, I suspect you've never done anything outside of scrum / agile, so you are comparing it to some mythical way of doing things you heard about (undoubtably from scrum consultants.)

You suspected wrong. In fact, I have far more years of experience in waterfall projects in real world engineering projects than in scrum/agile. Waterfall projects make sense when the requirements make sense. Software development projects based on basic software engineering practices don't incorporate some fundamental requirements found in engineering projects, thus their efficiency can and does improve by following adequate practices.

"The whole point of organizing projects around scrums is precisely that there is no well defined goal nor can one exist. What exists are the client's needs, and those needs do and will change frequently and radically as projects move on."

I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are.

> I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are.

You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements, that these requirements will and cannot change, and that software architects have perfect information and are able to make flawless choices regarding the design.

None of these assumptions hold even in conventional engineering projects. The only reason why waterfall processes is used in conventional engineering projects is that it's so expensive to fix problems arising from these sources of failure that it's perfectly fine to deliver working but inadequate solutions.

"You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements"

No, I'm not. I am assuming it's realistic to expect that a company actually put some effort into finding out what they need, and getting us that information so that we can actually plan out a project.

"None of these assumptions hold even in conventional engineering projects."

Part of the reason for that is that companies don't do any of that research. They don't look at what they need; they think about what they want.

One of the biggest reasons people here dislike "Agile" is because management uses it as an excuse not to plan anything, and fly by the seat of their pants every two weeks.

> 2. It's important to stop what you're doing on a regular basis to evaluate progress and problems. This always seems like a waste in the moment, but failure to do so leads to regret down the line.

This point is of general usefulness and applies to many areas of our lives, not just software development.

Preach

My mental model was that ideally it is a greedy algorithm for job shop scheduling (dev time) with dt = two weeks and a horizon as long as your backlog. The biggest and most common failure mode I saw was having a bad product owner (it can be a single point of failure, devs have a team to help them out).

Great job distilling the essence of scrum into three bullet points, I wouldn't disagree with those.

Here's the common pitfalls as I see them:

1. Sprints offer flexibility but unless you educate the whole company waterfall + gantt charts are what the business side wants

2. Unless you educate all members of a scrum team on what the retrospective is, and let the developers drive it, you won't be effectively improving processes

3. I've always felt conflicted about the agile "working software over comprehensive documentation value". To me it implies that documentation is easier when the product is working and/or the product might change based on feedback, so you don't want to re-write the docs. To people who don't learn scrum/agile it means "don't write documentation"

That last point is simply working software _over_ documentation, meaning that in a world of finite resources what would you rather have? A pile of requirements and technical design docs _or_ a working product? All teams need to determine the right amount of documentation that maximizes total output of working software, but agility was--in part--a response to analysis paralysis and high overhead of many software implementations of the time.

Not all documentation is equal.

While design documentation tends to be anti-agile (but sometimes useful to avoid wasting more time on miscommunication and mistakes), end user documentation is, for all practical purposes, part of the valuable software product, as it enables end users to do what they want to do.

Unfortunately, being able to neglect end user documentation makes many outfits treat it as a useless luxury, either because they are only judged on software (e.g. passing a test instead of having satisfied users) or because they don't care (e.g. many introverted hacker/artist open source maintainers). It's purely delusional agility, like driving fast by not stopping for fuel.

I think you are entirely right that the "sell books and consulting" is a major driver of what Agile became. I got involved in the Agile world circa 2000, but by 2010 or so my main feeling was increasing horror: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...

One of the especially interesting things to me was that at the beginning there were a variety of different methods. People behind them got together in 2001 to figure out what was common, and that's where the Agile Manifesto came from. Of the Agile Manifesto signatories, I think only two of them were Scrum people. These days, though, most people thing that Scrum is Agile and Agile is Scrum.

I see three reasons for that. One, Scrum was the simplest, arguably the lowest common denominator; it had no technical practices. Two, it could be installed in place at existing waterfall companies doing what is effectively mini-waterfall, so there would be little disruption to the hierarchy. And three, it had a "certification" program, where a) anybody wanting a career bump could spend 2 days to get a "Master" certificate without taking any test or proving any competence, and b) any "consultant" wanting easy money could quickly become a Scrum trainer. Basically, Scrum became the Amway of software processes.

If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission accomplished".

And my point here isn't "Scrum bad", really. There are some great people in the Scrum world. My point is, "Business models shape outcomes, so be careful which you pick."

> "If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission accomplished"."

I think this is a key insight, and I suspect for many people (myself included), the phrase you use when you say "Low-end Scrum" is just the only type of widespread Scrum we've ever seen practiced anywhere, ever, to the point that it makes us question whether Scrum itself is partly responsible, even in an idealized format.

One of my good friends came up with the idea he called "barriers to anti-quality" to describe this. A good workflow process establishes inviolable norms that act like preventative barriers to doing things in an anti-quality way -- so that you specifically arrange the world such that trying to take a quality shortcut actually costs you more than just doing it in the quality way.

We proposed trying to judge workflow and management practices based on how willing upper management was to give up control of the process in exchange for erecting barriers to anti-quality.

If they wanted to force a team to pivot in some quality-destructive way, just on their whimsical preferences for reprioritizing different tasks according to vague business needs, they could not do it.

Barriers to anti-quality would be like Odysseus pre-committing to be tied to the mast, so then when the Siren song comes, he cannot give in the temptation.

I think a lot of the spirit of early Agile was meant to suggest something like this. Even though the method talks about being flexible and adapting when there are real business needs to adapt to, this gets bastardized when middle and upper management conflate adapting to real business priorities, and begrudgingly paying a cost in terms of quality lost due to pivoting developers, with demanding that people have to adapt to the management flavor of the month, unsubstantiated ideas about business priorities, often stemming from political power struggles, restructurings, quarterly earnings, etc. etc.

What I really wish Scrum or Agile had, was a more unbreakable way to let development teams say no, and decline work or decline pivots. Basically to veto changes made to the backlog, and say that it violates an anti-quality principle for no good reason.

A key failing of modern Agile / Scrum is that it doesn't create any type of stop-increasing-our-entropy-with-unsubstantiated-management-preferences notion of a barrier to anti-quality.

Don't get me wrong, this is hardly a failing that us unique to Agile / Scrum. But I think when people talk about why in principle these methods fail, it's that they lack any mechanism of enforcement for this. As a result, they can be so easily politically subverted to just be a pivoting, bludgeoning tool of misguided or unexplained management choices, that almost always trade-off quality for anything else, and instead of ever looking back to understand when an under-investment in quality actually cost them, they just explain it away as some other team's fault.

In a sense, Agile / Scrum (or 'Low-end Scrum' as you call it), is a tool to create managerial Dutch books. A manager gets to unilaterally disrupt on-going investment in quality without ever being held accountable when that gamble on short-term anti-quality causes losses.

By the end, it makes developers very cranky that they are being jerked around with all this prescriptive and time-wasting overhead of meetings, planning, estimating, etc., only for this political anti-quality nonsense to go uncorrected anyway. If that's going to happen anyway, then what's the supposed value of all that costly Agile-specific overhead?

Would love to hear more about practical examples of "barriers to anti-quality". Would this be things like e.g. "Emplace and enforce documentation & project change control process" -- people may want to make changes - but if they don't go through the change request process - they can't have those changes effected?

One example which I actually used to great effect in a previous team was that the team decides the relative allocation of backlog items between new features, fundamental research, maintenance, and refactoring / architectural design. The product owner, no matter how upper management is breathing down their neck, is not allowed to supersede that allocation.

Once we got approval for this, it meant that product owner had to focus on communicating to us why the business had certain priorities and desired certain pivots, instead of just nuking our desired plan of work and superseding it "from on high."

It meant everyone had to trust us as the team that we wanted the business to succeed! (Who'd have thought!) And we weren't going to act childish and just demand backlog items and sprint work that satisfied our preferences for some fun project or some back-burner idea. That, as grownups, we would actually consider when business priorities made sense to supersede our intended plans, and act accordingly.

After a while, we exercised our privilege a few times to ignore or decline "urgent" work that the product owner relayed to us. Instead we invested in much needed refactoring stories, fleshed out more serious design documentations, researched detailed trade-offs between approaches or third party tools we would need in the near future.

Over about a year's time span, this worked incredibly well. The team felt happier and more productive. There was less tension with the product owner since he would not circumvent our plans and dictate new priorities all the time. And people learned they could trust us to understand the underlying business considerations and deploy our team accordingly.

In our company, this was very much as "un-Agile" as it gets. It was the farthest thing from what "Agile" methods meant in the company as there could be, and in large part we only got permission to work this way because our output was in a very specialized domain area that had really critical requirements for some large business initiatives. Most teams could not have possibly negotiated this arrangement.

Like clockwork though, the director of our business unit was surprisingly fired and replaced with no explanation or warning, and the new director stopped us from doing this at that point. It reverted to the usual thing where sprint planning is just a Wheel of Fortune gameshow where you learn the radically new and unplanned pivots you'll be forced to make for the next two weeks. Like trying to win a 100m race by dancing on a DDR mat at the starting line.

Anyway, long story short, the barrier to anti-quality principle was that it's totally the team's discretion as to what work is admitted into the backlog. If the team ignores legit business considerations at their own peril, to goof around with fun stuff, then the team owns that failure. But no matter what, they are not told by the product owner what goes in the backlog, and it must be a sacred right for the team to tell the product owner "no" when management proposes to add work or change direction in a clearly stupid way.

So like everything in life, it all comes down to management. If management doesn't buy in, it doesn't matter how many processes you put in place, they're the ones that either hold the keys to success or failure.

Except that Scrum added time-wasting extra stuff on top of the situation.

If management doesn't buy in and I can operate my own low-overhead, low-formalism workflow, then so be it. I suffer the badness of management, but I don't also pay time waster costs for a formalized process whose sole purpose of better facilitating productivity is categorically disallowed in the first place.

I personally, as a matter of experience and opinion, would take it further to say that certain properties of Agile / Scrum actually add fuel to the fire and allow management's already bad behavior to manifest in even worse ways. But even if someone doesn't agree with that, I think the point stands: why incur the overhead costs of Agile if the same outcomes happen because of mismanagement anyway?

No, I agree; that's why I've always thought of it as an amplifier for management. If you have good management that buys in, then everyone is more productive. If you have crappy management that doesn't, then they're given a tool to amplify the micromanaging and dispiriting aspects of the job.

Man. ^ This is a brutal revelation right now. Totally just opened my eyes to exactly why things have been going badly at work, despite formal process.

Conway's Law deserves a management corollary.

That's great to hear, and I'm sorry it blew up.

I had a less extreme version that still served our needs. My rule was that a fixed percentage of effort, say 80%, would go to business priorities. The product manager could certainly ask about where the time was going, but they couldn't claim it unilaterally. The rest of it could be ordered and reordered as the product manager thought best. We in turn could ask about that.

This worked well for us, in that it let us keep the code clean and make tooling improvements without having to explain to a non-developer what was going on.

It was also helpful that we were good at expressing technical-sounding things in user terms. E.g., all scaling and reliability work was put into the backlog with titles like, "system handles 1000 simultaneous users" or "system survives web server failure". And a lot of research was covered by the product manager buying information rather than features.

Of course, this was at a startup, where there was no "on high". The product manager was the CEO, so in theory he could have fired us, but mainly we just collaborated on getting shit done.

My experience with scrum at work using VSTS is that you do have the option to mark tasks as closed and fill/dropdown box the reason why. If not on your own, then at a scrum meeting when the story or task comes up. (If you need to discuss whether or not it should be closed.)

I often wonder if it would be easier to start from the top instead of trying to build those barriers from below.

If your business leaders are prone to changing their minds at the drop of a hat, you probably aren't going to actually change that. Putting process in place to make it painful to do that is just going to cause pain for the people who have the decision imposed upon them - the CEO's just going to tell other people to figure out how to make it work.

Is there a way to bottom-up build something focused instead on reducing that pain from those pivots? Just-in-time planning whenever possible, for instance, to minimize wasted time invested in would-be future projects?

The timeframe matters, here, though. Are the wild changes once a quarter? Once a week? Once a year?

Generally the problem is that management wants this idea you call "just in time planning" to happen all the time, and even believes it to be synonymous to Agile. Meanwhile the software team is saying, that's fundamentally at odds with the entire premise of how to write software. Saying you want to produce software that was always planned at the drop of a hat (which is what management wants) is like saying you want to chisel Mount Rushmore but you won't tell whose faces should be on it until right at the end. It's just not a coherent goal. My hope with the barriers to anti-quality thing is that we would take things like this, where regardless of what management feels entitled to, and make it sacred and inviolable that the obviously stupid and incoherent things can be vetoed by the feet-on-the-ground people doing the actual work.

Hypothetically, "agile" is about _allowing_ decisions to be changed at the drop of a hat, without causing pain for implementers. The whole point is accomodating that, that's what "agile" _means_, right? (One can argue this whole goal is impossible, but I don't think it is. If it is, it's a problem for any agile process, not just "low-end scrum." But I think there are _way bigger_ problems with thinking you can plan out all work and schedules a year in advance and stick to it and wind up with anything succesful).

Now, every decision (new or changed) has a cost to be implemented. Some more than others. If you have decision-makers who refuse to recognize that, and think the amount of work they can ask a given staff with a given level of skill to accomplish in a set time period is unbounded -- no process is gonna save you from misery.

Definitely. I think you're well on your way to reinventing what the originators meant by "Agile". The subtitle of the first Extreme Programming book, for example, is "embrace change".

I spend a couple of years at a startup I co-founded; requirements volatility was legitimately very high. We were very experimental, which meant we learned a lot, which meant frequent wild changes. We had a long-term vision, and plenty of theories about the future, but rarely planned more than a couple of weeks out.

This was honestly fine. The product manager (my cofounder) was really good at including us on the necessity of the changes, so it never felt irrational or out of control. Our process was highly tuned for minimum waste. And we were militant about a lot of quality-oriented practices, including unit and acceptance tests, pair programming, paying down technical debt, continuous deployment, frequent releases, and close collaboration with the product manager. That meant that however things changed, we were prepared.

I think if you can do it at a start-up that's shipping every few hours, it definitely works at much lower levels of requirements volatility. To me the real issue at scale is that if agency moves away from the team level and gets concentrated at the executive level, then decisions at least appear irrational, and often are because real-world information becomes ever more removed from the decision makers.

You might want to keep in mind that making cost estimates for proposals is how developers get to influence the planning process. If you skip this, you're giving up your power.

> when you say "Low-end Scrum" is just the only type of widespread Scrum we've ever seen practiced anywhere, ever, to the point that it makes us question whether Scrum itself is partly responsible [...]

Yes, exactly. I know some good people who are dedicated Scrum fans. In their view, the engineering practices are all implied, because if you do have a relatively autonomous team dedicated to continuous improvement, you'll get there. And it works, because they are smart and dedicated people committed to doing the right thing.

So in that sense, the idea of Scrum is a good idea. But Scrum-the-movement and Scrum-the-business have fallen very short of that ideal. So in practice about 98% of Scrum implementations I've seen make me despair for humanity.

> What I really wish Scrum or Agile had, was a more unbreakable way to let development teams say no

One interesting version of that was the Extreme Programming Bill of Rights. One version of it is here (and in XP jargon "customer" is something like "product manager":

http://www.agilenutshell.com/bill_of_rights

It's not perfect, but I think it was a good attempt to make clear that there's a useful balance of power.

I love the phrasing of 'barriers to anti-quality' as a way to bring attention to this particular category of (rampant) problem. It reminds me of that saying 'under extreme pressure we tend not to rise to our ideals, but fall back on what we know.'

I work on 3-12 month projects in an agency, we don't really do Scrum. It's mostly some version of waterfall, and occasionally dual-track agile. Generally the process of determining what to build is squeezed into the cracks. I just recently built about 40% of a prototype for a SaaS in a couple weeks with fractional team input, and then had to lay out the rest of the flows in a week. After that, more needs popped up (I can only imagine the shitshow that development will be). This is the worst case scenario.

In less-worse cases, it seems like this becomes an issue of how to compare a requested change's value to its cost. Without enough data, this can be really hard to actually know well enough to have a grounded position on. It seems like consensus here is to focus on the cost of the change, rather than the potential value.

It also seems like there's little faith in managers. I don't totally know what it's like out there for ya'll though.

You’re absolutely right - and that’s the e tire core point of Scrum: to promote agile methodology (which can be summed up as you just did)

However the reason there is “bs” (by which I assume you mean the process/meetings/etc) is that most teams suck at being agile. Scrum provides a more rigid framework so that a team can develop agile skills and then, when ready, move beyond scrum.

Most people think Story Points or terminology like Standups comes from Scrum too - they don’t! They’re from XP.

Scrum is exceedingly simple and suffers from being over complicated and dismissed by those who don’t understand it,

The blog post above is no exception.

I'm probably oversimplifying, but this looks like 3 different ways of saying "get feedback often" :)

That's... actually pretty accurate? Dang.

So it becomes this?

* Get feedback often from the business owners

* Get feedback often from the developers

* Get feedback often from the users

And act on that feedback.

I argue that's actually a misconception of many scrum practitioners. It's not really "get feedback often", it's "get feedback early". "Often" is just a bad approximation of that. The difference is most obvious with retrospectives - if you just do them often they feel like a burden. What you want is to get early opportunities to improve .... but that's not necessarily through a very frequent retrospective! You have to let things crystallize a bit, so that people can observe the effect of process changes & give accurate+reasonable feedback on it.

Sprints are a shit idea and need to die a horrible death. The number of times we've had to break up some functional requirements for no reason other than to meet some stupid concept isn't funny ultimately it's a waste of time in itself

Are you saying you have projects that show 0 progress of any kind after 1 month, but still succeed later? What is happening in that first month?

Laying the foundations. Doesn't look like a house even after you've done it.

Exactly. You need the end-to-end backbone working so that you can start adding end-to-end user-visible behaviors on it, a few at a time.

Research? Experimentation? Foundations?

Pffft. We're talking crud apps here. Has any innovative software ever been developed in "sprints" using "user stories" and "story points" with a "product owner" and a "scrum master"? I doubt it.

Yeah, I've been on a couple of those. It was XP, technically, not scrum, but we did sprints and user stories and story points, and we had a product owner, and we had a guy who was de facto the keeper of the methodology. It worked really well, too.

And no, it wasn't just crud apps. It was a distributed security auditing tool. Yes, it had a database component, but it was much more than that.

It's best to break up user stories into small vertical slices and implement them within a single sprint so that you can get early feedback from the customer. That's a great way to uncover misunderstandings about requirements, even though it might seem less efficient. Optimize for rapid value delivery; a little wasted time is acceptable.

That or having to estimate work based on your sprint. This is a 130 pointed task? Oh we only go up to 8.

I'd like to add priority next to progress and problems in the second item. Being able to pull things in and out of planning is one of the biggest advantages over waterfall.

I can probably agree that sprints are usually more realistic than old school waterfall (arguably it depends, like all things) but why do we feel the need to perpetually sprint?

A simple kanban board seems to give all the same benefits without the constant pressure and weekly death march to meet the end of sprint commitments.

Because a simple kanban doesn't have any scope/goal, it's just a disorganized TODO list. A sprint/milestone is a way to set goals for the next 2-4 weeks. At the end of the iteration, you redefine new goals according to what would bring the most values to the clients at this new moment T.

If the sprint is not finished, well it's not a big deal. You move the tasks back to the backlog, or in the next sprint, or delete them if it doesn't make sense anymore. And you decrease the number of tasks in the next sprint. You shouldn't feel a constant pressure to finish sprints if the velocity of your team is taken in account correctly.

"Because a simple kanban doesn't have any scope/goal, it's just a disorganized TODO list."

Not everything has to be encapsulated in the TODO list. I mean, a Jira backlog is also just a TODO list.

To be fair, the simple kanban doesn't stop you from creating a scope/goal, you need to generate your TODO list somewhere, which isn't any different from sprints, but it's less rigid when it comes to the deadlines.

More to the point is, setting sprint goals is defacto pressure which many people and orginsations are poor at handling, and we can largely avoid it by not having people doing or managing the work care about end of sprints, but just that the tasks are scoped and are of a reasonble size.

The business benefit of having a longer planning horizon is that it enables making some commitments outside the agile team. In the real world sometimes that's necessary. A sprint cadence also helps ensure that the team does real retrospectives rather than putting those off. But certainly Kanban can work as well or better in some environments. Pick what works for the circumstances.

I definitely feel that once something has gone into "maintenance mode", where most of the work of making the project exist is done, then Kanban can be much better for organizing work.

Sure maintenance engineering is usually a good fit for Kanban. If a high priority defect report comes in you don't want to have to wait two weeks to include it in the next sprint plan. Just move it to the top of the backlog and fix it tomorrow.

For larger products with multiple teams working on the same code base it can even work to have a mix. The feature development teams follow Scrum (or something similar) and the maintenance teams follow Kanban.

It's worth noting that Scrum does not have sprint commitments: https://www.scrum.org/resources/commitment-vs-forecast

Another observation I have had, it provides much clearer and realistic progress reports to management. You can track the normalized points per day executed by the team to see their overall velocity. You have clear check points about what has been accomplished (which is why a shipped product is critical, it removes any chance for something not to meet DOD)

On the dev side, I have never attended so many meetings. Technical debt being addressed is generally against the feedback loop, unless the PO/Leads of the team make it their first priority. Grooming meetings are a mix of people who care, those who don't, and vague stories. To save time, any new story got sent to one of the devs for a sniff test before grooming, to help ask critical questions early. Typically, the request is reasonable, but may run into a contradiction of the system.

I have also found that, forcing scrum (or waterfall) on a product that is running at a difference release methodology is horrible. Got a customer that needs a new thing built by a specific date? That won't fit, unless the date is flexible and customer stake holders can be deeply involved in the process. Waterfall at least forces the customer to define the project up front and allows for calling out changes to the plan and thus changes to the scope.

As with all the above, this sits on how skilled your project manager/scrum master/product owner are at their jobs. Anti patterns abound.

I completely agree. I don't get why people try to strictly follow the methodology (and then complain about it) instead of just taking the core of it and apply what work for them and their company.

I've a SCRUM master certification and still, I follow only what's good for us.

It's totally fine for me to add a task in a current sprint. If you care about finishing the sprint, you just move a task of same points back in the backlog.

It's also totally fine to allow the technical lead to add his own tasks to the sprint. You can do 80/20 for instance (business/technical values). It's not going to kill your business and will make your developers happy (SCRUM is about people, not process, right?).

Problem is, that's a recipe for management ignoring all the stuff that gives developers power and agency, and taking all the micromanaging things.

My best experience with Scrum was with a team that was willing to completely overhaul our weekly process if we needed to. We finally settled on a structure pretty different from the general recommendations, the most significant being we had no daily standups. They felt kind of useless, one guy on the team particularly hated them and pushed for us to do a sprint with no standups. So we tried it out once and kept it that way permanently, turns out our team really didn't benefit from them.

When the rest of the company saw our productivity, they moved every other team over to Scrum, hired a Scrum coach, etc... And it didn't work because they were extremely strict about the "process" and any changes to the process were like arguing against the bible. They even made our team begin doing daily standups every morning again.

I'm not certified or anything but the entire point of Scrum to me is that you frequently re-evaluate your situation and team and adapt to that. Everything else is just a good baseline to start with.

I feel like the books and consulting came from the fact that Scrum, while it can be explained in a paragraph or two, is very hard to reconcile with the idea that what the business wants is for you to be able to guarantee that you'll be "done" (and define exactly what that means) by a particular date in the future.

"This does not sell books and consulting, so it evolved into a field of its own."

Exactly. This is why it's stupid when managers get all hyped up about <present software development trend/> and decide everything needs to be shaken up based on what they learned at a seminar or heard from some consultant/"coach".

For the most part, those 3 points seem like easily understandable ideas, and have been used in some form by other industries, such as manufacturing, for a long time before they were presented for software development. Replace "PM" or "Scrum Master" with "Foreman" and you can get the picture of what activities are involved with a worker managing other workers and the work that gets produced.

There is so much over-complication with the current system of methodologies and nebulous acronyms that accompany it[0]. There's SAFe, Agile, Scrum, Scrum of Scums (recursive scrum??), RAD, LeSS, etc. It gets confusing and messy very quickly. Instead of focusing on doing the work, it's easy for managers to get swept up in the semantics of these frameworks and end up hurting the work by over-thinking and over-applying the principles on the workers. Scrum methodologies are guidelines that can be tweaked to fit the situation, and don't have to implemented if they don't make sense. Instead of thinking "Does this make sense?", the manager/business side tends to think "Well, it worked for X, so it must work for me!". Scrum is an editable template that should help eliminate wasted effort and mindless work, and if that's not the case then it isn't being done right.

[0]https://en.wikipedia.org/wiki/Scrum_(software_development)

>1. Sprints are a better way to organize than Waterfalls. I've experienced this over and over again personally, so I'm sold on this.

There are so many people who say, Agile or Scrum, respectively, do not need specs, the specs are just incremented with every sprint as the product itself, leading to software projects with undefined goals and overlong project time

I find this article lacking, because it makes all of the same mistakes typical of these bandwagon anti-Scrum articles.

Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Our product owner works closely with both commercial and development groups to build the backlog. Pressure to build good technical solutions is reasonably balanced with commercial requirements. The development team is empowered to step in and request product changes when they think it's necessary. This happens because we are a team of skilled professionals who want to deliver working things at reasonable pace, and this applies to both commercial and development groups.

There is a weird underlying assumption in these kinds of articles that implicitly seems to assume that Scrum will somehow turn a bad team into a good one. I have no idea where that comes from. A team using Scrum still needs skilled people who know how to do their jobs effectively – and that includes the scrum master and product owner roles. Introducing it into a good team can then help to reduce the impact of common software development issues. It doesn't work for every company, team, or product – but that doesn't mean its without value.

I'd be more interested in articles that talked a little about better processes that we can use. I'm absolutely open-minded about the idea that there are other legitimate and effective ways to deliver software other than Scrum, because it's obviously the case. "These are the problems with Scrum and this is why they aren't a problem in <other process>" is more valuable than "If you have a bad team then Scrum is bad".

> Despite working in a a Scrum team, I recognise literally nothing of the problems that are described.

Same. This process takes work, requires buy in by all levels of the company and needs to be fully understood including its error cases. It takes time and requires course correct and attention. Its not easy but done right it is effective.

> done right it is effective.

That is one of the problems highlighted in the article though, too. What is the appropriate level of training for a scrum master and scrum team? Should we read the Scrum Guide? Are we reading the Scrum Guide? Do we actually know what Scrum is? Do we even know that we are doing Scrum?

I am working on a young, small team, and we started with an expertly trained scrum-master about 30 sprints ago. She was so well-trained that she was promoted out of our team. Since we started, we've had about 72% turnover.

I'm the only original member of the team who is still on full-time except for the product owner... and reading this article, I am coming to find out that our product owner is not doing the job of product owner (mostly our new project manager is.)

And

> apparently it has to involve something called “Jira”.

hits me right in the feels! We have been working with one project management tool (not Jira) since the beginning, and we found another tool that we like (the dev team likes) better.

Doesn't matter what the tools are. Bear with me. The first tool is used to communicate with our product owner(s) or stakeholders, where we get their acceptance of stories, and the second tool was meant to be a place where we developers can own tasks and "blog" about our progress without adding noise to the stakeholder channels. A task list that we control. Again, neither tool is Jira.

We did a trial, and we quickly found by consensus of opinion and observation that it really helped us a lot to add this tool to our process, all of the developers were buying in! Brought it to management to get it added in the budget... really a nominal sum, but then we were told we had too many tools already and made to abort the trial.

I was devastated, but I played along. It was the wrong decision! I started using slips of paper to fill the void, a place where development issues that are not part of our product backlog can live outside of the backlog and the sprint, and now in my perception at least, we're more disorganized than ever as a team.

I believe you both, that Scrum can work well if done right, and I'm glad it's working well for you, but ... I think at least some of us definitely need to hear these stories, many of them are our own stories, properly articulated so we can understand what's going wrong in our teams.

With turn-over like that, nobody is going to be successful. What is driving the turn-over? Are team-members being moved elsewhere, or are the quitting out of frustration?

As for training for the SM (or PO, or anybody else), it's a continuous process. The CSM is a starting point, a basic level of understanding. At my office, many of us have gone on to take the Advanced CSM course. Most of us attend meet-ups, conferences, etc. It's not a once-and-done thing - nothing in a professional career ever is - if you aren't learning and improving every day, you're not doing your job.

> What is driving the turn-over? Are team-members being moved elsewhere

"72%" is really misleading... from the original team of 2 developers and one PM/Scrum-Master, the Scrum-Master was promoted to a newly formed team, and the other developer is still with us, but in a mostly consulting-only capacity, as she is focused on other projects in our team.

Nobody is quitting out of frustration. (Not yet anyway!) We've since added two new developers from other groups within our organization, and a new PM.

We're talking about a greenfield project with some inherited/appropriated/shared code from other projects on our (slightly larger) team, a mostly new dev effort, and we're approaching year 3 of development.

For a dev team this small and a project of this scope and duration, I feel like this is almost an appropriate level of turnover. We have to strike a balance between spreading the domain knowledge around, and keeping the expertise near the "most important project," which is obviously the particular one that we're working on. (/s) The big problem is training, or lack of... the SM that left our team was practically the only one of us with any formal training in terms of either development skills or Project Management. The rest of us have learned basically everything "on the job."

We've been exposed to some training opportunities for "business analyst" skills development, which is our organization's take on a little bit like "Scrum-lite" but I am not sure that's for all of us. (I'm working in higher-ed so there are a lot of training opportunities in-house. Just not sure they are the right ones. Most teams in our building just aren't doing product development, so we are special snowflakes.) I've taken some of those BA classes. We really need more technical training. We probably need a larger team too, but hiring is very difficult for us, and in reality I think we're going to have to cope with more of our team members being poached by other departments as we become more successful.

Some members of the team have participated in bootcamp-style training courses for our chosen framework. In every case, it was years ago, some time before I arrived on the scene. I have not had any of this, just some prior on-the-job experience and also have read a book or two to pull myself up by bootstraps! We're all learning on the job, and we have a conference budget so we're getting exposed to plenty of new ideas each year, but that's nothing like a formal training day where we all hammer a particular skill until we all get it, or even a sprint that's dedicated for training.

Second major problem is that we also usually don't have sprints or stories devoted to addressing technical debt. No refactor stories, basically ever. Basically all story cards must be customer-facing and represent some new, testable functionality for some functional user of the product. This part of the article also struck me as poignant:

> The items promoted in the backlog, combined with the schedule pressure set by the product owner and the business mean that the Development Team often are told how to create releases: quickly and exactly how we said. The lack of technical craft or development control means each sprint is launched as soon as possible rather than as soon as prudent, refactoring isn't done, and technical debt builds up, eventually choking the product.

When every story is a feature story or bugfix, this is what you get. When the team says "we need to learn this skill first, so we don't add unnecessary technical debt in the next sprint" and are overridden by the PM's boss and told to stick to the planned release timeline at all costs, we lose.

> As mentioned above, the lack of titles or specific responsibilities in the development team means no-one is empowered to advocate for development priorities, and also contradicts the typical implementation where there certainly are titles and hierarchies within teams

... exactly this. We're told that the development team as a whole is accountable for progress, but when everyone is responsible, nobody is. You can't call someone a technical lead and then confine their decision-making to minutia within the already-planned sprint work. That's not really how I feel about my team, but I feel like sometimes circumstances put the pressure in that direction.

This is getting too personal, but suffice it to say I really agree with this article about a lot of points.

overridden by the PM's boss

Yeah, lack of buy-in from senior management is probably the biggest single problem with scrum, any other agile framework, and probably even non-agile frameworks.

Interesting that you're in higher ed. I am as well, thought it sounds like you're at a college/university and I'm at a software company selling into that market.

That's correct! And as much as I may gripe about these issues, we're consistently ranked as one of the best places to work in tech. I believe that's specifically with respect to employee happiness. (Go figure! LOL)

Just goes to show that wherever you look, you're going to find problems.

> A team using Scrum still needs skilled people who know how to do their jobs effectively – and that includes the scrum master and product owner roles.

That is my key beef with Scrum here. I entirely agree that done well Scrum can be effective. But how it is often done is not well at all (e.g. the two day Scrum master training course.)

I'm criticising Scrum as it's widely implemented and how that is poisoning the groundwater for all agile methodologies.

And definitely I'll get on to how other processes can be better.

> There is a weird underlying assumption in these kinds of articles that implicitly seems to assume that Scrum will somehow turn a bad team into a good one.

This assumption starts with one of the earliest Scrum pioneers, Jeff Sutherland. He writes quite clearly that he doesn't care about an individual's performance, but rather a team's performance. He also talks at length about how poor performing teams can be turned into high performing ones by the implementation of Scrum.

You can agree or disagree with him on this (I'm on the fence), but it's not at all weird that this idea is found within Scrum. It was there from the get go. It's there by design.

You are misinterpreting. Scrum is designed to cure disfunctions that turn good developers into bad teams.

I recognize the disfunction. What happens is that the owner of the backlog becomes the controller of how much time gets spent on what. With feature pressure, it's all new features all the time, with no scope to address debt.

IMO, this is where a good leader (SM, tech lead, whoever - I don't mean a literal manager) advocates for sanity on behalf of the rest of the team. Mostly, this just requires somebody to say "No." every so often in the face of ridiculous demands.

As SM, it's my job to ensure that not only will the PO listen to concerns from the team, but the team feels empowered to provide that criticism. If neither of those happens, I've failed.

A bad PO will RUIN a team. I've seen them do just what the blog entry claims. I've also worked with POs who don't do any of the bad things claimed.

This is correct. The article (and grandparent) seems to quickly jump to the assumption that the members of a scrum team are mindless drones - and don't get me wrong, some scrum teams are - but they are empowered by scrum itself to have a say or two itself in what to deliver when. The PO only decides priorities, and is not (officially) allowed to pressure for time and deadlines. In return, the scrum team gives feedback in the sprint ritual about how fast they're going, relatively, in story points delivered. This is only relative to that team's own (previous) sprints.

I think the main issue is that people are doing scrum wrong, applying traditional management to an agile process.

Does Scrum itself empower individual members of the development team? Saying it’s on the developers not to be “mindless drones” and the managers to not be “bad managers” may be true but doesn’t really refute the article’s point. Maybe you have Scrum disempowering developers and (at the best companies) other forces, including other practices and processes, empowering them.

For example, Scrum says responsibility for operations and testing are to be shared responsibilities; you don’t have an ops team or a testing team, or titles, or recognized responsibility. You might have a de facto ops team, but those are just some individuals who have chosen to carry pagers right now. I’ve seen things like this play out and been puzzled by it. I didn’t actually realize until reading this article that people have been giving talks and writing books saying that “subteams” are bad, but it makes sense now.

The point being, not having officially recognized responsibilities is a form of disempowerment.

not having officially recognized responsibilities

I feel like that's a bit of an overstatement. While scrum advocates for shared responsibility, it doesn't demand no-titles, no-roles, or no-passions.

It's all about ensuring the entire team possesses 'T' shaped skills. Depth and expertise in some areas, but still generally knowledgable across all areas. My test engineer doesn't write much code, but in a pinch, she can. My PO is fully capable of "running" the team in my absence, as is the test engineer. All my developers know the full DevOps pipeline and can contribute to it, though none of them are DevOps engineers by title or primary responsibility. And I'm an ex-developer-now-manager who can do a bit of everything, though these days I'd rather go to meetings and play office politics so my developers can do their thing.

Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;

Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis

Maybe T-shaped people are required to make Scrum work, or vice versa? Like if you are running a restaurant and your company process says “there is no distinction between waiters and chefs,” then your waiters need to be decent cooks, and your chefs need to be personable and presentable. “Passion” can be a liability in this environment, for example being passionate about great food or great service. The lack of specialization doesn’t seem directly related to how to do great work, or be really happy at work.

Thank you for being the kind of owner I want.

I recently quit a job because I was the only one on the team "capable" (or that felt confident/comfortable) saying "No."

As a "devops" (loosely defined on our team) I felt my focus was uptime and error rates which sometimes is counter to new features (what managers want)...

While that's great, the boss is still the boss. I don't feel that any kind of parity can really occur when one party has the ability to pull the, "Do it this way and in this time or I take away your ability to feed and house your family," card. And while the vast majority of managers will never come out and say this, or try to not imply it, the implicit threat is still there.

> the owner of the backlog becomes the controller of how much time gets spent on what.

Then it's no longer Scrum, correct?

I mean, if you want to do the "No True Scotsman" thing, sure. But I think it's really counterproductive to handwave away a lot of the common problems that occur.

While it was a genuine question, I don't think the "No True Scotsman" fallacy applies at all, since that refers to subjective interpretation. IIRC, one of the objective rules of Scrum is that estimation of tasks is done by those who are to do them. If that is the case, and the owner of the backlog is estimating tasks, then it would appear that Scrum is not being practiced (or only partially being practiced, which may as well be not at all). I'm not sure how you interpreted any handwaving from a legitimate question, but I do agree with the point in general.

And I don't, because it detracts from one of the main cons against Scrum, in that it's basically a huge amplifier for crappy management, and offers absolutely no protections against it.

To hear about better processes, you'd have to time travel back to the 90s, go thru PMI training, work with experienced project managers, earn your sergeant stripes.

No, it's the other way around: those arguing against SCRUM don't have to tell their reasons (bad experience suffices), but SCRUM proponents must come forward with logically sound and coherent arguments pro-SCRUM in the first place.

For something that prescribes how to do everything, like Scrum does (e.g. you need all these meetings, this person does X, this person does Y, teams have to be cross-functional, no specialists, etc.) I think it's more than fair that the burden of proof lies with the proponents of that methodology.

Another way of putting it is that there are many good ways of doing project management, as many good ways as their are unique (team, circumstance) pairs.

Most people have an intuitive understanding of why some very low-overhead, low-formalism, "just get stuff done and be reasonable" workflow has worked really well in some specific (team, circumstance) combo situation.

If you want them to override their experiences with how those ad hoc, customized management processes worked well, and instead believe that a company-wide, one-size-fits-all approach that removes tons of workflow autonomy that could just be left up to separate teams to customize for themselves, then you absolutely have to have extremely convincing answers to address widespread bad experiences.

What if scrum proponents are busy having successful experiences, but are open to an argument convincing them that they are not?

Having worked at primarily at “informally agile” software companies in Silicon Valley (and I count Google as one), I see an important bit of truth in the article that Scrum ideas have become the embodiment of agile, and ideas from Scrum that may not make sense in isolation have become standard practice in software development and are somehow seen as the alternative to “waterfall” development, even if they have nothing inherently to do with waterfall vs agile development.

For example, it’s never made sense to me to have a powerful product owner while treating the development team as N interchangeable workers who may have “areas of focus” but have no roles, responsibilities, or organization among themselves, smearing out any sort of power or responsibility for technical quality like butter spread on toast. And yet, the fact that Scrum says to do it makes me wonder if that’s why everyone does it. Reading Scrum’s idea of a development team made me facepalm.

I don’t think the article is attacking a straw man that Scrum can turn a bad team into a good one. It may be pointing out that Scrum is regularly used to turn a good team into a bad one. Because everyone wants to be “agile,” even if they never use the word Scrum, they are implementing bad Scrum or cargo-cult Scrum by default.

Where has management forced Scrum onto a team that was already successful?

Every company I've ever worked at. It's how Bozo managers get points from their Bozo managers. "I can save you a lot of money by converting to Agile / Scrum."

What it really means is, "I'm not really responsible for making deadlines anymore."

I think very, very few articles actually want to touch on the reason that Agile/Scrum goes bad: Lack of management/client buy in. If management or the client aren't going to work in an agile manner as well, then that just puts the devs at a disadvantage, and makes for a crappy work environment. Devs lose any agency they had in terms of what to work on, and as a result become disgruntled and stop caring about the work.

My initial thoughts...of course Scrum disempowers developers but that's not what the article is about. I see a hyperbolic title and a bunch of complaints about how "in the real world" things work differently (entrenched opposition will always sabotage progress).

What is a manager but someone who has control over the controlled? I'm surprised with so many ppl nodding their head at this list of complaints about bad software processes at bad companies, masquerading as analysis. If you think it takes more than 2 days to learn _how_ to be a Scrum master, you don't understand the role. It's not complicated, difficult, and time-consuming enough to require a singular employee...unless your process is already screwed up. Good luck finding whatever magic bullet you think will save you that isn't Scrum-based teams.

My biggest beef with Scrum (and why I think it's a scam) is that they renamed everything, all the processes.

Historically, there are three important sides, and roles, for each project. Product management - takes care what the customer wants to have build. Project management - takes care of what is delivered is on schedule and that there is enough material/personnel to build it. Architect/engineering lead - takes care of whether the thing is technically feasible, what technologies are used and what technical trade-offs are made.

And there was a vast literature and discussion about how these three sides affect the result of the project, and how to solve these problems.

Unfortunately, Scrum, renaming everything, acts as if the history of project management doesn't exist. And if you forget history, how are you supposed to learn from it? That makes it easy to sell snake-oil. I frequently hear, for instance, that scrum master is not a project manager, despite him having some responsibilities in this area.

And as the blog post also expounds, there is no recognition for these three different sides of each project in Scrum (ironically, there is some recognition of that in Scrum derivatives such as Scaled Agile Framework, for instance, modulo nonsensical renaming of the roles).

Scrum didn't rename any of them. They added the roles of scrum master and product owner but those are roles that can be assigned to people with traditional titles in addition to their normal roles.

The scrum master and PO should explicitly not also be the PM, there's a huge conflict of interest.

PM can be scrum master. I've done it plenty of times. The entire scrum team should be aligned around the same objectives so a conflict of interest is not possible. The PO is outside the team and is the only one who should avoid wearing multiple hats.

The purpose of all the jargon that Scrum introduces is to avoid naming collisions with prior terminology.

You probably have a good idea of what a product manager should be doing but someone else in a different company might have a different opinion. Introducing a new term eliminates this source of confusion.

Admittedly, all the jargon you encounter when learning about Scrum can make you feel like you're joining a cult. However, there is a reason behind introducing it.

I don't think there was anything like the kind of consensus you're portraying about what these things were called. Different shops used their own terms for things; "architect" meant radically different things from one pre-scrum shop to another, "engineer" even more so. "PM" would be used interchangeably; different people from the same company would tell you it was "product" or "project".

I don't like renaming things for no reason, but if you want a term to have a precise meaning and not carry any baggage from previous similar-but-subtly-different usages, it's probably best to coin a novel term.

There might not be a clear consensus what a given person does but there are three types of tasks or concerns on the project, as I outlined them. Do you disagree with that?

So if Scrum (or any other methodology, for that matter) wants to define a new role (to what end?), they should explain, how they are related to these concerns? What tasks that were traditionally done by the triad are supposed to be done by the new role, and why? And moreover, how are the concerns from the triad dealt with in Scrum?

That's what I miss from Scrum. There is no connection to what was before, aside from using waterfall as a straw man (it's not a methodology to begin with). It's an ideology, its own world.

The result of Scrum being an ideology is, somebody who becomes scrum master in Scrum, and effectively doing project management work (in the better case), by default, has no idea that there is a field called "project management", and that he should study that field. So they don't know, for instance, the classic like Fred Brooks.

> There might not be a clear consensus what a given person does but there are three types of tasks or concerns on the project, as I outlined them. Do you disagree with that?

That's one way to break down the set of tasks/concerns you've identified, sure - but only one. I don't think that the industry as a whole accepts your categorisation into three, or even your paradigm for which tasks do and don't need addressing in this way.

You're coming across as far more ideological than the thing you're attacking, assuming that your particular breakdown must be the canonical one when it simply doesn't have a level of industry acceptance that would justify that.

No, you misunderstand. I don't care about the breakdown, but I do care about these tasks and concerns (and you seem to agree that they exist). How to deal with them needs to be explained in the context of the new methodology, and how it relates to the old ones. That's what I have not seen with Scrum, it pretty much ignores all the history of project management as a discipline.

And actually, when I started programming professionally, I didn't think that management was necessary, and that we could self-organize and all that. But as I changed projects and bosses, it turned out, I just had a good manager (and it was a waterfall-like method, by the way).

So I think the idea of self-organization is intuitively appealing to many people (especially young without any experience), and if you have a person in the team who can naturally take each of these roles, then I think it can work (that is - sometimes). But today, I don't think it will work in general, and for that reason.

Now I recognize that, for instance, you need somebody well-organized on the team who can make sure things do not fall under the table. Or you need somebody who is process-oriented, interested in improving process. Then self-organization can work.

If you don't have people with specific traits like that, or they don't emerge as natural leaders (gain respect) in their specific areas of interest, then you need to appoint somebody to have that role. Then it makes sense to have explicit project manager, or product manager, or architect, who focus on certain tasks and concerns.

I suspect the fact that sometimes you can do without having these people designated as such can account for some anecdotal success of Scrum (or any other method - I personally had the best experience with waterfall-like approach).

> I do care about these tasks and concerns (and you seem to agree that they exist).

Not really, and I don't think the industry as a whole does either. Everyone has their own set of tasks and concerns; I don't think there's any consensus that says that all the important ones are on your list, or that everything on your list is important.

I like trilemmas.

Mine is "marketing" (biz case, price, feature set, aka what), "engineering" (cost, schedule, aka how), "QA" (owns the release).

Loosely based on the Deming-style "quality circles" used at Ford and else where.

> the product owner often works alone and the development team simply receives a stream of backlog items that need to somehow be brought into a cohesive whole

This is the root of the problem in my opinion.

I am not interested in defending "Scrum", I don't like what I know about it, in the few experiments I've been involved in with it (not by choice), I agree it was disempowering to developers, trying to treat developers like commodities.

However, I am a fan of trying to do things agilely (iteratively, figuring out what to do next in relatively short chunks without trying to plan out the next year+).

In the experiences I've had where this _worked_ the product owner was _intimately_ involved with the development team, with lots of communication in both directions, with the development team's info and feedback effecting how the product owner prioritized and determined (and changed, agilely) acceptance criteria.

The product owner had to embrace/accept that this would be a significant time and energy commitment to them, they could not be looking to minimize their time here, and had to accept that "with great power comes great responsibility" -- that they needed feedback from developers to make these decisions properly.

On the flip side, through these good experiences, I also learned that a good product owner is _so important_ -- as a technical decision-maker I don't _want_ to be responsible for determining product priorities or acceptance criteria. I want my feedback to be taken into account, but having someone else (who is good at it) be _responsible_ for it let's me focus on applying technical excellence to achieve the goals set by the PO, and takes _so_ much pressure and anxiety off of me. Especially when I can trust them to know what they are doing it and do it well (just like they can trust me to execute well).

I _do_ think the development team needs a "technical lead" in addition to product owner, not just an amorphous bunch of people "self-organizing".

A "one way" product owner is useless.

Backlog grooming is a thing [1]. In fact, I'd say after the Increment, it might be the most important thing. If developers and all the owners are not continually reviewing the items in the backlog together, clarifying them and making sure everybody understands what is being asked for and what the priorities are, breaking down stories that are too big, making sure that, yes, some tech debt gets in there, then all you've accomplished is a kind of mini-waterfall where stories get shoved to the top of the backlog by whoever comes last and then developers hammer away at them frantically at the beginning of each sprint.

> I _do_ think the development team needs a "technical lead" in addition to product owner, not just an amorphous bunch of people "self-organizing".

Scrum consistently fails because everybody thinks in terms of the "who" and the "how." Scrum books are all about the process, the daily meetings, the roles and the responsibility. This a symptom of a much larger issue here, the "technological paradigm" that pervades nearly all corporations. There's an unfailing obsession on organization charts, department boundaries, and processes.

It's all kinda silly.

As somebody who's managed too many scrum teams to remember here's the secret: don't focus on the "who" or the "how", focus on the "what." The what is all that matters. In Scrum there are certain key artifacts: stories, the backlog, the increment, blockers, and retrospectives. Relentless focus on the quality of these artifacts as documents and you will excel at Scrum. But you have to really care about the quality of these documents. Everybody, not just the scrum master, has to keep iterating over these document/artifacts until they are awesome. This means continually refining stories until people know them inside and out. Continually polishing the backlog until it shines. Making sure everybody understands exactly what will be delivered at the end of a sprint, the increment, and when it's delivered having people write feedback and rate the increment. It means investigating and documenting every single time a developer is blocked for more than 15 minutes and then making sure it never happens again.

I've worked with remote/distributed scrum teams and what I've found is that you can even throw out all the ceremony -- the daily stand-ups, the endless sprint review meetings, the endless retrospectives. When the team is distributed between London, Shanghai and Sydney and most of the developers work from home at oddish hours such meetings are impossible. But by focusing on the documents even such a distributed team can fly. So, yeah, at the end of the day this all boils down to effective communication and writing things down. Most knowledge games do.

[1] https://www.agilealliance.org/glossary/backlog-grooming/

I'm not sure if you are arguing against what you quoted from me (that I think a technical lead is neccesary, cause it is a "who"), but the reason I come to this conclusion from my experience is because technical decisions on the macro or medium level need to be decided on a fairly regular basis, and I do _not_ want continual endless consensus committee meetings hashing them over. Or a free-for-all with no coordination.

It is not only more efficient, but better for morale to have an agreed upon person upon whom the buck will stop. Sometimes when things are "everyones" responsibility they end up actually having nobody take responsibility for them. Such a person with ultimate responsibility and authority for technical decisions should be both competent and not an asshole, they should be in constant dialog and taking feedback from everyone else, and paying real attention to their concerns about technical matters.

But for the same reason you need a Product Owner (instead of just the amorphous group of all stakeholders) to ultimately take responsibility for decisions about priorities and acceptance criteria, you need a technical lead to ultimately take responsibility for technical decisions.

I think that "Scrum" doesn't have this is just part of it's attempt to commoditize developers (something I think is characteristic of "scrum" but not part "agile" generally or at it's best). "Scrum" sometimes seems as if it's designers thought there _are_ no technical decisions to be made, just a bunch of widget-ized, swappable developers churning out code to meet the requirements set by the PO. But, in fact, there are technical decisions to be made, that will effect other people's work and the product as a whole, in the short- and long-terms. Regularly.

Pretending to do agile seems to be widespread thing in our industry. There are literally no companies out there not claiming to be agile. So, the word has become meaningless. Scrum is the lowest common denominator in our industry when it comes to that.

Agile implies getting things done and getting things to market. If scrum helps you do that great. If not, ditch it. In my experience, Kanban is a step up on the evolutionary ladder. Both have issues with not prioritizing essential activities related to research, refactoring, etc. that you need to guard against. There's a difference between agile and firefighting.

One worry with scrum is the roles of product manager and scrum master. In my experience these things end up being formal job titles in bigger organizations. This is bad because they are typically on the very low end of the scale. That means you end up with the least experienced people filling these roles and a lot of corporate politics. I've seen more than a few organizations that were hiring accordingly.

My company doesn't claim to be agile, I don't think. We just allow devs to work on whatever they find interesting. If something really urgent comes up, its urgency is made known to the dev team at large, and someone always steps up to the plate. Works fine for us! Also, we don't have deadlines. Things ship when they are "good enough".

Granted, we're very selective in our hiring process, but it means things just work without much need for fancy management practices.

If any dev managers are reading this, I can say, this approach works, and you should give it a try.

A previous company I was at worked this way and it was a dream. That said, it does require very selective screening processes and maturity from those you do hire.

However, it was the most happy / least stressed I've ever been in my life. I still get beers almost weekly with over half that team. This "strategy" really built comradery because we were always talking and discussing rather than leaving comments on some Jira ticket (which we did for async or when necessary).

Seriously.... give it a shot if you can

Our weekly "why scrum sucks" post that's really a "why my company does scrum wrong and I don't know how to fix it".

Product owners push customer value. Of course. You should too. Code quality and refactors have business value. Reduced maintenance cost, fewer bugs, faster future dev. If you can't explain that to your product owner then maybe it's not worth doing. I think your big missing piece is the collective ownership aspect. Product owner gets to set priorities, but it should be a collective discussion. Every dev should be allowed to express their opinion and it's the job of the product manager to referee.

Who is the “you” here? Who is supposed to explain to the product owner that code quality and refractors are worth doing?

The real issue the article brings up is that Scrum has an individual who takes ownership and responsibility for the product backlog, it has an individual who takes ownership and responsibility for the project management, but it has no individual who takes ownership and responsibility for the non visible technical aspects of the product.

In an ideal world, this responsibility would be taken up by the scrum master, who would have technical expertise, but as the article points out, (a) scrum never states this, and in fact, hints in the opposite direction, and (b) this is rarely the case in the real world. The scrum masters are usually as non-technical as you can get.

The agile team members are supposed to write refactoring user stories and explain their value to the product owner. If the team members aren't doing that then they aren't doing their jobs and need to be trained.

Going beyond Scrum, Scaled Agile Framework (SAFe) has some specific guidance on refactoring.

https://www.scaledagileframework.com/refactoring/

This is utterly backwards.

The team owns it all - the process, the product, the technical artifacts, the code quality. If the team is looking to the PO or the Scrum Master to take responsibility for things, then they are going to fail.

The product owner is there to help the team understand what value they can deliver. The scrum master is there to help the team optimize the process. The team hopefully has developers on it who are there to help the team make well engineered pieces of code Maybe there are designers to to help the team make great user experiences. The team has specialists, but the team works collectively to deliver results.

If your scrum team has a bunch of engineers on it wondering how to get their voice heard over the product owner, you don’t have a scrum team building your software, you have a PO acting as a tech lead running a waterfall project.

> Who is the “you” here?

The development team!

Scrum is antithetical to quality. We're 20 years into this experiment? I have yet to even hear someone tell a compelling narrative about doing QA/test in an "agile" context.

https://continuousdelivery.com/implementing/patterns/ and https://continuousdelivery.com/foundations/test-automation/ would be your starting point there.

Yaya. Thanks for the links. Will review.

FWIW, I'm desperately trying to bring "TEST in PROD" style continuous delivery whozeewhatsit to my current team.

When in Rome, join the third millennium, old dog new tricks.

I still can't imagine I can get back to the 90s (quality wise). But if there's a way, I'm gonna find it.

I'm not sure where you got that mistaken idea. The Scrum values explicitly call for "shippable quality" by the end of every sprint. Other than that, Scrum doesn't explicitly define testing practices so do it however you like. But I would note that you can't test quality into a product.

Agree about futility of testing towards quality.

Source: Former QA/Test manager.

Shippable quality to me is a full regression test. That's awful hard to do in the few days a 2 week sprint allows.

Your full regression test suite needs to be 100% automated and fast enough to execute within a couple days. If you don't have that then you have a bigger problem that goes beyond any particular development methodology.

A proper Scrum definition of done requires full test automation for every user story. You can't merge code to the release branch or accept the user story until all the automated tests (unit, functional, integration, system, performance, etc) are working.

I assume you don't mean unit tests, which should never be a replacement for full regression testing.

Ya since that is essentially a deal breaker, I wonder why all the scrum consultants fail to mention that.

Automated full regression is very expensive to develop and maintain. I think a lot of people who implement scrum don't realize that they are sacrificing significant levels of testing when they implement it without a testing automation team.

To me, that's just another reason to ditch scrum.

I mean all tests — unit, functional, performance, everything — necessary to verify that a particular product build meets your customer's quality standards. Automated full regression testing is far cheaper than manual testing. If it seems too expensive then you're probably doing it wrong or failing to account for full lifecycle costs.

This is absolutely not a reason to ditch Scrum. In fact Scrum is conducive to good quality practices.

Scrum does not require automation at all. Generally speaking, it should, but full automation is folly and dependence on automation is an anti-pattern. You simply can't test everything without eyes. Usually when you automate as soon as something is built, you tend to automate what it does instead of what it's supposed to do. You're also trying to hit a moving target and will end up spending a lot of time maintaining your tests instead of actually testing. There needs to be a balance of automation and manual testing.

Full automation is not at all folly. Manual testing doesn't scale and can't practically be done on large, complex products if you want to release on a rapid cadence while keeping costs reasonable.

The only two types of testing you can't really automate are exploratory testing and usability (UX). Exploratory testing should be done concurrent with product coding, and then the tests that seem useful can be scripted as a permanent part of the test automation suite. Usability testing should be done either on a separate branch, or on the release branch with a feature toggle. It's essentially part of requirements analysis and not part of qualifying a particular build for release to customers.

While Scrum doesn't call for any particular testing approach, in practice it's almost impossible to do Scrum effectively on a large product with multiple agile teams unless you have a very high level of automation. Otherwise development just bogs down and you end up with nonsense like "hardening sprints" (basically waterfall in disguise).

It's really not possible to take stories from dev to QA, to remediation to release within a sprint without having idle cycles of either developers or testers. It's what make Kanban more appealing. The sprint boundaries can be useful guidelines, but I'd never hold anyone's feet to the fire over sprint commitments. I don't care about carryover so long as we have good rolling velocity.

It's certainly possible to take stories all the way through in a single cycle. I've done it many times and seen others do it as well. There's nothing wrong with having some idle cycles. In order to maximize economic value you should focus on the cost of delay rather than insisting on 100% productivity.

I've never seen QA not be part of the agile process. One of the hallmarks is quality-first. Stories are not done until they've passed all quality gates.

Then I need to work on your teams. I have yet to be on an agile team that did triage, acceptance testing, go/nogo.

No True Scotsman and all that, but it really was different, back in the day.

When every single failure of a methodology is explained away with "you aren't doing it right," I begin to question the methodology itself.

“80% of companies suck no matter what methodology they use” is an equally plausible explanation.

"why my company does scrum wrong and I don't know how to fix it"

Well, because more often than not, the answer is management, and there's really no way to fix bad management.

If you do Scrum like that, you're doing it wrong (I know, no true Sctosman [1], and I know, there are actually dark patterns [2]).

I wrote a whole book about "Agile Anti-Patterns" [3]. Most of the book's content is about things that many companies get wrong when they start with agile or lean software development. Because it is very easy to get those things wrong.

Yes, those problems are extremely common. Not only with Scrum - Organizations also face those problems when they try Kanban or SAFe or whatever. Because, change in a traditional organization is hard. And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change.

But those problems are not Scrum's fault. If the team has no power, it is also not truly self-organized. And the Scrum Master is not doing their job.

You could start to improve by creating awareness about the problems. Blaming Scrum may or may not be a good idea to do that - Because, some people in your org may be invested in Scrum. Some mentoring or coaching for your Scrum Masters, Product Owners and developers and managers might be a better start.

[1] https://www.davidtanzer.net/david%27s%20blog/2014/03/26/no-t...

[2] https://ronjeffries.com/articles/018-01ff/hills-to-die-on/

[3] https://www.quickglance.at/agile_antipatterns.html

And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change.

Bingo. That is the key point to me. Scrum, and other agile-family methodologies, are great when fully implemented. But what usually happens is that the higher-ups refuse to relinquish a bit of control, and stick tightly to their traditional command-and-control approach, and the dev teams are forced to do something that looks-kinda-like-scrum (or looks-kinda-like-XP or looks-kinda-like-AUP, etc.) while operating in a structure that isn't really compatible with the principles of Scrum, XP, AUP, etc.

Basically, we're forced to try and fit a round peg into a square hole because people higher up the org-chart either don't really understand agile-family methodologies or are actively opposed to truly implementing them.

Nail, meet head. I've worked in places where scrum has worked great. But most places I've worked at or heard about have exactly the problems you describe.

That sounds ridiculously similar to people hanging on to communism/socialism: "the principles are sound, it just hasn't been implemented as intended". Except, just like communism, Scrum has never and will never be implemented "as intended" because that's contrary to our collective evolutionary gifts, and against a developer's desire to find satisfaction in good craftsmanship. A project management methodology building on utopian altruistic ideals and delusions wrt people's motives is just propaganda.

I've seen it work to the benefit of everyone before (I'm a developer). It's not a pipe dream.

Yes I've also been in SCRUM projects that worked well; however, these projects would have worked well under any organization, because of the particular people on the project.

Yes, when it's worked for me, the team has also been great. What I mean, though, is that scrum was an active benefit to us. The project would've gone well with or without scrum because the team was good, but scrum was helping us achieve our potential over using other approaches (that I know of).

That also sounds ridiculously similar to people hanging on to capitalism: "The free market is the best way to run an economy, it's just that there has never been a free market in the real world."

True. Scrum is mostly propaganda. I have yet to see it work right and it's been more than 3 different jobs now. The closest was at a big corporation where they sent us all the agile training, had buy-in from management, the PMs, everyone and that was great except that high profile project eventually had PMs whose entire jobs involved evaluating burn down charts to track progress within sprints. So yeah, they actually had people who looked across all the many dev teams doing a roll-up of burn downs for management. That was totally bizarre.

Maybe what's missing in my original comment... What I'm trying to say is that there is a certain kind of organization (mostly traditional / old organizations) who would have these kinds of problems with any agile method.

And there are other organizations who can make any agile method work for them.

So, it's not really Scrum's fault when it fails (at least not always). And it's not really (or not only) Scrum's achievement when it succeeds.

As a friend of mine, Samir Talwar, once said: "To be good at software development, you need an organization that's optimized for software development. Most organizations are optimized for something else."

Anyway, if you implement a process, but ignore even the very short (22 pages) guide that summarizes the process, but instead cherry-pick what you think will work well in your org, then don't blame the process when it does not work.

As I wrote in my book: "But changing Scrum so it works within your company will not make you more agile – It will make Scrum less agile!"

I think the value I get out of Scrum, or XP, or any other methodology, is two-fold.

Firstly, it gives you a set of tools to use -- sprints, TDD, product owners, and so on -- that should work well together. To use them well, I think you both need an understanding of how each of those tools supports some idea or principle that the methodology promotes, and whether or not you think that principle is important for your team.

Secondly, a methodology gives you a starting point of how to run a development team. It's easier, although not necessarily better, to start from a pre-existing cohesive set of practices than to build a process from scratch. Especially if a team isn't experienced with many of the ideas, this is not an unreasonable place to start.

I think the key is:

1) knowing what principles your team thinks is important (low defect rate? frequency of releases? developer happiness? empowerment?). This is often hard to articulate. As time goes by, you might discover principles that were previously implicit, or you might find that the principles that are important to you change.

2) knowing how each part of your process maps back to one or more of those principles

3) having a mechanism that allows you to tweak your process over time (for instance, retrospectives), whether that's adding, changing or removing parts of your process

Scrum can be a sensible starting point so long as you're willing to introspect and consider which bits are and aren't working for you, and you're empowered to do something about it.

Not disagreeing (though not a fan of Scrum or Kanban), but can you elaborate why TDD is part of the "agile toolset"?

I've seen this claim multiple times and it's never made sense to me. I do TDD on side projects where there's not even a hint of "agile."

Agile -> YAGNI -> TDD

Agile warns against building stuff you don't need. TDD means that test provide the justification for feature work. If your feature work isn't making a failing test past, you don't need that feature work. Obviously this assumes that your tests are justified (ideally there is a stack of tests leading all the way to the end user experiment), but that's much easier to get right than justifying untested feature work.

Rapid feedback and short iteration cycles are often considered to be an important part of agile development. TDD suggests that you write a test first, and try to make that test the smallest increment that moves you forward. It feels to me that TDD is an application of the principles of rapid feedback and short iteration cycles on the level of code.

If you think using TDD improves the quality of your code, then it's also important for maintaining high code quality, since that enables some of the other agile practices, such as frequent releases.

I don't worry too much about whether a particular practice is agile or not. If you find TDD useful, then great! It's often included in conversations about agile development, but that doesn't mean you have to be doing agile development in order to use it.

Makes sense. I just see them grouped a lot as if they are a "required dependency" for lack of a better phrase. Thanks

One would expect Scrum to disempower developers. After all, it is a management methodology (yes, I know some will protest at this label), and it emphasizes those things as a result. Any resemblance to software development methodology has long been lost, if it was ever there at all.

That said, an entire industry has emerged to sell this methodology, and it is supporting a vast array of jobs: everything from those selling the certifications, to the software used to track developers. There are too many vested interests now, and no company wants to admit that it burned through thousands of dollars, with dubious results, to "train" managers and subscribe to the usual software bundles.

I expect the comments here will also have the usual comments about how Scrum is great, and everyone who is critical of it is just doing it wrong.

On contrary I found scrum to be empowering for developers at least in my organization. Earlier, we used to have Technical Manager who provided estimate for a feature/project just based on his gut feeling which often was challenging and not feasible. But then developers needed to burn midnight oil to achieve the targeted release date. It often put enormous pressure on highly talented and competitive developers who had to cover up for less skilled developers. Now the development team is empowered to give its own estimation considering all factors. Mind you, in can lead to overestimation, but then we have experienced Technical Lead working also as a scrum master and individual contributor who is there to correct the course.

In general scrum will work best when 1. The product owner is from technical background with enormous experience under his belt in product development/architecture. The Product owner does not work alone in silos to create backlog but interacts with development team regularly to refine the backlog. In our case, the product owner is someone with 20+ years of experience who has worked in roles like developer/architect.

2. The scrum master is also highly technical person who has been working on the product for several years. In our team, the same person wears different hats as per the need like scrum master/technical leader/individual contributor.

It may not be exactly as per scrum guidelines but worked fine so far for us. Ultimately we need to look for good practices in each methodology and bend it as per our needs.

The teams I've been on that just 'jive' usually start with some process framework but then evolve to just work well together.

There are strong philosophies in Scrum and Agile that should be kept as guidelines. The key is being agile (lower case 'a') so you can adapt to changing priorities. Continuous Integration/Continuous Delivery go a long way towards empowering developers.

Two ways to tackle technical debt in projects:

1. Tech debt sprint. If scrum master and product owner can't get onboard then they need to realize somewhere in the near future, a feature they want will either break things or take forever.

2. Break up tech debt into small efforts someone can do in short time boxes. Even do feature flags or something to make slower progress towards a goal rather than tech debt sitting in a backlog for months.

An example of a guideline is estimation with planning poker. We completely ditched estimation activities. The estimates were usually off and not good predictors of completion. The team has a cadence of ticket completion and the 'sizes' of the tickets vary some but you don't need to waste time estimating. Developers (humans) are horrible at estimating. Having a good PM/PO set expectations with the business helps.

I would say that estimation isn't so much about predicting completion as understanding hidden assumptions in the team.

We sometimes find that engineers have entirely different concepts of how a particular feature or change needs to be implemented. Estimation – planning poker in particular – is a great way to reveal that and start exploring what the reasons are.

It is a good facilitator of that conversation but you don't need to do estimating to have that conversation about implementation details. Once a team arrives at common patterns of implementing things then those conversations really only need to happen for new implementations or integrations with other systems.

"At least we're not doing planning poker" was a running joke response to any kind of crazy process stuff we were forced to do on my last team.

Maybe it works better for small projects/teams, but in my experience it's a massive waste of time.

> Two ways to tackle technical debt in projects:

Disagree with tackling it as a separate activity at all - that's a way to get useless churn as you move towards an architecture you think is better rather than one that meets your actual needs. Do continuous improvement instead: improve the part of the codebase you're working on in a way that also contributes to your immediate, customer-facing task. "Make change easy, then make the easy change".

> An example of a guideline is estimation with planning poker. We completely ditched estimation activities. The estimates were usually off and not good predictors of completion. The team has a cadence of ticket completion and the 'sizes' of the tickets vary some but you don't need to waste time estimating.

You need to give enough of an estimate to let the business prioritise, and to realise when a task is too big for a single ticket. You shouldn't spend a lot of time on estimation (frankly I struggle to imagine how your planning poker ended up taking long enough to matter) except when developers radically disagree, as that's a warning flag for a story that isn't clearly scoped.

> Developers (humans) are horrible at estimating. Having a good PM/PO set expectations with the business helps.

You don't want to rely on one person getting it right. Developers, like most workers, understand their own job better than anyone else; they're the people who should be giving their estimates.

We have minor refactoring baked into our definition of done, so when agile team members run across existing code that doesn't meet current standards then they're supposed to just go ahead and refactor it on the fly. Since it's part of the definition of done, it's not "extra" work and is accounted for in the user story points estimate.

Larger refactorings that impact multiple modules have to be treated as separate user stories and prioritized based on business value just like everything else.

> Scrum has become the de facto definition of Agile

That is a part of the problem. Scrum is very far from Agile. Scrum introduces processes and tools while the Agile Manifesto [1] clearly states:

> Individuals and interactions over processes and tools

That said, Scrum isn't entirely bad. Its just not what many people think it is. As a tool to change the culture of a company that has been shaped by classical project management methods for decades it is very valuable. But the process shouldn't stop there as Scrum isn't the end, its the start.

So companies which managed to implement Scrum should try to move on to more Agile practices to transform their culture over time.

[1]: http://agilemanifesto.org

The Scrum process is a set of tools to push individuals into interaction instead of hiding from each other.

Yes, and sets aside a lot of time for them to interact (read not get things done) for no good reason.

I need interaction maybe 5% in my week. Anything outside of that is just goofing off. Oh and email works great for that sort of thing (interaction, not goofing off).

I've had a lot of success working with teams that use scrum practices and agile values. Many team members (like several developers and testers) have actually gone on to become scrum masters themselves at different companies. The feedback I've gotten is that it's an empowering way to work - you choose your commitments, team aligns around a goal, priorities stop constantly changing, teams make time to improve the things that slow them down, etc.

It's hard for people to go back once they've seen it work. The people that I've worked with have said that when they do move on to other companies they didn't realize how helpful it was until it was gone. It can seem like some bullshit, I get it. It's change. It's not a perfect model. Also, when leaders or teammates behave in a command-and-control and uncollaborative way, it's a lot less fun.

Biggest personal challenges: connecting team members to real clients, integrating UX (need more people and up-leveling of team members), too-stable of teams (I like forming around new ideas and the excitement of that), being distributed, the language (Scrum Master - really?!!?), perscriptive agile peers

What’s that quote from Elon Musk - process is an excuse for large companies to keep mediocre talent?

Put enough smart people in a room and they’ll figure it out. Scrum isn’t any worse than Kanban or ‘pure’ Agile or Waterfall or Lean — every system has tradeoffs and smart people learn to adjust.

No company is perfect. Tell management how the process can be improved. If they ignore you, consider moving on.

> What’s that quote from Elon Musk - process is an excuse for large companies to keep mediocre talent?

Isn’t he the same guy who’s been learning that more process is necessary to make cars safely and on-schedule? I’d be reluctant to draw any broad conclusion from one optimistic aphorism.

But the essential difference is that process applied to manufacturing is about repeatability, quality, reliability etc. where process in software is more about communication.

Eventually, maybe, a software process will be more like a manufacturing one but the variation in technologies, techniques and general fashion make that hard - even in limited areas such as CRUD web apps. I think you'd get the same outcomes with a manufacturing process as we currently get with software if every year you changed the engines, materials, electronics and transmissions.

Awesome software development process that is not about communication: testing by testers. Also code and documentation review. Also, keeping tasks in tracker and having version controll. Etc.

Code review definitely is about communication. That’s arguably it’s biggest benefit. The author could test something himself, but code review facilitates a conversation and keeps people on the same page.

My experience is that people often can't test what they've been doing by themselves. They've got blind spots and assumptions that they can't see. They have a mental model for how a feature is supposed to work, and they test that mental model, but they don't test outside of that model.

Yes, this. Programmers are supposed to test their own code. And write tests. You are not supposed to have bugs for what you thought to test.

Tester is for independent check you forgot about or did not knew about. Tester is so that you don't stop testing your code due to too much confidence.

Without testing, programmers tend to not have feedback on bugs, tend to think they don't have them and then tend to produce more bugs in the long term. Not because they are lazy or bad, but because they are normal humans.

Processes in software are also for quality, reliability and repeatability. Good communication is just one mean to support these goals.

Has he really been learning anything at all?

Maybe he has a problem in finding smart people in sufficient quantity, so he has backtracked to the "process".

You pretty much too the words out of my mouth - I was talking with someone about this just yesterday. I suspect that when interfacing with 3rd parties that are over-burdened with inefficient processes it means that he/they have to stoop to their level and dumb down their production line to work with said party.

I'm curious why you would think this? Surely every other auto manufacturer deals with the same suppliers? I can't imagine Toyota would be overly pleased with inefficient suppliers

I think it’s more that business owners love the idea of hiring half as many workers and paying them 40% more but that doesn’t make it realistic.

Larger teams and process are really about scalability and robustness, because even high achievers have bad days, can only focus on one thing at a time, etc. If you’re running that lean you have limited capacity to handle anything unusual. It’s the same reason why the only way a 10x developer exists is if you compare them to a really unqualified, poorly managed group – almost nobody works on a single well-defined problem in isolation.

> Put enough smart people in a room and they’ll figure it out.

Or start a religious war about something or other (which language, framework, architecture, etc). Efficient self-organisation is far from inevitable.

They will figure that they need process if they want consistent quality. Really.

Besides, smart people still have egos, personal ambitions not lined up with project, biases, weaknesses, personal antipaties and make mistakes. Good process with accountability and responsibility makes wonder with all those.

Elon Musk is allowed to be slightly arrogant, but most organizations work in the opposite way: process allows them to grow by making mediocre talent productive, instead of remaining small because they are limited by what a handful of very talented people can do without process.

And the non-mediocre talent pool is exceedingly limited, and fickle. They jump to the next opportunity faster than your business cycles.

You might be thinking of Reed Hastings: "The more talent density you have, the less process you need."

All large organizations — including Tesla — are composed mostly of mediocre talent. This is mathematically inevitable. Furthermore "talent" is a myth anyway.

https://www.newyorker.com/magazine/2002/07/22/the-talent-myt...

OP here: lots of people have written about problems with Scrum (e.g. https://news.ycombinator.com/item?id=16892307 ). I'm trying to take a bit more of a systematic, longer, researched and justified view of things, so any feedback is very welcome!

OP do you work at my company by any chance? This is scarily accurate.

What I've mostly noticed is that when people show up with cynicism or actual anger towards Agile-with-an-A, perhaps nine times in ten, Scrum was involved (edit: though this might be sample bias, as Scrum is by far the most popular methodology).

I'm sure it's working really well for some folks. A large fraction of the magic of any agile system is the folks involved and their familiarity and experience with it. I work for Pivotal, our wheelbarrow is XP with Lean trimmings. I've seen it up close for 4 years in both consulting and large product development and -- summarising -- it works.

But no small part of it working is the context. Our context is that we hire carefully and that the entire organisation is interested in, and supportive of, the way we work. It is fantastically easier to do agile well in an environment where it is already done well (which is why we ask our clients to come work in our office).

If I had to pick the most destructive part of Scrum, it's the sprint commitment. Yes, it's called forecasts now, but folks are held to it anyhow. All it does is create a dynamic which generates either waste or burnout. Software should be releasable at all times, not once every two weeks. New features should be presented to a Product Manager as they are done done, not according to what is an essentially coincidental cadence chosen because two weeks is easy to mark on a calendar.

At Pivotal the closest we came to sprints was setting up a quarterly release cycle for our flagship product, PCF. The first few were a mess and we massively overshot our planned dates several times. We switched to something much closer to our normal way of working: release trains. Every quarter we make a release. If a component product has a feature ready at that time, the feature gets shipped. If it doesn't, it doesn't. And that's that.

We already have a lot of our customers who've adopted automation to update their PCF platforms for patches on a rolling basis. My fond secret hope is that one day, we'll be able to drop the quarterly release cycle as well and just ship things when they're ready to ship.

> If I had to pick the most destructive part of Scrum, it's the sprint commitment.

I've organised many XP teams that regularly hit our sprint commitments virtually every time. The times when I've found it problematic to hit sprint commitments were due to the following:

- Sprint was too small. 1 week sprints are awesome, but they are extremely difficult to hit. I run 2 week sprints if I can manage to get people to agree. It can also significantly reduce planning overhead.

- Stories were too big. Stories should have a median delivery time of about 1-2 days for a 2 week sprint. The occurrence of 5+ day stories should be in the 1:100 range. High risk stories should always be arranged first in the sprint so that even a 5 day story doesn't blow the sprint out of the water.

-Stories were ill-defined. Goes together with the previous point. If you have a really high variance on your stories, it's probably because of this. You should have a "backlog grooming" session once every 2 weeks. At that meeting, you go over any new stories in the backlog and any stories that might make it into the sprint commitment. All developers should attend the meeting. At the meeting you decide: Do you understand what the story means? Could you start coding the story today? Should the story be broken up? It helps if project managers are not in this meeting -- they just respond to the feedback after the fact. Only stories that get the thumbs up, make it into the sprint commitment.

- Stories did not have acceptance criteria. Similar to the above, but more specific. Everybody might feel they understand what to do, but if you can't answer the question "How do I know when it is done?" then it isn't a story.

In the above cases, you can fairly easily fix the problems and still have sprint commitments. I have also been in some situations where I think sprint commitments didn't match the team. For a variety of reasons, I really like sprint commitments, but it is a bad idea to stick to it if it's not going to work. Here are some situations where I've had problems:

- Developers had many disagreements about how/when to merge code. They would take unpredictable amounts of time to merge code. If pressured to merge in order to hit targets, conflict would eventually erupt in the team.

-There was a young team that did not know how to relax when there is a deadline. Sometimes they merged inappropriate code just because they are afraid to be the one on the critical path. Sometimes the cut corners for the same reason. If you can pair program, it can really help with this.

In these cases, it's a matter of training the team. It helps if you can keep the team together for a long time and if you have a manager who isolates the team from a certain amount of surrounding politics. But sometimes, for a variety of different reasons, it isn't going to work. It's not bad to reach for something else at that point.

Sprint commitments can be really beneficial in my experience, but it's one of those things that is the result of having a high functioning team. It's not necessarily the way to make a high functioning team.

How do you organize acceptance criteria? Is it language that has to be added to every story?

Every user story should have acceptance criteria (confirmation). Otherwise how will you know when you're done? One common technique for organizing acceptance criteria is to write them in user voice form: "As a <user role>, I want to <activity>, so that <business value>."

https://www.scaledagileframework.com/story/

Every once in awhile we'll get someone to actually do that. But most of the time the verbiage in the story summary is the acceptance criteria and if there's a problem understanding what is expected, the team lead is the go to person.

I was wondering if there's a lighter-weight way of specifying acceptance criteria, or a framework for deciding which stories need additional criteria specification.

The Product Owner is accountable for distilling user requirements into proper user stories, including acceptance criteria. (Other team members can help with that but the PO is accountable.) POs who don't do that consistently need to be retrained or replaced.

And the Scrum Master has to be a gatekeeper. During sprint planning if a user story lacks proper acceptance criteria then it stays in the backlog for further refinement.

Yes, I think this is exactly right (not just in what Scrum/XP says, but also in how it has to be). Separating that role is super important and is potentially one of the friction points in transitioning from a more traditional setup (as evidenced by TFA). In my experience, it is also very, very important that the Scrum Master is not the manager of the team. It has to be someone whose accountability is to the technical success of the team as distinct from the delivery of high level objectives for the team. In a more traditional setup that would be someone like a team lead, senior dev or even a system analyst. XP doesn't define this role specifically and it is probably a weakness -- I've done it as a coach, but usually I appoint someone on the team to do it.

Also, interestingly, I've often had project managers who refuse to do the PO role (I usually call it the "Customer Proxy", but it's the same role). In those cases I try to appoint someone who is accountable for writing stories. They consult with the project manager for the higher level "vision" (but in practice the project manager does virtually nothing -- a state of affairs which they are usually quite familiar and comfortable with, unfortunately). Prioritisation of stories is done by the development manager, PO and project manager (if they are different from the PO). In this case, the Scrum Master/Coach is not invited to that meeting.

To answer the original question: How do you represent the acceptance criteria? Personally, I do not like code based representations of acceptance criteria. Having said that, my entire exposure to them is working on legacy projects where they have gone badly wrong.

The main problem is the same problem with trying to maintain prose documentation of the requirements of a large system -- those requirements are at least as long as the implementation of the system. They are also at least as complicated. We've slowly created ways of organising production code to make it easier to manage. The same is not true for BDD style acceptance criteria, or even prose requirements documents.

At the beginning of my career I spent a lot of my time writing requirements documents in prose. Every 6 month release would include something like 1300 pages of requirement documents. Maintaining these requirement documents was impossible. Very quickly they get out of date and so you no longer have any description of the working code other that the implementation itself.

Based on these experiences, my attitude is that requirements (including acceptance criteria) are ephemeral. They exist for the life of the story and then you abandon them (note: I'm still massively in favour of acceptance tests and unit tests, but implemented as code that is written in a similar way to the production code -- because we have techniques for managing that complexity).

Long story short: I write them in prose on the story and appoint someone to making the determination whether or not the acceptance criteria is sufficient to add the story to the sprint commitment (as nradov explained in much fewer words than I did :-) ).

Just a quick feedback on this: several people I respect find that this works really well. I've had mixed success. For example I often find people writing things like "As a user, I want to ensure that the application never crashes, so that I never lose data". This is not specific enough and fails the "how do I know when I'm done" test. I usually prefer to list the acceptance criteria in a format similar to "When <user role> does <X>, <Y> will happen".

I should be able to use the application in the <user role>, do <X> and observe that <Y> does not happen. That's my kind of litmus test. The <business value> is super important in the story, but I don't like them in acceptance criteria because they are often too high level. This, in turn, forces the acceptance criteria to a higher level in order to match.

But like I said, some people I respect highly really like this format, so it's possible that I'm missing something.

By and large I agree with the nitty-gritty, which will show up anywhere under any scheme.

> In the above cases, you can fairly easily fix the problems and still have sprint commitments.

You can also fix them and not have sprint commitments.

Here's my one piece of feedback: It's all well and good if you look at places where Scrum has failed, but if you don't look at places where Scrum has succeeded, and offer an analysis there, the research is meaningless.

Currently it feels like you're limiting your scope of research to places where Scrum has failed. Is it any surprise, then, that your research has supported your thesis?

I think the article confuses what Scrum is and what some (probably most) companies make out of it. I agree that there are scary things happening in practice and I've seen a lot of scrumBut and scrumAnd that really endangers a lot of projects.

My experience is that this is often caused by a lack of understanding of the methodology and how it can be applied and integrated into existing structures.

Also existing structures need to be integrated with Scrum to make it work. That is, they need to be transformed to match agile workflows.

The latter is not easy. Especially not in larger companies. I am not surprised that most do not even try to tackle this.

I'm not confused :-) Maybe I don't set it out clearly enough, but I'm criticising Scrum as it is widely practiced, rather than how it ought to be done.

And yes, integrating it with the rest of the company is the biggest question, e.g. if you really are agile, what does your sales team tell customers about future upgrades?

For me Scrum is like training wheels for agile. It’s restrictive and hinders progress at any real speed, but gives you the framework to start producing stuff in an agile way. Once you out grow it there are plenty of better methodologies, include the proper agile way which is that the structure of your product management is also a component to be iterated. It’s difficult to jump straight in at that point though.

Just a shame that most teams’ processes crystallise around Scrum. Working with self described Scrum masters is painful as they’ve built themselves into a box they can’t see out of.

This is a good article, but I disagree that Scrum's major flaw is a lack of hierarchy on the development teams. I've worked on some great self-organizing teams, and they're more than equal to the product manager. They outnumber the PM, after all.

The problem only comes in an organizational culture of "whatever the boss says". In that context, teams rarely learn to self-organize. Instead, the previously existing control hierarchy stays in place. Before, developers built whatever spec landed on their desk. Now they build whatever is in JIRA. Developers in that world can't even conceive of pushing back.

It's my belief that if Scrum had had some strong counter-balance to that, like an Engineering Master, then it just wouldn't have been adopted. Scrum won out over the other Agile processes (of which there were several) not because it produced better results, but because it was the one most comfortable for medium- and large-company managers. It provided the feeling of transformation without actually changing anything important. They were doing waterfall before, which became untenable with the rise of the Internet. Now they do mini-waterfall, call it Agile, and imagine themselves kings of the world.

"Instead, the previously existing control hierarchy stays in place."

That's what happened at my place. Instead of having only product owners, scrum masters and Dev teams we now have project managers, business analysts, line managers plus product owners, scrum master and Dev team. And all of these roles have some level of authority and want their own personalised reporting.

So instead of less management we now have more.

About a year ago, we went from no-process to "agile?? I guess?"

And let me tell you, a badly implemented process is a great way to turn self-driven developers into cogs that just do what's in Jira. Getting your tech decisions questioned by non-tech scrum masters during standup, requirements that don't arrive till midsprint, inability to deploy anything that hasn't been specifically inspected by the sole overworked product owner, etc.

It's not intellectual laziness, it's a defense mechanism. You can't be emotionally invested in your work if the process makes things worse for everyone, at least not without a good therapist.

> questioned by non-tech scrum masters during standup,

Standup is for raising issues, not answering questions. Standup rules says to defer discussions to a separate meeting.

> requirements that don't arrive till midsprint,

Not scrum-specific, and scrum requires either (a) not doing that, or (b) negotiating a trade to remove another requirement.

> inability to deploy anything that hasn't been specifically inspected by the sole overworked product owner

Not scrum at all. Scrum deploys every month, as clockwork, with whatever is built so far.

Yes, these are all examples of process done badly.

Why would you let yourself get so stuck in the minutia of SCRUM? Use the parts you need and not the parts that work against you.

The value usually listed first in the agile manifesto is "Individuals and interactions over processes and tools".

Agreed. It should be about letting a team figure out the highly customized, team-specific things they need to do.

If that means getting rid of rigid Scrum frameworks, so be it. Maybe you don’t need regularly scheduled planning meetings, for example, because on a given team the planning might happen in a more 1-1 manner, with irregular and specially scheduled sync meetings that just arise organically from whatever the team’s working on.

Maybe you find that estimating story points doesn’t actually correlate with any predictive efficacy for delivery or deadlines, and maybe you find estimating also doesn’t help identify assumptions or potential blockers. So then, just don’t waste time estimating in that particular case.

Any part of the workflow, ranging from what project issue tracker you want to use to what meetings you agree to have, should all be adjustable by the team to customize for what makes that team, in that situation, most productive.

It doesn’t matter if it’s Waterfall, Agile, Scrum, or just some totally made up, off the cuff meeting arrangement with no formal name and no industry of consultants behind it. Whatever works.

To quote one last bit of minutiae: "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum."

I agree with what you're saying, but Scrum says not to modify it. That's one of my problems with it.

> implementing only parts of Scrum is possible

https://age-of-product.com/agile-micromanagement/ another interesting observation along this line; when the scrum master is a middle manager then he will micro manage the show - because that's the way he is supposed to function.

Empowering the workers is a good idea, but it is not how most organizations work.

A slightly different take on why scrum becomes micromanagement, which has always seemed revealing to me: https://www.mountaingoatsoftware.com/blog/ssssh....agile-is-...

I don't know about continuous integration; version control + automatic builds really helps to prevent the mess that you have without it. I still remember the nightmare of copying sources from and to a central directory.

That’s something I’d probably put on the “good servant but bad master” category. Agree with what you’ve said, but have also seen it start to get oppressive.

(One pain point is when it is used to hide build/deployment complexity to the point when it’s no longer practical to build the thing on your own workstation...)

I agree with the criticisms of Scrum on the whole. However I find it bizarre that this article and the other one it links to (which quotes Milton Friedman, which ought to be enough to raise eyebrows by itself) crticises organisations which market themselves as non-hierarchical (or in the marketing lingo 'holacracies') when they clearly adhere to hierarchy if you think about it in any depth, just a badly organised one.

Edit: And I guess my real point here is that Scrum doesn't usually work because the development team as a whole has no way of pushing back on decisions made by the overall business hierarchy unless they just go tools-down.

Then it goes on to crticise Valve for not delivering HL3, despite that clearly being a successful business (and one where Gabe has over 50% of the $2.5 billion equity valuation... non-hierarchical, sure, whatever you say) - perhaps all of this emphasis on shipping products as fast as possible and no emphasis on the service and the interests of staff is the real problem here.

Yes I thought the jab at Valve was a cheap shot; very poorly supported.

I LOL'd at this

"Valve is the other famous poster-child of radical freedom. And just as soon as they release Half Life Episode 3, I'll be happy to take lessons from them on getting software delivered."

I wouldn't fault it for lack of technical craft, that's not a specific statement in the original manifesto, except loosely maybe "working software". Largely forgotten now since more than a decade has passed, but even the poor implementation of Scrum has helped shut down the RUP hyper-documentation madness, massive unshippable releases with hundreds of bugs, etc.

When trying to explain "Why agile?" to new devs out of school, I struggle "Well... it helps to have been through a soul crushing waterfall deathmarch. If you read the manifesto after that, you will start to weep for joy." But they don't really get it.

So i could argue that even when badly done Scrum has improved the success rate and business satisfaction across the industry. Every couple of weeks the business gets some new functionality and the devs get feedback. Great! But I would agree, it's been long enough with Scrum, I'm ready for the next evolution in this story.

Much of it does also depend on the type of team, product, environment so that scrumbut customization seems nearly inevitable in my view.

Agree we need a way around the short-sighted prioritization, we've overlain some classical PM roadmap concepts to make sure we also chip away at longer term initiatives and debt.

In part one of this series (https://www.lambdacambridge.com/blog/2018-05-how-scrum-destr...) I explain how technical craft was key in all the agile methodologies, except Scrum. So I think that was part of the thinking in the original manifesto, but not expressed at the time (fish don't perceive water?)

I suppose you're right that Scrum is better than waterfall deathmarches, but I hope we can do even better.

You assert that technical craft was key I think by inferring the bent of the associated methodology of each the people involved?

I don't agree, I think the main aim of agile was to solve the extreme dysfunction with the business-side and non-technical people, and there it has succeeded. (This is perhaps also reflected in your observation that XP interest has ebbed while scrum continues to climb in popularity.)

Have you had a look at the context inthe history statement in the manifesto: http://agilemanifesto.org/history.html

Quotes from that: "At the core, I believe Agile Methodologists are really about "mushy" stuff—about delivering good products to customers by operating in an environment that does more than talk about "people as our most important asset" but actually "acts" as if people were the most important, and lose the word "asset". So in the final analysis, the meteoric rise of interest in—and sometimes tremendous criticism of—Agile Methodologies is about the mushy stuff of values and culture."

"For example, I think that ultimately, Extreme Programming has mushroomed in use and interest, not because of pair-programming or refactoring, but because, taken as a whole, the practices define a developer community freed from the baggage of Dilbertesque corporations."

Fair enough, I agree that avoiding the baggage of Dilbertesque (great word!) corporations was key.

My point was just that all the methods except agile had explicit technical requirements. XP required TDD and pair programming which was incredibly extreme at the time (and still is fairly out there).

These were people meeting up at OOPSLA. They were programmers' programmers. I absolutely think craft and technical quality was important to them. I think it was so intrinsically important that they didn't express it clearly in the manifesto.

But I could be wrong; I wasn't there!

What are these technical priorities that are being ignored by your team?

I know some examples of cases where the development team was performing poorly which led to a bad experience with scrum. The symptom is when the development team asks for stories to refactor some code. They don't want to add any new value to the system or enable work in a different area: they've just made a rats nest out of the code or it doesn't live up to their expectations or guidelines. The cure for that? Set coding guidelines (and not just the syntax formatting variety: be hard and opinionated on initialization, patterns, and language features), mentor your team to refactor code after they've got it working and made their tests pass, and encourage developers to leave code in a better state than they found it. Also ensure that the business stakeholders and product managers are not setting unrealistic timelines and expectations. In time you'll find fewer requests to create backlog items to refactor code.

What else is there though? If your product and team leads are not concerned with security, performance, or other important factors you need to make them aware... that has less to do with scrum and more to do with good communication.

Scrum is just a simplified process for applying some of the principles behind lean manufacturing to software engineering. One of the core principles of lean is - minimize work in progress (WIP). Sprint's are just a way of minimizing WIP.

Why minimize WIP? Because WIP holds the risk that you're building the wrong thing. In manufacturing this might be using flawed parts that won't get tested until later in the process or it might be building inventory that you ultimately can't sell because the market demand has changed. In software WIP risk could be a misaligned understanding of the requirements; a flawed view of what minimum viable product looks like to the target market or a technology stack decision that represents a performance dead-end. In all of these examples you want to find out if you've made an error as soon as possible because if you're wrong then all of the WIP may need to be discarded.

A smart team holding to the core lean principles should feel empowered. Arguably Scrum, in it's dis-empowering form, is just another process to help manage mediocre teams.

Agile workflow is based on the notion that software can be created thru progressive revelation. Like Moses wandering in the desert.

But, as you suggest, per the original writings, the real goal was to better manage upward, and has nothing to do with creating projects.

The alternative is what we gray beards call "have a plan". Well, as much as any one can plan for the unknown.

I think that this is a critical point to understand and it highlights why Scrum has been so successful. We know from research in the 80's, and 90's 90% of Software projects failed, due to things like poor estimates or wrong requirements or delays.

Agile/Scrum has addressed a significant portion of those concerns by introducing lean processes. This visibility has enabled the business to understands what is happening in the SDLC quickly and can reprioritize and redirect if things are no longer matching expectations.

Where Scrum tends to fail (IMHO) is that it doesn't integrate well with other business units. I think the industry needs to focus on release management (predicting outcomes) as a process to help marketing teams, sales teams, etc... if they need to know what is happening in the next quarter, etc...

Either that or everyone needs to wait until engineering is finished before talking about new features (sounds a bit like the tail wagging the dog)

Robin, most of what you mentioned in your article are true and I agree with them. I had very similar situations (conversatons may end up with "alright, this is Product Owner’s call") and I understand most of developers get frustrated about this. I had been there and I was the developer who got frustrated, but I managed to change it (yep I also agree Scrum does not teach us how and we had to figure it out ourselves) by understanding PO, influencing them about what we proposed by describing value and making a plan for win-win. It is not a fun journey to be honest, but once you are there (we are not completely there yet) your team will trust each other and work more collaboratively. I am really happy to know I am not alone and I have so much to say and share, if you are interested in it, saw my experience at https://medium.com/@ericjwhuang/how-scrum-fails-and-what-you...

Let's do a little thought experiment where we try to stay within the scrum universe, but try to solve the main problem (developers being disempowered by scrum) by modifying the scrum framework. As the author states, "So Scrum has a master, product has an owner, but no-one is empowered to advocate for development priorities." Let's add another role to scrum called the craft master. This individual has excellent technical leadership skills and deep technical knowledge. The craft master's goal is to defend what the team is doing as a craft (much as the scrum master would defend the process of scrum itself), making sure that the craft's level of quality is manifested through a Definition of Done that takes way more of a center stage than it currently does. Would this be empowering developers?

IMHO, the answer to this question is "yes".

I am on the fence. A master craftsman is awesome to have on a team, but I worry that, just as understanding of Scrum gets pushed off as the Scrum Master's problem, craftsmanship would become the craft master's problem. That's how we get "team leads" and "architects"

Sometimes - heck, perhaps most times - when Scrum is involved, some organisations are just too fscked to save. Over time, the "leadership" have reacted to market forces by imposing variations on processes, cuts, reorgs and redundancies. The result is a workforce who, even if they were given total autonomy and unlimited resources, would be unable to turn things around.

Not that these execs would see it like that. Instead, they hear this Scrum thing has worked wonders elsewhere so they wheel it in and, if it fails this time, it's clearly the crappy workers who are to blame. "Management was right about that all along."

I take other commenters' point about strong leadership making a difference. Fully agree with that. But some situations are simply unrecoverable no matter how great the team.

I encourage the author to load this post over a spotty 2G connection. I have the feeling that some paragraphs (mainly quotes) were just missing for me, maybe because of failed XHRs. Also, it takes much longer to load despite being plain text.

> Finally we have this self-organised, cross-functional, non-hierarchical, essentially amorphous development team. They are meant to be self organising, with no one telling them how to build the product backlog. However, they have limited or no say over what is top of the product backlog, pressure to deliver something sprint-after-sprint, and no-one with the authority to balance the product owner and advocate for developing with higher quality. In fact, the whole way Scrum views the development team is completely flawed given how real organisations operate.

Setting up the scene to fail, and then, surprise, it fails. Blame it on scrum.

"no-one with the authority to balance the product owner and advocate for developing with higher quality"

In a functional scrum team everyone on the team should be empowered to advocate this. In turn the product owner should be receptive to technical improvement because it is in the interest ultimately of the overall project success.

Yep, I fail to understand the problem with this. A product owner who doesn't respond to pressure for technical quality is a bad product owner – end of story.

These types of replies always strike me as No True Scotsman fallacies, which are rife in Agile & Scrum.

“No true Scrum team would do X.”

“No functional team would disempower people...”

At some point though, Agile & Scrum cannot be propped up like that.

When the same failures happen again and again all across the industry, it’s time to admit that the tool facilitates that failure.

The tool (Agile & Scrum) is the correlate here. Somehow it’s always showing up co-located with these problems, but we’re never honest enough to step back and admit maybe, sometimes, with enough evidence, correlation can be related to causation in this case.

A poor organization will find out how to fail in many processes. The problems are much deeper than at the scrum level.

Basically this.

If the ecosystem in which scrum (or any process) is embedded is hostile then it will fail. But so will everything else, in time.

This just trades one non-falsifiable defense for another.

First it’s “no true Scrum implementation would have property X.”

Now it’s “any observable badness of Scrum was just ambient badness of an already bad company bleeding into Scrum.”

> no true Scrum implementation would have property X.

That's not the point. Scrum does not say anything how good your organization is. Scrum won't fix these problems.

Thus you can have a great Scrum setup and still fail.

Of course you can have bad management and a 'true scrum implementation'.

Your mistake is to assume that Scrum fixes all kinds of management practices or that 'true scrum' also means all kinds of other things, which it does not.

It's also unlikely that specifically bad management practices are especially caused by Scrum - it might have some negative effects in some organizations - it might have positive effects in some other organizations.

Scrum is simply not sufficient to be successful - if we want to be successful Scrum might be a good tool in a certain domain, but we also need to address the other issues/topics/practices/processes. Most of that stuff is very independent from using Scrum or not.

What? I don't assume Scrum should or can fix bad management practices.

I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire. Scrum doesn't help.

Also, if Scrum is only some kind of special snowflake process that only works when applied in sociologically perfect companies, well then it's useless.

I'd rather use custom, ad hoc, duct-taped together management practices that get the job done even in the midst of bad corporate sociology.

> What? I don't assume Scrum should or can fix bad management practices.

What? Scrum fixes all bad management practices?

> I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire.

There we need evidence that it is actually so. Haven't seen any convincing data for that.

> Scrum doesn't help.

The sentence before claimed something else: Scrum makes it worse, quickly.

> Also, if Scrum is only some kind of special snowflake process that only works when applied in sociologically perfect companies, well then it's useless.

True, but that's not the case. Scrum can be used with advantage in average to good companies - but the reality is that good software product development is not that easy and has many ways to fail - for example the software could have a huge security problem, it could have architectural problems, it might not earn enough money, etc. - nothing which the scrum process will fix. There are many areas on the management and other levels, which scrum does not address: payment, office, product, market, hiring, ethics, ...

Scrum is really on a tiny framework addressing a few basic things in small team organization.

> I'd rather use custom, ad hoc, duct-taped together management practices that get the job done even in the midst of bad corporate sociology.

Personally I'd rather work in a company willing to learn how to successfully develop software in some reproduceable way.

> What? Scrum fixes all bad management practices?

What are you saying here? I was questioning your original statement that I mistakenly thought Scrum should fix bad management practices. I do not think that, and no part of that is a criticism of Scrum. The criticisms are other things. Your follow-up just seems confused about your own parent comment.

> "There we need evidence that it is actually so. Haven't seen any convincing data for that."

I've seen a lot of that evidence, in threads like this, in the original post, and also empirical evidence in my own work experience with Scrum as both a developer and a manager across several organizations of various ages and sizes. I'm not asking anyone to take my word for it though. I'm happy to look into randomized controlled studies about effectiveness of engineering teams with or without Scrum. Much like with open-plan offices, I'm confident the evidence shows zero efficacy (despite huge planning overhead costs and time wasters) for using Scrum even after controlling for whatever confounders you think are the scapegoats for Scrum's badness.

It's a good thing we don't have to worry about what you've seen as our standard of evidence for discussing this topic, and we're free to make useful written arguments and discussions, like the linked post in the OP, that also appeal to important qualitative aspects of the problem, like how developers are disempowered, or how management always misuses Scrum-related progress tracking data.

> "The sentence before claimed something else: Scrum makes it worse, quickly."

This is pedantic to the point of making me suspect you're just trolling to argue with anyone who doesn't like Scrum. Yes, indeed, two different sentences claimed two separate but compatible and related things. Shocking!

> "True, but that's not the case. Scrum can be used with advantage in average to good companies"

You're demanding evidence but then just making equally unsubstantiated claims in the opposite direction. What's to say that instances of well-delivered software you've seen weren't done in spite of Scrum rather than because of it. That would need evidence too. And particularly because Scrum requires a far-reaching and globally prescriptive implementation (e.g. do team planning exactly this way and exactly on this timeline, estimate your workload exactly like this, use exactly these meetings, etc.) it strongly suggests the burden of proof is on Scrum proponents to explain why this is better than customized, individually and organically developed workflows that teams use because they are demonstrably working for them.

> "Scrum is really on a tiny framework addressing a few basic things in small team organization."

This is abject nonsense. Even a framework that did nothing but prescribe that teams must do some form of estimation every X weeks would be hugely overbearing bloatware. Scrum goes so much further, prescribing a huge overhead of different meetings, a bunch of specific named positions that have to have specific responsibilities in teams, and overbearing principles that superficially look small in writing but really are huge bureaucratic nightmares, like mandating that all teams should be cross-functional, which is totally disconnected from business realities in many cases, especially for teams whose sole business value is highly specialized domain area.

> "Personally I'd rather work in a company willing to learn how to successfully develop software in some reproduceable way."

This presumes that there always exists some "reproducible way", and that it is one-size-fits-all for the a whole company. You're just denying the premise that customized, situation-specific or team-specific workflows could be the right way.

It's fine if you want to deny that claim as a personal preference or opinion, but you're just taking that as your own assumption, and then tacitly basing various claims about the superiority of Scrum on this built-in, hidden assumption.

> I've seen a lot of that evidence, in threads like this, in the original post, and also empirical evidence in my own work experience with Scrum as both a developer and a manager across several organizations of various ages and sizes.

'evidence' found in Hackernews posts?

> I'm confident the evidence shows zero efficacy

this will surely help with selecting evidence, given that you know already the findings.

> This is pedantic to the point of making me suspect you're just trolling to argue with anyone who doesn't like Scrum. Yes, indeed, two different sentences claimed two separate but compatible and related things. Shocking!

How about deciding what you want to say: a) scrum makes it worse or b) scrum does not help?

> This is abject nonsense.

Really? Before we have worked with RUP and Agile RUP. Compared to that Scrum is tiny.

> like mandating that all teams should be cross-functional, which is totally disconnected from business realities in many cases, especially for teams whose sole business value is highly specialized domain area.

The team should be cross-functional based on the product the team develops.

> This presumes that there always exists some "reproducible way"

This actually presumes that I identify successful practices which can be applied in many projects. We did.

> You're just denying the premise that customized, situation-specific or team-specific workflows could be the right way.

No, I'm not denying it, but when my team had success with Continuous Integration, I probably would use that in the next project - when applicable. It would also be a surprise if in a new project I would need to start from scratch to completely redesign workflows and team communication, without any prior knowledge/practices applicable.

I've worked for a few decades in software projects and in software consulting - often I was responsible for project and team setups. Often developing new stuff. I can easily imagine that other domains work differently.

> "How about deciding what you want to say: a) scrum makes it worse or b) scrum does not help?"

Both!

> "Really? Before we have worked with RUP and Agile RUP. Compared to that Scrum is tiny."

Nuclear submarines are tiny because aircraft carriers are large. And this means submarines are a good investment.

> "The team should be cross-functional based on the product the team develops."

This is ignoring reality in many cases. A team might develop something domain-specific, like a natural language processing algorithm, but then later the product requires a web service and a front-end. As a result, management requires specialist machine learning researchers to spend their time writing front-end widgets, because "Scrum says to be cross-functional" (and don't even think of saying the no-true-Scotsman reply, "but that means they're doing Scrum wrong!" Scrum leads them to that type of thinking).

In many cases, the different functionalities for a single product should absolutely not be embedded in the same team. Rather, much like in software design, it's important to separate concerns, and have teams with modular and clearly defined boundaries between their different and complementary skills. Then for a single product, parts of it will be worked on by different teams that each have specialized skill in one area, and can operate independently of each other because it's not muddied by an artificial requirement for "cross-functional" skills.

Some other times, Scrum-like cross-functionality is good. That's why Scrum is wrong to unilaterally prescribe it for every product and every situation. Sometimes it's good, sometimes it's bad, and teams need to be empowered to customize according to whatever the case at hand needs, not the unilateral model that Scrum tries to impose.

> "This actually presumes that I identify successful practices which can be applied in many projects. We did."

But then what do you say to people who have identified successful practices over decades that conflict with Scrum and are mutually exclusive with Scrum's approach. Scrum worked for you. Great. It didn't work for me.

What's your reaction to that fact? If your reaction is to say, "well then you did Scrum wrong, because it always works" then you are just denying the premise that any other solution could be possible, and it absolutely is a No True Scotsman fallacy.

Can you at least admit that some people have earnestly tried Scrum in a situation when Scrum is advertised to work, like iterative software development, and they did not "do it wrong" yet still found that it didn't work for their team?

> Both!

Strange,

>Nuclear submarines are tiny because aircraft carriers are large. And this means submarines are a good investment.

Not sure what this has to do with Scrum or the low complexity of Scrum, which fully can be explained in a small book or a week of training.

> This is ignoring reality in many cases. A team might develop something domain-specific, like a natural language processing algorithm, but then later the product requires a web service and a front-end. As a result, management requires specialist machine learning researchers to spend their time writing front-end widgets, because "Scrum says to be cross-functional"

Management actually meant: we don't want to spend more money. They fooled you.

Basic knowledge: a NLP developer is not a front end developer. Yes, you can add and remove people from teams during the runtime of a project.

If your management is too dumb or you are too easily fooled by management, don't blame Scrum.

> In many cases, the different functionalities for a single product should absolutely not be embedded in the same team.

True. But that has nothing to do with Scrum.

> Rather, much like in software design, it's important to separate concerns, and have teams with modular and clearly defined boundaries between their different and complementary skills. Then for a single product, parts of it will be worked on by different teams that each have specialized skill in one area, and can operate independently

Sure, this is how silos in big companies try to work. For small teams this is overkill.

> of each other because it's not muddied by an artificial requirement for "cross-functional" skills.

This is not an artificial requirement. Small teams with cross-functional skills make communication more effective. If you have large problems, then you need to scale that. But that is all basic knowledge.

> Some other times, Scrum-like cross-functionality is good. That's why Scrum is wrong to unilaterally prescribe it for every product and every situation.

Again, basic knowledge.

> Sometimes it's good, sometimes it's bad, and teams need to be empowered to customize according to whatever the case at hand needs, not the unilateral model that Scrum tries to impose.

Scrum does not impose an unilateral model for all projects. You can develop in all kinds of ways and Scrum might not be applicable to your domain/setup. You can even take elements of Scrum - just don't call it Scrum - a daily standup meeting can be useful in many projects.

> But then what do you say to people who have identified successful practices over decades that conflict with Scrum and are mutually exclusive with Scrum's approach. Scrum worked for you. Great. It didn't work for me.

Then don't use it. Simple as that.

> Can you at least admit that some people have earnestly tried Scrum in a situation when Scrum is advertised to work, like iterative software development, and they did not "do it wrong" yet still found that it didn't work for their team?

I already said that you can do perfect Scrum and still fail. You can also succeed without Scrum. It's just more likely to succeed with Scrum in situations like small team (10 people), product development, changing requirements, responsive customer, etc. etc.

Also if your team does not like banana, don't feed them banana.

> "Not sure what this has to do with Scrum or the low complexity of Scrum, which fully can be explained in a small book or a week of training."

Earlier you made a disingenuous comparison of the relative bloat of RUP and Agile RUP in comparison to Scrum. The relative overhead costs of Scrum compared to those other methods don't matter. Only the overhead of Scrum compared to low-overhead and low-formalism methods that deliver the same business outcomes.

> "Basic knowledge: a NLP developer is not a front end developer. Yes, you can add and remove people from teams during the runtime of a project."

Scrum, despite not explicitly saying it in any formal documents, facilitates managers in avoiding adding or removing of the right specialized people, by creating an expectation that every engineer ought to be trained as a full-stack engineer, and using language that makes it sound like every team ought to cover every possible domain.

> "If your management is too dumb or you are too easily fooled by management, don't blame Scrum."

How is this relevant? No one mentioned dumb management nor workers who are fooled by management. We are talking about how Scrum encourages and facilitates this kind of behavior, even among earnest management and fully-aware teams. It seems like more of the same No True Scotsman fallacy for you to presume it can only be caused by "too dumb" management or teams being "fooled". Yet again, in your description, the bad stuff cannot happen in a "real" Scrum setup, only in a "bad" one where people are either dumb or foolish. Defining away your problem.

> "True. But that has nothing to do with Scrum."

False, Scrum explicitly holds it as a principle that teams should always be cross-functional. Scrum doesn't allow the possibility that e.g. front-end work for a wide variety of products should be separated into a single front-end team, and corresponding backend work separated into different backend-specific teams. It advocates that all teams working on projects with front-end and backend needs should be both front-end and backend teams. This is very much a direct problem with Scrum itself.

> "Scrum does not impose an unilateral model for all projects."

This is one of the defining properties of Scrum. A unilateral choice for sprint length, format and frequency of planning meeting, details of required story point estimation, daily stand ups, required retrospective, etc. Scrum doesn't allow omitting these things when they are not useful. There is a tiny amount of customization allowed (e.g. t-shirt sizes instead of story points, or 3-week sprints instead of 2-week), but it's meaningless in terms of what a team actually needs to customize (which is stuff like dropping estimation all together, and e.g. only hold occasional retro meetings scheduled in an ad hoc way at the team's convenience, not enforced every X weeks as part of a sprint).

> "It's just more likely to succeed with Scrum in situations like small team (10 people), product development, changing requirements, responsive customer, etc. etc."

My experience is the opposite... that adding Scrum in exactly those situations just means we have to do extra boilerplate work to get the same end product finished on time, and that Scrum is not more likely to succeed than other methods.

> by creating an expectation that every engineer ought to be trained as a full-stack engineer,

This is false. Scrum requires the TEAM to be cross functional for the product it develops. It does not require each TEAM MEMBER to be cross-functional. Even 'full stack' (a concept not from Scrum) does not mean 'expert on everything'. Full stack means able to work with front- and backend frameworks for websites. A 'full stack' developer for example will not be expected to be a NLP or a ML expert. The full-stack-developer might have no idea about automated performance tests and he/she usually will not have deep UX skills.

I usually use 'T-shaped' or π-shaped as a requirement for team members. Horizontal skills enable the person to work in a Scrum team with all the added stuff (like automated testing, software repositories, task system, continuous integration, ...). Vertical skills add depths in one or two fields: backend development with Java, frontend development with JavaScript, agile testing, business analysis, database admin/programming, cloud infrastructure, etc.

Looks like you are setting up strawmans - another fallacy.

> “Scrum requires the TEAM to be cross functional for the product it develops. It does not require each TEAM MEMBER to be cross-functional.”

It’s naive to approach this in some letter-of-the-law way. Whatever you want to argue that “Scrum says” the reality of what it facilitates & encourages (which is the attenpt to push everyone towards full-stack responsibilities) is different.

> “A 'full stack' developer for example will not be expected to be a NLP or a ML expert.“

This is just not how it plays out in big corporate Agile. They absolutely try to combine specialized skills with front end skills. I work in ML & I can’t tell you how many times I see job ads for “machine learning engineer” requiring experience in React, devops tools, highly specialized database internals, etc., with job descriptions listing all manner of wishlist full stack competencies in addition to PhD-level skill in some machine learning domain. How these places keep thinking the drives and interests required for this can coexist in a single person, I don’t know, but they keep it up. Always in a “fast-paced Agile environment” too.

> It’s naive to approach this in some letter-of-the-law way

The principle of a cross-functional team is widely explained and described. Basically everyone will tell you the same story. Even Wikipedia:

https://en.wikipedia.org/wiki/Cross-functional_team

> A cross-functional team is a group of people with different functional expertise working toward a common goal. It may include people from finance, marketing, operations, and human resources departments.

The companies I work for are able to understand that.

> I can’t tell you how many times I see job ads for “machine learning engineer” requiring experience in React, devops tools, highly specialized database internals

Zero?

I've just searched on monster.com for "machine learning engineer". Hits: 300+ Then I searched for "machine learning engineer" and "react". Hits: zero.

Combinations "machine learning engineer" and "scrum": 8 hits.

I fear your 'many times' is not backed up by reality.

> "The principle of a cross-functional team is widely explained and described."

You are completely side-stepping the entire point and it's extremely disingenuous. You're acting like because the specific words in a Scrum principle says "cross-functional team" that it must mean everyone who uses scrum practices it in the most charitable, idealized way.

Instead, in real companies, terms like cross-functional team, regardless of any dictionary definition or intention in theoretical Scrum, are completely subverted for convenience of managers and business people. In particular, it's taken to mean that if a team needs more expertise in a skill area, it's fine to require training or expect self-learning in that area from existing staff, regardless of how wildly inappropriate it would be given their skill set. And because Scrum doesn't do anything about this, other than to vaguely encourage "cross-functionality", the problem shows up all the time in companies that use Scrum and is often amplified by it, with middle managers pushing back that e.g. my ML team ought to be trained in Javascript so we are "cross-functional" to write frontend GUI stuff.

When it comes to people with marketing skills, finance skills, etc., then of course they see them as separate domain specializations worthy of new headcount to grow the team's skills. But they lump all of software and information technology into a single huge bucket.

> "The companies I work for are able to understand that."

Your experience has been fleetingly uncommon then, to such a degree that it does not generalize to common or average situations, and therefore we ought to discount your experience as too much of an outlier from most of the industry.

Since you boasted about looking on job search engines for these crazy pan-everything job ads, yet you clearly did not actually look for them, let me do it for you and definitively prove you very, very wrong on it.

I searched for results containing both 'TensorFlow' and 'Scrum' on Indeed, sorted by newest, and just walked down the list of results.

< https://www.indeed.com/jobs?as_and=tensorflow%20scrum&as_phr... >

Here are some specific ads:

- < https://www.indeed.com/cmp/Thor-Incorporated/jobs/Big-Data-2... > This one contains desired skills directly managing scrum teams, IoT expertise, tons of BI database systems, tons of machine learning frameworks, among much else.

- < https://www.indeed.com/viewjob?jk=a6693cf7a3422b247&from=ser... > (This one is for a full-stack web developer that also needs experience in machine learning frameworks, cloud-based devops tools, "LEAN and Agile/Scrum", and about a dozen specific frameworks.

- < https://www.indeed.com/viewjob?jk=abe4938edc06babe&from=serp... > (This one specifically names Agile, Scrum, JIRA, and Trello, amongst also listing specific deep learning frameworks, Node.js, Flask, and .NET, familiarity with healthcare data, 5+ years of ETL experience, and demonstrated front-end experience.)

- < https://www.indeed.com/viewjob?jk=c231123cf951f128&from=serp... > (This one lists half a dozen databases, half a dozen cloud frameworks, Spark, Storm, BigQuery, Theanos, Tensorflow, Keras, Python, R, Scala, C++, Java, Ruby, Angular, React and then finally lists as the final item, "Drive agile software development practices (Scrum, Kanban, XP, test-driven development, DevOps)")

- < https://www.indeed.com/viewjob?jk=4f7f9564892a1c9a&from=serp... > (This one lists front-end, Javascript, and Angular experience for a front-end role, specifically says, "Experience with an Agile development / SCRUM approach", and then also says "Experience working in a cloud based environment, such as the Google Cloud Platform (GCP), or the Amazon Cloud and using languages such as Jupyter and TensorFlow", which indicates a bad mistake (calling Jupyter and TensorFlow 'languages'), despite the fact that Deloitte is a huge company that could easily invest more into better effort on recruiting ads.

There are so many more, 80 results I found on Indeed just with 'tensorflow' and 'scrum', without even trying more generic search terms or looking on other sites.

Most likely you did not even search for this, or else just engaged with confirmation bias when one or two job ads didn't match the pattern.

But regardless, as anyone with experience in machine learning will tell you, it is extremely common for companies to try to require you to have front-end skills or train you to have them and then give you crap projects that are only aspirationally focused on machine learning, or just use machine learning as crappy hype signalling.

> "I fear your 'many times' is not backed up by reality."

No, you're just in a rush to use confirmation bias to defend scrum without deeply looking into the points that Scrum critics make. This claim is trivially disproved, even just from the links above.

> are completely subverted for convenience of managers and business people.

That's again is fully independent of Scrum.

> we ought to discount your experience as too much of an outlier from most of the industry.

He, now you are 'we' and suddenly I'm alone. Nice trick.

> I searched for results containing both 'TensorFlow' and 'Scrum' on Indeed

You are shifting topics, that's extremely disingenuous. Your argument was about a 'Machine Learning Engineer' and 'react' knowledge.

Let's look at the job ads:

'Solution architect' - not a 'Machine Learning Engineer'

'job not found'

'Data Engineer' - again not a 'Machine Learning Engineer'. no 'react'.

'CTO - again not a 'Machine Learning Engineer'.

'Frontend Developer' - again not a 'Machine Learning Engineer'.

You also generally seem not to understand job ads. If they list as desired skills a, b, c, d, e, f, g, h, ... then usually an interesting SUBSET is required. These skills are often mentioned so that they appear in searches and to signal people a range of interesting technology.

> I found on Indeed just with 'tensorflow' and 'scrum',

What does that show, again? Nothing. Your argument was about 'machine learning engineers' doing front end development with react. Stick with your original argument.

> extremely common for companies to try to require you to have front-end skills or train you to have them and then give you crap projects that are only aspirationally focused on machine learning, or just use machine learning as crappy hype signalling.

Now we are back to front end development. If your 'machine learning engineers' have to do 'frontend development', they should look elsewhere. The topic is in high demand and there are lots of better employers which have actual 'machine learning' projects for engineers.

> “What does that show, again? Nothing. Your argument was about 'machine learning engineers'”

Yes, the linked roles required experience with TensorFlow and other machine learning frameworks for specific job functionality focused on machine learning engineering.

Please re-read my comment above because it refutes your earlier comment, in which you claimed that jobs ads requiring combining inappropriate cross-functional skill groups while specifically also mentioning Scrum don’t exist, and offered disingenuous claims about trying to look it up, when just a cursory search already showed your claim to be wrong.

Here you are again disingenuously acting like the specific job title words are the only part that matters — that’s ridiculous. It’s obvious from the linked job ads (which were just the first ads in the list, selected just by clicking links 1, 2, etc. from the results, i.e. there are many more) are intended to function as machine learning engineers in various ways if you read the job descriptions.

In fact it seems you are again trying to dodge the problem with another No True Scotsman fallacy. Now you’re saying “no real machine learning engineer role can have a title such as xyz..”

This seems to be your go-to defense for everything. Just look at examples that clearly and unequivocally refute what you are saying, then turn around and try to claim that no “real” example would be like that. Just trying to define the outcome you want (“Scrum isn’t disempowering” or “machine learning job ads don’t require front-end skills”) by defining the premise to already have that outcome baked in (“Scrum is by definition empowering, so disempowerment only happens when not correctly doing Scrum” or “real machine learning engineer job ads don’t have other titles or list front-end technologies, so any examples which do must not be “real” examples.”)

> “If your 'machine learning engineers' have to do 'frontend development', they should look elsewhere. The topic is in high demand and there are lots of better employers which have actual 'machine learning' projects for engineers”

This just speaks to your lack of knowledge of this part of the job market, and how tons of large companies staff up on machine learning staff without anything more than a hype-driven, aspirational understanding of machine learning, and no actual statistics projects to offer the people hired. Often a hugely credentialed machine learning engineer is tasked to babysit Tableau dashboards or get added to PagerDuty for answering 2 am alerts for failed Spark jobs.

Only in very few companies and very few teams do these workers actually get approval from pointy headed managers to spend time on research or modeling at all.

Again, I’m glad for you that your experience with ML has been an incredibly unlikely, pleasant outlier with a company that magically always does Scrum “the right way” (and where Scrum is never to blame when they don’t), and where, despite all industry trends, they give good statistics and modeling projects to machine learning engineers (whose specialties are perfectly respected).

This is such a fairy tale scenario though that your experience is inapplicable to reasoning about the more general case of how Scrum itself begets and amplifies and tacitly permits all sorts of bad practices that it ought to be expected to reduce. And your experience is inapplicable to reasoning about how Scrum’s endorsement of cross-functionality is inextricably linked to the way managers assume any engineer, of any specialty, should take on cross-functional software responsibilities.

At this point I do not have confidence that you are participating in the comment thread sincerely, and you are merely attempting to shallowly gainsay whatever I say without actually looking into it.

Maybe you can’t stand not having the last word or can’t deal with it when someone refuses to not call you out on your shallow arguments, I’m not sure what the motivation is. But either way, at this point you’re cherry-picking isolated comments and then rephrasing them as repeated No True Scotsman fallacies in which no “real” example of what I describe is allowed, by definition for you, to contain the bad characteristics you seek to deny, like Scrum’s inherent flaws or the way engineers functioning in a directly machine learning capacity are often forced to also have cross-functional skills in front-end frameworks, devops, etc.

You’re welcome to have the last word if you want it in some follow up to this comment with the same cherry-picking and gainsaying.

But since I have lost confidence that you’re discussing this in good faith, and you are without sincere willingness to look into my points, I’m not going to reply again, and you’re welcome to criticize that choice of mine as well. If I thought you were being sincere instead of yet another No True Scotsman attempt to define away the problem, I would continue. I don’t believe that, so I am disengaging.

> Please re-read my comment above because it refutes your earlier comment, in which you claimed that jobs ads requiring combining inappropriate cross-functional skill groups

Your example was explicitly about 'Machine Learning Engineers' with 'React' skills. For that you have presented zero evidence so far.

> I’m not going to reply again

I think that's fine, since your last posts were not able to back up your claims around Scrum leading to making 'Machine Learning Engineers' to work as 'React' programmers. None of the positions you presented were actually for 'Machine Learning Engineers'. Instead you presented job offers for CTOs and Solution Architects - two very different positions. Since you could not provide evidence for your original claim, you came up with a different selection of positions and skill requirements.

For some reason you project all kinds of project failings from staffing to task selection to the Scrum methodology, instead of looking to yourself, your team and your management.

Well, sure it stumbles into this fallacy but so does the roll out of any process involving humans that has a set of normative criteria with a given critique in hand. I always feel this fallacy is a weak response as norms can always be applied well or less well. This is what makes them norms.

I've seen it work very well. I've seen it work badly. Where it has worked badly it was because the process was not fully understood, badly implemented and not iterated upon. For reasons I can detail on reflection. These are explicable and fixable reasons that given the right company ecosystem and desire to honestly reflect upon them and fix them could have been fixed. A bad process tout court would never see highly effective result in some cases.

But if a given norm is always applied badly, it’s disingenuous to say it’s not the norm’s fault. It obviously is.

Even if it’s a good norm in theory, if it doesn’t survive contact with human sociology in practice, then it’s disingenuous verbal gymnastics to say “but the norm itself is good, it was just misapplied constantly and nobody, despite huge effort, could stop it from being misapplied.”

And Scrum is misapplied so often that this clearly applies, and renders whatever “spirit” of “true” Scrum irrelevant.

The norms aren't always applied badly. I have existence proofs of the norms being applied well in multiple different teams.

Quoting from my parent comment,

> "And Scrum is misapplied so often that this clearly applies ..."

It's not about always being misapplied. Just that it's misapplied so often that in the larger scale decision making, it's a problem with Scrum.

I don't deny there are isolated examples in which Scrum is applied well and works well. I also don't care, unless those examples represent the majority of cases in most average companies.

Seems you are shakey ground, without empirical justification, to say that in the majority of cases when applied scrum goes badly.

We are probably at the point of trading ancedotes, but I'd say in the majority of cases where I have seen it applied it has worked more than it has not. Even a poor implementation has yielded some benefits. And those pieces that have not worked there are reasons why.

I agree we might be at the point of trading anecdotes. I would suggest though that there could be the problem that a team works hard to produce good outputs in spite of Scrum, rather than because of it.

My feeling, as I have mentioned elsewhere is that this burden of proof is on Scrum and Scrum proponents to back up the claim that it facilitates better business outcomes than would otherwise have been obtained without Scrum.

The reason I think it's fair that Scrum has the burden of proof is that it is so far-reaching and overbearing in its degree of prescripting exactly the manner of working.

Scrum as a system is responsible for micromanaged enforcement of exactly one set of meetings, exactly one cadence of work, special new positions with Scrum-specific job duties, constraints on team structure, like cross-functionality and minimizing specialization, that there must be some form of aggregateable workload estimation, etc., all which are part and parcel with every Scrum implementation I've heard of (meaning that whether all these prescriptions are explicitly listed in some Scrum manifesto or not, they are absolutely a part of Scrum).

Given all this costly overhead and one-size-fits-all prescription, I think it's very fair to say, "prove it." If I know that my team works really well in our own ad hoc way that is tailored to our specializations, our current workload, our preferences, the way we jell as a team, etc., then why should I agree this other way is definitely, empirically going to be better?

I'm not saying any other team should use the custom methods my team has found to be productive. But why would we need to give them up for a system nobody has proven to be better, and many people have argued to be worse?

There is no particular burden of proof. No one cares whether you approve of Scrum or not.

But what are you comparing Scrum to? Define your specific objections and propose an alternative.

I'm comparing Scrum to customized, situation-specific workflow practices created and adopted by the team that will use them, based on what works for that team. What about Scrum uses evidence to convince a team to believe it should deviate from that?

> "No one cares whether you approve of Scrum or not."

If you don't want to participate in a discussion about it, why are you? Statements like this are useless. We're talking about high-level evaluation of Scrum.

It's like you would read the original post in the OP, which is a qualitative discussion. And instead of formulating reasonable discussion points, you'd just leave a comment saying, "No one cares what you think."

At that point, I mean, your opinion's decided. Why are you even here? What is the goal? To shoot down anyone who tries to analyze Scrum in a bigger picture sense and just give them a raspberry?

You're comparing Scrum to a phantom. State which specific practices work better than Scrum in specific situations. Otherwise it's just a complaint with no useful contribution.

> "State which specific practices work better than Scrum in specific situations."

Sure.

- When working on a team whose primary outputs are highly specialized research, the necessity to have planning meetings, standups, retrospectives, etc., according to a single fixed schedule causes a lot of problems. A better practice is to allow the length of a sprint to be variable and to be different for different individual team members depending on what they are working on. Elminate overhead that's not helping by discontinuing a fixed-cycle planning meeting (e.g. don't do it every X weeks, rather just arrange planning meetings in an ad hoc way whenever enough items reach a state where a group planning meeting makes sense.) If your team is working on projects that need a longer time to ruminate and develop at the moment, then cancel the retrospective meeting and just do it later after some other milestone. Basically, treat these things like collegial, flexible, malleable tools whose timelines and cadence flexibly changes all the time in response to current projects.

- When working on fundamental research, notions of incremental progress are not useful. You might spend weeks on a problem and have no demonstrable new functionality. You may not even have any research or documentation to share. You might only be able to say, "I worked extremely hard on methods X, Y, and Z, and I appear no closer to know whether they could work or not. Need more time." So in this situation, estimating story points is absurd, and reporting velocity is at best a nuisance but more often harmful because you can count on upper management questioning it with inappropriate comparisons to the way velocity works for iterative software work. Later on, maybe several weeks later, you might have a breakthrough on the tough research project, and now you are at a point where you need to productionize the supporting software that wraps it, and you do get value from estimating time to completion and using iterative cycles of incremental, demonstrable units of functionality. So once again, it should be flexible. Many times, there is no use whatsoever to estimate story points, so don't do it. Don't use a concept like velocity for these case-by-case situations at all. Then later, if you find value in switching back to an estimation-and-velocity approach for productionizing it, then do so.

I could go on, but the general idea is that it should be highly flexible. No fixed set of meetings that must happen every sprint no matter the work context. No enforced policy of always estimating story points or always tracking velocity. That's no flexible, it's rigid because it says you always have to do it that one way, and leaves no room for situations when that one way is not useful, or when it adds costly and time-wasting overhead during periods of work that don't benefit from it.

These things should be left up to the team to decide, based on what type of work the team does, how it varies over time, what feels low-overhead and liberating, what facilitates productivity for that team.

> "You're comparing Scrum to a phantom."

No, I'm not. And I have not been at any point in earlier comments either. Your comments are just needlessly antagonistic while constantly deflecting without dealing with the fundamental problems of Scrum.

> "Otherwise it's just a complaint with no useful contribution."

Complaints are often useful contributions all on their own. It's foolish to claim that complaints have to always be accompanied by candidate solutions to be useful. No. Knowledge of the details of the complaint is useful all on its own. Regardless though, this is still a lazy mischaracterization of anything I have been writing.

Well all I can say is that I've seen multiple teams implement scrum and this improve overall team productivity, usefulness to the wider organisation and general happiness amongst all members of the team. I have no evidence to suggest that it was anything but adding the framework to the mix that caused these effects. And the more the processes were adhered to by the letter of the framework (i.e. all meetings were adhered to, stand ups were understood well etc), the better the results have been.

Of course one could argue that the improvements were the result of some other phenomena. But it certainly seems that the equation seems to have worked and turned teams around. Scrum wasn't in the mix before and now it is things are much improved.

By the way I'd in no way advocate a one-size fits all solution. Sometimes other techniques might be as effective or more effective. I'd not say you should agree another way is definitely better if your team is humming along. Why would I?

I wish more Scrum-advocates shared your opinion.

Hey, if Scrum is working for some team, I would be the last person to ask them to change it. I know how much I hate it when I have a workflow that is succeeding and then management arbitrarily makes me switch to Scrum. So I would not want to do that to people who are doing great with Scrum.

The reason I feel the need to deeply question it though, is that most managers don't express the attitude you expressed. Most often they see a workflow as something they need to enforce unilaterally, and that it should function to commoditize the underlying teams.

Given that this is how it's practiced almost everywhere, it's fair to ask why is that? Is there anything intrinsic to Scrum that makes that mistake easier? Or at least, is there something Scrum lacks which would make that mistake harder?

And then to finally ask if someone is advocating for everyone to be happy switching to Scrum, and advocating that every possible problem with Scrum is not Scrum's fault but always just the misapplication of Scrum (like they are interpreting a religious text or something), then I think it's fair for me to say, "prove it" and ask for evidence that the extra operational overhead of Scrum is empirically shown to be cost-effective.

Doubtless scrum can be imposed from above as a management tactic. This would open to more wider discussions about how power operates in workplaces.

I don't know if there is anything intrinsic to Scrum that makes this more common as imposition but there are certainly risks involved in it that can push a negative power dynamic that is certainly possible in any undemocratic workplace. I'd have to reflect on this a bit more before answering.

But in a couple of cases I've seen it was sought by the team "from below" to protect the quality of their work, make work more enjoyable and self-organised and basically work to more reasonable timescales. There is something to scrum being a toolbox you can use and having a brand. It means you can ask for a process and people know what you mean. Rather than say "I wish work was better".

When it is sought by the team, consensus-wise, "from below" -- I would absolutely support it. That is the team telling you what works for them, not the management telling the team how it must work.

I disagree that the scrum master needs to be a technical leader. Technical leadership needs to come from the development team. The scrum master mainly needs to be a good communicator, communicating the value of feature priorities to the dev team, and the value of tech priorities to the product team.

EDIT: If your scrum master isn't a good communicator, here are some tips for doing the communication yourself: https://medium.com/@brlewis/fighting-technical-debt-in-an-ag...

And the scrum master needs to be empowered to do things. In my company the scrum master has pretty much no authority because the line managers are still pulling the strings.

The problem with Scrum is that it tries to solve one problem (the problem being that business processes are dynamic in nature) with a set of tools that is not meant for this kind of development (namely, static processes, static development procedures, static tools).

The actual solution to business needs is to able to create software like a clay sculpture. I.e. build the software in front of the client, using dynamic tools, satisfying their immediate needs. There is no need for sprints, retrospectives, and all the jazz, if we could actually create our software as dynamically as business processes are.

From what I could tell, most workplaces use scrums to enforce a minimum starting time for all their developers.

They would typically schedule an early in person scrum meeting to defeat all the devs that like to work late or remotely.

From my experience though using DSDM end of day standups are better.

It also helps where team members have different commutes and stops wasting the time of early arrivers. I regularly used to be first in the office even though I had a 70 mile commute to London when compared to my co workers who lived in London.

We got rid of most processes. I "think" what we do now is Kanban - I say "think" because I haven't looked at Kanban closely really. But we look at our board, and everyone just works on things, and when they are done, we help assign a new task. When code is done, we roll to QA, when that is done we merge, and release to production. Issues that get worked on are usually in production in a couple days. This excludes major refactoring work or risky items. Those are handled in special unique ways.

This is fine as an opinion piece and a close reading of parts of the scrum guide, but some kind of evidence (even reports via surveys) would help.

Here's a nice situation where the scrum team decided to become self-organizing and fired the manager who forced scrum onto them: https://workplace.stackexchange.com/questions/112596/how-do-...

The four points of the Agile Manifesto follow the pattern of “valuing the preferred over the less critical.” Seems to me that a valid — if not infallible — corollary is that if you practice the preferred TO THE EXCLUSION of the less critical you’re guaranteed to accumulate technical debt. The more fastidiously the less critical is ignored the more catastrophic the reckoning will be.

Dave has an interesting talk about it.

https://m.youtube.com/watch?v=a-BOSpxYJ9M

My personal experience is any project where scrum actually works is a boring project, no interesting problem is predictable.

Fortunately I see mostly frustrated scrum masters, not understanding why planning fails :)

Hey folks. Short question: What's better?

I read through a lot of detailed analysis of Scrum's shortcomings in the comments here, but little in the way of "Instead".

If anyone cares to share his/her vision: based on your experience, what would be a (nutshell) model for a better system?

Thanks <3

Most of these problems, such as refactoring, lightweight documentation, and tech debt can be mitigated with a good definition of done and a strong understanding of the sprint goal, whatever it may be.

This is a classic "Scrum" v.s. "How We Interpret Scrum" hit piece.

Are you working in feature factory? Chances are you're doing Scrum:

https://hackernoon.com/12-signs-youre-working-in-a-feature-f...

This is a great article.

Great article, but but none of it has anything to do with scrum.

True, but they're synergistic - Scrum is the natural choice for a Feature Factory and reinforces all the bad aspects of it, Kanban much less so.

Is there a prescribed SW development methodology at large technology companies? (e.g. Google). Google in particular seems to be heavy on tooling but, perhaps intentionally discards SCRUM et al from the outset.

This sounds not so much like a valid argument and more a thinly veiled tirade against one bad project manager this person has had during their career. Yes, most by-the-book approaches to agile project management are bad because they are by their very nature not pragmatic towards the reality of a given engineering team or product organization. No, that doesn't give you an excuse to claim that the tens of thousands of individuals (more?) who have made a successful career out of project management are all incompetent snake oil salesmen because there happens to be a certification with a low barrier to entry.

Grow up.

I can see why you'd think that. I just want to put on the record that all of the project managers I've worked with have been extremely competent and a joy to work with.

The problem is not the people, it's the methodology that gets in the way of people doing their jobs. The poor implementations of agile that Scrum encourages are what is devaluing project management, not my post.

Milton Friedman famously said that “one of the great mistakes is to judge policies and programs by their intentions rather than their results.”

There is no silver bullet. Never was, never will be.

As long as tech debt stories are created and prioritized and poc’s are enabled through stories, Scrum works just fine.

for your daily dose of reflection replace "Scrum" with communism (or capitalism if you like) and developers with citizens

If there's a Scrum Master, what does that make everyone else involved?

It’s often impossible to talk productively about this because of all the No True Scotsman fallacies uses to defend Scrum, e.g.:

“No true Scrum master would do X.”

“A product owner who doesn’t Z is just a bad product owner. Not Scrum’s fault.”

“If X is disempowering people then X is not Scrum.”

These are not valid defenses, and they just distract us from the elephant in the room, which is Scrum’s constant presence everywhere these problems occur.

At some point if the tool cannot do its basic job without requiring perfectly scrupulous product managers and “real” Scrum masters, etc., then it’s Scrum’s fault, and we need to think of less prescriptive, less inflexible models that cannot be so easily subverted politically to merely pay lip service to technical quality, while bastardizing reasonable principles to serve quarterly JIRA datamining expeditions and Dilbert-style management practices.

Oxygen is also present everywhere these problems occur, so clearly oxygen is at fault...

Someone proposes a mechanism by which Scrum is problematic.

“In Scrum, product owners ought to empower the team to advocate for technical quality, but in many Scrums, this does not happen, and short-term, quality-ignorant changes to the timeline rule instead.”

This is a claim about the mechanism of Scrum’s failure. And in response someone offers a non-falsifiable defense, like, “whenever that occurs, it’s always the company’s pre-existing badness to blame. Never Scrum.”

Can you really not see how this is completely different from an unqualified claim that correlation implies causation?

Your comment comes off like you think it has some rhetorical punch, but I invite you to reconsider that you migh have completely missed the entire point.

Reply on news.ycombinator.com