Live data from Hacker News

Scrum is fragile, not Agile

dennisweyland.net

31–40 of 329 posts

Re: Scrum is fragile, not Agile

#31
post #12

He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…

Scrum won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.

Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers.

I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product won't prioritize refactorings, and sprints are too short for devs to sneak refactoring into the schedule.

Re: Scrum is fragile, not Agile

#32
post #12

He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…

Scrum won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.

Waterfall was coined by a paper discussing why waterfall wasn't a good way to do software projects.

You aren't wrong, either. I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration."

That caused so many problems with tech debt.

Stories began to take longer due to the increasingly large and discombobulated code base, but the expectation was that we continue to deliver the same number of story points each sprint.

Then we got blasted for losing pace. "Why are you under-performing? We are just adding little features. You've already implemented this button on another form before? Why does it take longer the second time? You already know how to do it!"

It became absurd and no one could hear or understand what was happening was easily predictable and in fact -- was predicted by several members of the team many months prior.

When the project management was informed of these predictions now having come true, the development team was accused of intentionally causing the delays.

Re: Scrum is fragile, not Agile

#33

Earlier quoted context omitted.

Scrum won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.

> Commitments and sprints become terribly destructive over time. Could you elaborate?

You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. This requires sacrifices like ensuring network connections remain alive, handling exceptions, optimizing queries, abstracting functions for re-use, handling all the data input scenarios, etc.

This creates a confusing code-base with lots of IF statements, copy/pasted code, data modifications from several areas of the system, etc.

You'll fix a problem with data getting into the database incorrectly and realize a couple sprints later, fixing that bug caused other bugs elsewhere.

Automated testing doesn't catch it because automated testing only handled certain scenarios.

It's a mess.

Re: Scrum is fragile, not Agile

#34
post #31

Earlier quoted context omitted.

Scrum won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.

Scrum is iterated waterfall. By iterating faster, inaccurate estimation is shown up sooner. On the other hand, developers are treated like cogs in a feature factory, munching through backlog items fed to them by product managers. I think it works well enough, for a few years. I don't think it's sustainable - the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future and Product wo…

I was explicitly told not to write unit tests because they took too much time, which required me to spend entire days retesting almost 100 scenarios when the business logic changed.

Of course the business didn't know all the scenarios at the beginning of the feature development and didn't care because: iterative development means we'll figure it out later.

Re: Scrum is fragile, not Agile

#35

At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…

I feel like you work at my last company. But so many companies f* this up that it could be any company.

I got fired from any last job after being one of the only engineers willing to say something to management about this. I figured I had a popular opinion - many other engineers often DM'ed me on slack encouraging me to continue speak out, including my own manager, so I somehow figured I should be safe speaking out, politely, as a respected majority representative.

In fact I was dead wrong. By saying that scrum was a problem, I ended up making product managers / CTO who loved scrum and used it as an hour long opportunity to lecture the team every day feel threatened.

Getting fired was one of the best things that ever happened to my career, because in retrospect it was a dead end company that was run by fear. Management was afraid of ideas or challenge to power to the point where innovative ideas and feedback were never well received and a culture of fear and not stepping out of line arose, even though it was sugar coated with fake company values of "openness" that nobody really believed in but that managers loved as a way to elevate themselves.

I suspect many companies are a my least a little bit like this. Unfortunately it is human nature and there are so many stories in history, usually of narcissistic dictators, that mirror this.

This was a very extreme example but I'm sure many other companies struggle with this when it comes to challenging scrum. Managers tend to love scrum because it's a chance, daily, to "manage" and to get status updates so that they feel comforted. It makes it so that trust is no longer necessary, and bad managers are often bad at trust.

I guess another way to view scrum is to realize that it is often a reflection on management's subtle fears and insecurities being projected onto the processes of the company. It is an instance where employees unfortunately must manage up.

Re: Scrum is fragile, not Agile

#36

At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…

> Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room

It is central to the idea of the daily standup is that it is one team.

> Its limited to 15 minutes, so nobody says much of importance, and just parrots what is already on the Jira board.

If you have another mechanism for sharing what each person has done and is doing, then the standup should just be for sharing information about and resolving barriers.

> Stories are supposed to be forecasts, not commitments. But the business doesn't like stories carried over, so they become commitments.

If you organizationally can't get away from commitments, then you need to cut back the amount you plan to do so that there is some slack. As long as you are also doing backlog grooming and have items groomed beyond the current sprint commitments, you can take additional items opportunistically, if there is excess capacity after doing the committed items properly.

Re: Scrum is fragile, not Agile

#37

At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…

The way I decided to play the game was like this, "I won't be attending the Daily Standups anymore as I don't think they add value and do subtract value." The project mgmt response was, "Attendance at standups is mandatory." Regardless, I didn't go to anymore standups and when I got flack for that, I stopped going to the office all together. When I got flack for that, I stopped working all together. Then I got fired.…

I got criticized for zoning out at scrum meetings. So I watched what the managers do. They show up for the first few minutes, look alert, then leave as if in a hurry. I started doing the same thing, and never had a problem again.

Re: Scrum is fragile, not Agile

#38

At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…

The way I decided to play the game was like this, "I won't be attending the Daily Standups anymore as I don't think they add value and do subtract value." The project mgmt response was, "Attendance at standups is mandatory." Regardless, I didn't go to anymore standups and when I got flack for that, I stopped going to the office all together. When I got flack for that, I stopped working all together. Then I got fired.…

Attrition!

Re: Scrum is fragile, not Agile

#39

Earlier quoted context omitted.

> Commitments and sprints become terribly destructive over time. Could you elaborate?

You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. This requires sacrifices like ensuring network connections remain alive, handling exceptions, optimizing queries, abstracting functions for re-use, handling all the data input scenarios, etc. This creates a confusing code-base with lots of IF statements, copy/pasted code, data modifications from several areas of the…

>You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks.

Well there's your problem. How is that inherent to scrum?

Re: Scrum is fragile, not Agile

#40

Earlier quoted context omitted.

> Daily standup I have never worked at a company where this actually goes right and could not be replaced by [insert ticketing system here]. We use Basecamp to do daily check-ins on a very high priority issue, if we have one, which we usually don't.

I like standup on my current team. We're in an open office already, and just (physically!) stand up and say "I'm doing X today". Whole thing never goes over 2-3 minutes, and it's a friendly way to keep everyone up to date with the bigger picture.

It's similar at my office. We also use it to let the rest of the team know on occasions when you're blocked on something.
Post reply on HN