
Ask HN: How can I see the value of Scrum? - coconut-box
Dear HN-ers, this is not a rant, I wrote this post to kindly ask you to change my view. All answers will be helpful for me and other people in my situation.<p>I am a developer. My previous company gave us a free hand on how we organized. We worked directly with project sponsors and sometimes they had very concrete requirements about how things should work. Sounds worse than micromanagement. On the other hand, there was culture that we should tell them about unaddressed issues and design solutions to overcome them. I enjoyed my time there because of emotional roller-coaster and ability to prove myself. The project was a success and company made a pile of money.<p>Then I switched jobs.<p>The company does scrum. It feels like project management is duty of SM, PO and development team.<p>The process is heavy, we are forced to give estimates, give input on content of user stories and write down tasks. Tasks are locked for the duration of sprint even if these stop making sense after two days. I feel there is perverted need to predict what is going to happen next week and complete disregard for historical data.<p>Developers are also very eager to discuss how scrum team should fill Jira tickets to maximise their psychological comfort. We are also shielded from stakeholders and when one talked with a dev it was a &quot;disaster&quot;. There is an obsession with minutiae like keeping the sanctity of daily standup duration, getting five extra minutes &quot;ruins the productivity&quot;. I lost it when devs requested a reverse digital twin of Jira board with post-its. Every other day I lose two hours to existence of scrum.<p>My coworkers are great people but I can&#x27;t stop the feeling they are brainwashed in that area. Not only is PMO happy with &quot;predictable&quot; and &quot;well-defined&quot; process but also developers are enthusiastic because they work in ego-fuelling &quot;best possible&quot; framework.<p>Am I missing something? How to enjoy scrum? Can scrum fulfil the trifecta of time, budget and quality?
======
itronitron
Scrum and kanban depend on _a lot_ of upfront planning meetings that focus on
the work. Those planning meetings should include product definition,
brainstorming, technical discussions, etc. and not just be about estimates and
schedules.

If the planning meetings are well run then all the developers should be
excited about cranking out the tasks within the sprint. If the planning
meetings either don't happen or leave some people with a lot of questions then
each sprint becomes it's own mini-death-march.

Given your current work situation, I recommend sitting down for 30-45 minutes
each day and just focus on updating the status of your tasks in whatever
system your company uses to track the sprint. The value of scrum to your
current company is that they probably wouldn't get anything done if they
didn't have it (and given your colleagues obsession with the scrum minutiae it
seems to fit them well)

Stakeholders should be able to talk to devs, the fact that those interactions
don't go well at your company is a bad sign, and it suggests that the planning
meetings aren't being run correctly which makes the whole agile thing null and
void.

~~~
allwein
> Stakeholders should be able to talk to devs

Not necessarily. The Product Owner should definitely be able to talk to devs,
but not necessarily all stakeholders. What I suspect may have happened in this
case, is that a dev talked to a stakeholder that was not the Product Owner,
and instituted a change that was either not properly communicated to the team,
or which was contrary to what other stakeholders or the Product Owner wanted.

~~~
itronitron
That is true, it's not uncommon for some people to try and make an end run
around the process. Hopefully devs on the team know to update the Product
Owner and UX folks when that happens.

------
godot
Purely my own opinions:

I feel like scrum gives a lot of benefits from the top end of the organization
-- it generates predictable results, there's a clear schedule of development,
who's working on what. From leadership perspective, it feels clean and
productive.

From the bottom, the perspective of devs actually doing the work, it feels
more like a cog in a machine more than anything. After running on scrum for a
while, it feels like you only matter for completing the tasks set up for you
this week, and you start to only focus on that and not anything else in the
business.

It's entirely possible that I've simply had bad experiences in companies
running scrum, and had good experiences in companies not running scrum --
"correlation not causation".

I feel like in the instances I've been in where scrum was used, it may have
been used as a process to fix other issues in the company/business, like the
business not growing and needing to hit more aggressive schedules, or poor
codebase structures or team structures causing development to be a pain and
the company using scrum processes to solve that (translation: speed things
up), etc.

I'm currently at an org that doesn't use scrum. We just do daily standups; and
with a mature team, everyone knows what they are working on; we don't have a
project manager breathing down our necks for status updates every day. Dev
work is pleasant because code structures and team structures are good, the
company/business is doing well so we're not in constant pressure to
aggressively churn out more features more and more quickly. This is a huge
contrast with a previous place (similar team size -- 15~20 devs), where the
business wasn't going well (relatively flat growth), and leadership wanted
more effective ways for the dev/product team to get out more big features more
quickly.

------
tucaz
I believe that you will see the value of it when the company actually uses it
and not something they are calling scrum.

Tasks can’t be locked once they are not necessary anymore. The timebox idea of
freezing work for a week is about “requirements” and not tasks. The goal is to
have a somewhat stable target at least for that sprint.

Working with stakeholders directly is one of the reasons agile methos were
“created”. If you can’t collaborate with people who care and know about the
project you are doing it wrong.

The duration of the meeting or doing it or not is not set in stone. These are
initial guidelines and the team should adapt once everybody is familiar with
what they should do.

Here is the thing, the basic layout of any agile process is to “teach” people
to do what they would naturally do if they cared about their work:
collaborate, work together on problem solving and help each other.

Once that part is achieved, the initial process doesn’t need to be followed
anymore as long as the values are kept.

From your story it seems like none of that is being done and that why you see
no value.

------
realusername
I've also been in a company where they apply scrum very strictly. In my
opinion Scrum is a very good option when you are in a big company and you
already have older and heavier processes than Scrum like a V-Model, compared
to that, Scrum is a big step forward. However, on a startup it's clearly too
heavy to follow for my personal taste. You have a lot of easier to follow
agile methods.

