Hacker News new | past | comments | ask | show | jobs | submit login

I am in a big project which assembles 45 teams and all of them shall adopt Scrum (for various reasons). My observation is that all those teams which have a sustainable pace with regards to architecture, technology, quality, output, social behavior, etc have done so while adopting and embracing Scrum in a clean way since the beginning of their existence as a team. All teams severely struggling with their content of work, output and collaboration have also severe issues with regards to Scrum-adoption, and show anti-patterns similar to the Stackoverflow thread creator‘s. However I would say the root causes (which we discussed in maaaany meetings) are certainly neither caused by Scrum nor increased by it, but individual mindset, dysfunctional team dynamics, pressure, weird contracts, etc. and would be there under any other or no process framework.

I am no Scrum fanboy (I think), but this experience and also from former projects make me quite sure to not blame Scrum in the first place when I see struggling teams, but trying to understand the underlying problems and solve those.




One more thing: In answer to Scrum advocates claiming its about doing it right I would disagree and replace it with understanding what is really (really REALLY) the purpose and idea behind it. Don’t worship the cult and don’t fight it because it’s the perfect target of rants, but see the motivation behind it and acknowledge that there may be reasons why it makes sense how it is to some degree. This doesn’t only apply to Scrum but to any other interaction of humans.


Could you explain what you mean by the real purpose and idea behind scrum?


Let me try: I think it’s about reflection and continuous improvement and providing a framework to enforce those. Scrum-haters in our group are also notorious for an attitude of negativity and resignation in many matters, while Scrum-friends want to improve all the time and find ways to do so, beyond what is obvious.


I think that Scrum leads to resignation for many people, because it takes away control out of individual and insists on everything being collective. So your personal options to improve or make decision becomes severely limited.

Some people like it, because it allowed them to push themselves on the rest of the team. But people who dont thrive in such constant dominance conflict end up resentful and helpless.


That's an insightful concise description of "agile" experience.

As an anecdote, I have an acquaintance who is a psychologist in silicon valley and he has mentioned he frequently works with patients suffering from mental health issues related to being subject to "agile" at work. I wish someone would do a proper study on this topic.

Personally, agile hasn't driven me to depression but it has made me target roles that avoid it at all cost. Life is too short and precious to suffer through a detailed status report meeting every.single.day.


I found that testers in particular find agile off putting and some avoid working at such companies if they can. I am not sure why testers specifically end up disliking that.

I think that agile ignores human psychology. First, in management theory, intrising motivation happen when one has autonomy, mastery and purpose. Imo, plus accountability. Agile removes that from individual, but has some rhetoric that places it on the "team". But team is not person, it is set of people.

Second, it kind of assumes that people are socially perfect and everyone is kinda the same and its answer to any social human problem is "that is team dynamic or bad individual". It does not help to deal with predictable human imperfections, emotions and conflicts.


possibly because usually they get a fraction of a sprint to do a whole sprints worth of validation.


I think UX people should evaluate the different development processes. UX people because they have the concept of that something tasks take more mental effort while other less, e.g. searching for a button within 100 buttons has a cognitive load than searching for a button within 10 buttons.

My guess is that SCRUM has a greater cognitive load than waterfall.


what control do you feel is taken away from individuals? I mean, you discuss tickets with the rest of your team, but that doesn't seem such a big loss of freedom.


Control what to work, on for example.

These days I sometimes decide not to work on the top priority issue right now, because I suspect it'll take a few hours of uninterrupted log file reading / debugging / thinking to fix, but the day already has three different meetings scheduled.

If that's the last issue in the open sprint, choosing to add another issue to the sprint while there's still an open one tends to be a no-go, or at least causes some discussion, especially if the sprint closes without the issue being closed.

Or sometimes I simply I don't feel like working on a particular issue right now. Maybe there's no rational reason for that. I have no problem overriding that impulse if I know somebody else (either a colleague or a customer) is blocked by the issue, but if it's a case of "we have happened to include issue A in the sprint, but not issue B", having to work on A instead of B against my preference causes unnecessary resentment.


All the control and all the autonomy I would say. There is nothing I would be responsible for where I can make own decision and have them right or wrong.

In the teams where I liked to work, I felt control over order in which I do tasks and general shape of something I was responsible for. So I could make my own decisions, decisions that would be really mine.

So when there was mess or something was late, it was my fault. I was not due to other people forcing me do things their way and I did not had to fight about every single detail, just because college happen to be anxious or control freak.


So what process are you advocating for over scrum, that would restore this control and autonomy to you?


Compared to scrum, pretty much any other, quite honestly. The majority of teams I was in did not used named process and for the most part I was alright. Usually there were bigger tasks assigned to people or smaller areas of responsibilities.

For the record, I did not liked when leader had micromanagement/dictatorship tendencies either.


In fact there’s no point in being “agile” in an organization that has no appetite for change (unless those are topdown, consultant-driven, marching orders).

When you’re given the false hope optimization is possible, only to bump into 2-3 layers of middle management and just as many half-broken, Confluence spaces about the “one way of work” for the org... you just content yourself with features and tune out.


Robert C. Martin – The Land that Scrum Forgot

https://www.youtube.com/watch?v=hG4LH6P8Syk


In short I would say, applying ideas from the agile manifesto while providing cadence and some predictability. But that is a personal opinion.


My experience with scrum was that it makes issues around bad team dynamic, pressures and weird contracts worst. Basically, it makes it impossible for individual to react to them and defend against worst consequences.

When it is good, scrum powerlesness does not matter, maybe. But when it goes bad, it does.


I would agree that Scrum makes bad dynamics more transparent, yes. I would not agree that it generally makes bad dynamics significantly worse. This may happen and it’s certainly often claimed, but that is not what I can confirm from my experience.


I did not said more transparent. I said harder to deal with and harder to solve.

Those are fundamentally different things.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: