Hacker News Reader

If you read the agile manifesto and then you look at scrum, it feels as if scrum has nothing to do with agile. It seems to breaks every rule.

Scrum is processes and tools over individuals and interactions, by its very nature.

Scrum is comprehensive documentation over working software, because you have to map everything out.

Scrum is contract negotiation over customer collaboration, by allowing management to effectively rule scrum, scrum masters are always management or reporting to management, so devolve into contract negotiation by proxy.

Scrum is following a plan over responding to change, again, by its very nature.

It's the most odd thing I've ever seen, that somehow scrum came out of agile and literally got it all backwards. There's even certifications on how to do scrum, which is utterly stupid when you read the 12 principles, some choice scrum oxymorons:

trust them to get the job done - nope, we don't trust you, follow these scrum rules you oiks

simplicity is essential - but we've got all these formal rules for you to follow

working software is the primary measure of progress - no, actually, how many sprints have been successfully completed?

the best architectures, requirements, and designs emerge from self-organizing teams - but we're not going to let you self organize, you must follow these scrum rules

Scrum is all about implementing a system and then adapting it over time to fit your needs. It's all about having the team figure out for itself how to organize. It's not a rigid set of requirements. It's a set of suggestions about how to begin implementing the system, and then trusting the team to figure out what to adapt and what to cut.

That's not how it's presented in real life.

Read something like this:

https://www.mountaingoatsoftware.com/agile/scrum

All about what has to be done, with a formal role of scrum master.

Phrases like these brook no adaptability:

On each day of the sprint, all team members should attend a daily Scrum meeting, including the ScrumMaster and the product owner

on the first day of a sprint and during the planning meeting

Another activity in Scrum project management is the sprint retrospective at the end of each sprint. The whole team participates in this meeting

Management take Scrum as a set of rules to follow and then use it to micro-manage everyone. Scrum masters end up as middle managers. Daily stand-ups turn in to daily justify your worth.

> These questions are effectively a way lay out a very clear path for management to basically micro-manage developers

Well, they would if there was manager in the daily scrum.

Which is why there isn't.

(Not that I think the scrum formula here is ideal; if you've got a shared status display—kanban-like—the only question you should really need in the standup is the barriers one; the standup shouldn't be a status/progress check, it should be a venue for shared progress on breaking barriers.)

If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items.

They take control because they've made promises to other people, higher up in the org and possibly outside the company, and they need to find out if scope is expanding too much, if something is taking too long to implement and scope needs to shrink as a result, or people who've been promised something need to be let down.

As a developer, this interaction feels a lot like micro-management.

> If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items.

In by-the-book Scrum, that's the Product Owner, who isn't a participant in the daily scrum. Neither is the Scrum Master, whose only roles with regard to the daily scrum are: (1) teaching the Dev Team to keep it within a 15-minute time box, and (2) ensuring that it occurs, (3) ensuring that if people other than the Dev team are present, they do not disrupt the scrum.

(I do think that both having the status questions and leaving the door open for the P.O. to be present even if not supposedly participating is a thing that creates the temptation to turn the scrum into a managing meeting, which is very explicitly not the intent.)

Sure, present but not participating.

I really don't get this "management can micro-manage developers". Sounds like you work at a very shitty company / unhealthy environment. Dailies are for the actual working team, so they work better together and not a tool for team externals to shit all over the process.

I really can imagine your scenario - do you really have your CEO standing there on your daily meeting? Or are you bothered by your Team Lead?

I'm a CTO and I've never been on a daily. I don't care about daily tasks. I care about shit breaking. It can be our tech, our infra, our people, etc.. That's what I need to solve. I don't get it why in the god's name I would attend a daily. What value would I get out of that?

If on the other hand, I see shit going down, I dig in right away and talk with the Lead and/or Team if shit got real.

Without scrum, if a CTO wanted to ask how an individual developer is doing, they could ask their line manager. With scrum, a CTO could just dig in to some of the many dubious reports that scrum generates. They could look at an individuals burn-down on tasks, and compare them across developers/teams. No matter how stupid this sounds, I've seen this exact thing being done by company Directors.

Decisions are made. Developers are moved to different projects, or given shitty bonuses, or constantly hassled to make their scrum metrics look better.

Just because you don't go to a stand up doesn't mean your not micromanaging, or enabling micromanagement as it is usually the line manager using scrum as an excuse to account for every hour in the day. Sometimes that is due to pressure from up high for various metrics to improve, etc. Other times they are just douchebag managers that don't know what they are doing...

You're basically arguing that CTOs mostly cause damage and it's better to hide various vanity metrics from them with the purpose of them not meddling in the process.

My view is that looking at scrum metrics will provide you with additional insight into the development process. I understand that shitty managers will simply take those and decide on top of that. Proper managers would look at the numbers and go ask the line manager what is going on.

I can give you a very practical example - before we had scrum and burndown charts our team leads had limited tooling to detect problems and even quantify problems in the development process. Now we can use that to improve our process with the purpose of us being more efficient and making the development process less stressful.

I never look at burndown charts - I'm the CTO and my purpose is strategic. VP of Eng might look at them, but only if issues are detected, while team leads need to use them daily to help them improve how they work.

> I don't find value in anything that agile offers, can I just throw it out entirely by your argument?

Yes, of course?

But I think you might be confused about what agile is, going by your remark about processes that agile imposes. There are none. Agile is about certain values, and people have come up with various processes that try to incorporate those values. This fails sometimes, mostly because different teams require different things in their process.

But ultimately, since it is about values, if those values are not shared by a company (or at least your division) and management it's going to turn into process for process sake. You're screwed, but it's not agile that screwed you.

Then it becomes completely meaningless - It's the equivalent to saying to someone - "Be good" without defining anything about what good-ness involves.

Once you start defining specifically what you mean by good, if your initial premise falls apart and there's no practical way to be good, then what's the point of saying be good?