Ask HN: How can I see the value of Scrum? | Hacker News Reader

Ask HN: How can I see the value of Scrum?

23 pointscoconut-box6 comments

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.

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.

Then I switched jobs.

The company does scrum. It feels like project management is duty of SM, PO and development team.

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.

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 "disaster". There is an obsession with minutiae like keeping the sanctity of daily standup duration, getting five extra minutes "ruins the productivity". 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.

My coworkers are great people but I can't stop the feeling they are brainwashed in that area. Not only is PMO happy with "predictable" and "well-defined" process but also developers are enthusiastic because they work in ego-fuelling "best possible" framework.

Am I missing something? How to enjoy scrum? Can scrum fulfil the trifecta of time, budget and quality?

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.

> 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.

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.

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.

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.

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.

Reply on news.ycombinator.com