You are viewing a single comment's thread.

view the rest of the comments →

0
0

[–] FroggyHunter ago 

As someone not in the software industry, what is so bad about SCRUM, and how does it lead to apathy toward bugs? What other organization styles are there that avoid these issues?

0
3

[–] 13042607? 0 points 3 points (+3|-0) ago 

It basically comes to this, you have fixed deadlines every 2-3 weeks. The other issue that you work in a team and everyone in the team is equal.

The short cycle means that you never can have a well out thought design. If a but gets discovered then any fixes gets moved to another time. Could be the next sprint or 2 sprints further or even months. They just ship half tested and backed code to production. If users complain then we will fix it, if they don't then keep it.

The other issue is that since you act as a team, no one in the team will do any effort to create high quality code/product. Being a leader in the team is not accepted since everyone should be equal. Political Correctness is more important than to created good products.

What happens is what you see on a wide scale, systematic erosion of good quality products that gets fixed before it gets released. Only when they get caught with their pants down, and enough users revolt they will fix the issue.

(For the record my current team is one of the best SCRUM teams that I have worked for, my explanation here does not represent them! But the last 10 years I have been in multiple different SCRUM teams)

The idea of SCRUM is that bad developers gets elevated to better developers because the better ones will coach them. The hard reality is that a lot of developers simply does not have the mental capacity to reach the level of good developers. It is an impossible goal, so the SCRUM master will slow down the good developer to the level of the other team members. The best developer will probably say screw you to the team and leave. So you end up with the worst developers in the end. No one notices that the team is now under-performing than it should be.

How to solve?

Agility how real agile developers work. Not this over abstracted way that has no basis in reality.

What do real agile developers do?

  • They have a goal in mind they want to reach, but there is no time limit to reach that goal.
  • Real agile developed start to prepare their code to be migrated to the goal they have put in the future. They prepare the code when they have less work, never on command with a deadline.
  • Real agile developers are ahead of the business. Past experiences have prepared them to create code in such a way that when the business changes yet again their ideas right before a release they are ready for it.
  • Real agile developers will depending if they have a really good day or a very bad day what they are going to do. If I feel bad then I adapt code that is safe to make mistakes in. If I feel hyper focused then tackle the hardest problem. Again no preplanned or sprint deadlines. My workload is optimized according to what my body can take.
  • Real agile developer will take responsibility for the code they produce. The mindset is a winners mentality, and that is hard if the rest of your team has a losers mentality. And it is even more hard to take responsibility for some other developer that messed with your code you just fixed.
  • Real agile developers will prepare the release deadline to nail it. I actually will change my social live depending on the focus I need for my projects to succeed. I warn my partner that the next 2 months I will focus more on my work, but after the release I will give her more attention and slow down.

Solutions

  • Get rid of that stupid burn down chart
  • Get rid of that stupid user story planning that never works in the real world
  • Get rid of these stupid fixed demo dates. Demo when it is ready, not demo when the time is up.
  • Get rid of these separate user stories, sometimes you work more efficiently if you do 3 stories at the same time because they somehow are close to each other. Talk about a waste of resources!
  • Stop crippling your best people into a process that kills off their productivity

What has this to do with CPU's? Because they have a programmable microcode that in case they fuck it up they can fix it later on. This is the problem, no motivation to create good products in the first place.

0
0

[–] FroggyHunter ago 

Thank you for your detailed and concise reply. To see if I understood your points, I tried to sum them up:

  • Do determine goals to meet, but do not set arbitrary time constraints. Move on when the goal is fulfilled and not beforehand.

  • I'm not really sure what the second bullet point is about, could you perhaps explain it in another way?

  • Keep your code flexible, even in later stages of a project. Orient yourself on what your superiors or clients wanted changed in the past as a baseline of which code needs to be changeable at a later date.

  • Know your current state of mind, be aware of your proneness to make errors in this state and choose an appropriate task to work on.

  • This point is another one I didn't quite grasp the meaning of. Could you elaborate on "taking responsibility"?

  • Shape your life outside of your job after your work, well in advance. This includes putting more or less effort into your outside life depending on how focused you need to be.