Comment by theworld572 | Hacker News Reader

Comment by theworld572 | Hacker News Reader

Parent Full thread

My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan. Software development almost never works out so neatly.

What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. You start working on it, maybe you discover that there is a whole area of code that needs updating in order to allow for your feature to be implemented. This adds on another week of work required.

In a common-sense based development team, what usually happens is the developer has a quick work with the project manager and maybe other devs who need to be involved and says "Hey, I've found out that we need another week to complete this feature because X needs refactoring, do you still want me to continue with this?" then the PM either says "Yes this feature is important, even if it will take another week" or "No, the feature is not important enough to be worth spending another week on". Its really not rocket science.

In SCRUM what usually happens is the SCRUM master will tell you that the rules say that we have already committed to a set amount of work this sprint and that extra week of work falls outside the scope so we should create another card for the extra work and consider this card blocked.

The whole idea of having a rule for what to do in that situation just seems absolutely crazy. Just do whatever makes sense! Its really not that difficult.

> My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan.

They don’t, there are ‘spikes’ that are just time spent researching or exploring or designing rather than implementing.

If your scrum master is telling the team what they can’t or can’t do, or how they should do their jobs, they are doing it wrong. Their job is to help you plan and help you resolve impediments to your work. They aren’t your boss.

The first thing in the manifesto is people over process, there should never be a case where some rule tells you that you can’t do the right thing.

Formal Scrum is a nice way to organize ‘normal’ work, but there are lots of cases where you have to improvise, and the process should never get in the way of that.

> If your scrum master is telling the team what they can’t or can’t do, or how they should do their jobs, they are doing it wrong

Unfortunately in my experience this does happen quite often. I've found the biggest issue with scrum is when people (usually the scrum master and PM) take hard-line, dogmatic views of scrum processes.

There's this course in pluralsight that talks about two orgs that promote scrum. The other one seems to be giving out the wrong ideas. I think it's this one (copied from wikipedia):

    In 2002, Schwaber with others founded the Scrum 
    Alliance[18] and set up the Certified Scrum accreditation 
    series. Schwaber left the Scrum Alliance in late 2009 and 
    founded Scrum.org which oversees the parallel Professional 
    Scrum accreditation series.[19]

I think it was Scrum Alliance that's giving out ideas like Burndown chart is required in scrum.

> My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it.

No, it doesn't. It wants the team to discuss features to help find preventable issues up front and to make it as clear as possible. The unknown unknowns remain unknown, which is why an estimate is an estimate, and a sprint is a best-effort attempt at getting a thing done. If and when it becomes clear that this feature is too complex, too big, or whatever, then it can be reestimated, or decomposed or reevaluated. It's supposed to be agile, not rigid and fragile.

Whats the point of SCRUM then? If all it does is to tell you "do what makes sense" why do we even need it? Thats a rhetorical question, I already know the answer is that we need it in order to keep SCRUM consultants, certifications, training etc. a profitable business.

Whether or not you think SCRUM is good or bad, you can't argue that a sizeable (if not the majority) amount of companies are "not doing it right" and that a sizeable (if not the majority) amount of developers loath working in SCRUM teams. So wouldn't we just be better off if the industry ditched SCRUM entirely?

It's to keep everyone in the loop on what's happening in the codebase, and give people a time to ask for help on whatever's blocking them (so you hopefully get it sorted in a 10 second conversation instead of having to break their flow later to get help).

The "do what makes sense" is limited because you have to ask questions to ascertain what makes sense.

Some questions are easy to answer, but many questions can only be answered by doing a thing that takes work. And Scrum gives you a framework that tries to put a limit on how much work goes by with no answers.

So it uses a simple schedule.

The team works for X weeks, working on implementing specific tasks. (Which in turn answer some questions.)

Then the team stops, reviews their progress on the larger product, and adjusts plans accordingly. Now "do what makes sense" has demonstrably advanced.

Scrum, not SCRUM. It's not an acronym.

Good to know.

Unless you work for Scottish Club Rugby Union Magazine. https://scrummagazine.com/

Working is not vacation. Sticking to a process is a hygiene factor which doesn't necessarily has to be fun but it makes it possible for companies to be properly managed.

That being said, stop complaining. If you can find room to complain, you surely can find room for improvement right? It might just be me, but everywhere I've worked I've never encountered a manager who isn't open to solid ideas for improvement.

I never said I wanted software engineering to be fun. I have worked on 4 different teams that followed Scrum and all four of those teams suffered from the same problems - low productivity and poor management. The most entertaining was a recent place I worked where we had a certified Scrum master who had been "trained" by one of the two founders of Scrum, when I joined I told him about some of the bad experiences I've had with Scrum and he said "yeah that annoys me, those teams are not really following scrum and so teams think that scrum is bad but really they are not doing it right". Of course in the months to come I realised that we ended up with the same exact issues I saw in previous teams. In contrast theses problems were just non-existent in teams that did not follow a set methodology.

Scrum is just not a good way to manage a team. I find Scrum to be a lot like religion - it means different things to different people but its evangelists always have a pre-prepared answer to every possible criticism, usually containing lots of jargon, buzzwords and double speak.

In the traditional waterfall model, you don't do what makes sense. The Plan has been set, and you have to find a way to do even the parts that don't make sense, because it will be a huge disaster if The Plan isn't complete.

Sometimes it's even the right development model! If you're building the control system for a new power plant, you'd better follow the agreed-on spec even if you realize it's not the best way to do things.

> What really happens is that you have a set of requirements and an idea of how you are going to implement the feature.

The thing is, your story cards or whatever are meant to be a live document. You have the big meeting, the next day you realise that what you came up with doesn't work, you grab a coffee with your stakeholder and talk it through, come up with a new plan, and you change the card you're working on. Probably check with the tech lead first, but it's that flexible.

> In SCRUM what usually happens is the SCRUM master will tell you that the rules say [...]

This SCRUM thing sounds evil.

> Just do whatever makes sense! Its really not that difficult.

This is probably the best advice ever for any development team. Just do the thing!

I think the OP is missing the point of scrum. The scrum master isn't supposed to tell you what the rules are. The rules are whatever the team decides they are. The scrum master is not the boss, they're supposed to be a facilitator...

Exactly. It's meant to be collaborative, not authoritative.

That sounds like typical scrum-enthusiast double-speak to me! :D

https://www.scrum.org/resources/what-is-scrum

"This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together."

Definitions, Rules, Roles, Artifacts etc. Sounds pretty authoritative to me. If it wasn't authoritative, how would you even know what SCRUM "really" is? You cannot say both that SCRUM is not authoritative and lets you do what you want, and then also say "you're not doing scrum correctly".

All of the rules say the team is allowed to change anything that doesn’t work for them. Scrum is a set of suggestions for organizing a team, it’s not Moses coming down with tablets from on high.

Why not try to find a perspective that will make things easier for you? You can look at any suggestion and shoot it down for reasons X, Y and Z - that's easy. Try to invest some time in finding out what works for you and focus on that.

You shouldn't actually ever change a story in progress if you can avoid it. The feature is the feature. How you build it doesn't go in the story. And if you aren't sure how to do it, you account for that in the estimate.

You never just write a story on the spot for a feature. It has to come out of completed design work that takes as long as it takes and ideally is funnelled through the same pipeline as you use for development.

Reply on news.ycombinator.com