Agile Is Not Ideal. SCRUM Is Not Ideal.
Ideal Methodology picks up where Agile Methodology left off. Its motto is as follows:
“Those who can, do. Those who can’t, complain.”
Agile and Scrum represent the mindset that complaining and intimidating people are the main methods of achieving project requirements.
Agile and Scrum is simply institutionalized slavery.
Yes, people are basically afraid of losing their job security, and so they can be motivated by intimidation. Agile and Scrum work by preying on peoples’ fears, with the threat that one’s money and job will be lost, leading to hunger, or worse.
However, employees can also employ Agile and Scrum tactics against their employer, by being narcissistic, intimidating and fatalistic at work. It’s wrong, both ways. Everyone, please stop being so damn self-centered.
The Ideal methodology’s main tenet is that a person is motivated by improving themselves through hard work.
Agile is not ideal, but Ideal is agile.
That being said – non-ideal Agile is the main methodology used in the IT world (as of 2019), for the same reason that the Dark Ages was the way of life in Europe, before the Renaissance came along. So here are ways in which you can make your Agile more Ideal, and incisive questions you need to answer, to make you and your company more Ideal.
- Don’t delete user stories and bugs even if the relevant task is complete, but it hasn’t yet been tested for a day or two. Have the courage to ask the team what is going on. You only live once.
- Do delete user stories and bugs if they are irrelevant, or part of another task. Don’t keep useless tasks around, because you are afraid of letting them go, or unsure what your boss will say or think about you. Your boss wants the work to be done. That’s all. Nothing more. They don’t care about your feelings, and they do not give a rat’s ass about you. You are not a special snowflake. Your boss only cares about how they themselves are viewed by their own bosses. You are but a cog in the wheel of the bigger picture. If you still think your boss or company is the bee’s knees, then, well, yeah. Good luck with that. Anyway, don’t let your fears rule you. Don’t let them rule you.
- Do not worry what your boss or anyone thinks about you. The average IQ is low, and people mostly have impure thoughts, most of the day. And deep down, nobody at work could care less about you, your feelings or needs. So, should you then, in turn, sacrifice your precious time on earth to care about morons’ feelings and needs, morons who would gladly stab you in the back, because their only concern is their own well-being?
- Only do one user story or bug per pull request. Otherwise, a reviewer might not know the exact reason why a certain change was made. It could be due to one of many reasons, so which one is it? If you do multiple user stories or bugs per pull request, no one will ever know for sure.
- That being said, do not make your pace slower, or limit the amount of work that you do (because you feel jaded or despondent due to your “speed being broken”), since (as per the above rule) one pull request cannot contain more than one user story or bug.
- A kanban board can cause a lot of tension, anxiety and uncertainty. It truly, honestly, is a loathsome, ugly thing. It reduces your sacred thoughts and creative output to “work in progress”, just because it “works for everyone”. So, it is a devilish, communist device. Admit it. That being said, the kanban board is a tool that must Ideally be used for good and positive things. It should be used to manage a project, not people.
- Don’t change features during a code review, that were agreed upon during sprint planning and grooming. Make a note of it if you want to make a change, and mention it at stand-up or planning so that it can be discussed.
- Is everyone on the team equal, in terms of being allowed or being able to take responsibility, to test completed bugs and stories? If not, why not?
- Get rid of the weakest link in your team. It’s evolution, survival of the fittest. Don’t kid yourself – a person knows VERY, VERY WELL that they are a bad performer, and they know exactly what the reason is why they hate their job, in their heart. Of course, they are just staying with you or your company, because they need the money, and because they have a “contract” and a “notice period”. Please. Such people will seriously make you run the risk of letting your projects fail, while they end up walking off saying “ha, I showed you!”. So, don’t be “shown” by them. Anyway, it’s better for peoples’ self-esteem, and for society, if people do the work they are passionate about and truly enjoy doing. People shouldn’t do work which doesn’t fulfill them. Things go south when the wrong people are in charge of doing work which they shouldn’t be doing.
- Don’t create code smells that other developers have to fix later, even if it makes the user story or bug take longer to complete, and even if you don’t think the work is really that important or interesting or impactful.
- Let everyone on the team (or at least the manager) know if you are taking the day off or working from home, so that everyone is on the same page and someone can take over your responsibilities if needed.
- If a team member says something will be done by a certain date, they should be done with it by that date, or otherwise ask for help.
- If you have something urgent to tell someone who is in a conversation with someone else at that moment, courteously ask if you may interrupt them.
- If a task is becoming too complex during the sprint – not during the sprint planning and grooming of course – mention it to the team, so that the team can work together to break the task into smaller pieces.
- Multiple tasks assigned to a team member at the same time, should not happen. Team members should only assign one task to themselves at a time. What does it mean if I’ve got two tasks assigned to me at the same time? Which one am I actually busy with? The first one or the second one? Both? Oh yeah, both of course, because it is possible to be asleep and be awake at the same time, for example. Sure.
- Deadlines must be clear, they must be enforced, and so communicated.
- You need a ticketing system to log bugs from outside. It’s a knee-jerk reaction to help clients immediately when a problem arises, but it’s a costly context switch each time you have to stop what you’re doing. Developer time is precious.
- Be more realistic with sprint goals and the tasks that are included or committed to for a sprint. Too many tasks create uncertainty about their priority with respect to each other, and it creates anxiety in the team about what will happen if all the sprint goals aren’t reached by the end of the sprint.
- Don’t worry so much about the admin or audit trail of stories and bugs, i.e. the velocity, all the new features that were implemented, and how many bugs were fixed. Focus on the great product that is being created, not the sprint’s admin and red tape.
- Give the benefit of trust and doubt to developers to do their job, but do monitor and manage a situation if the progress isn’t where it should be, in order to get a task on track again.
- A developer should not be allowed (nor need to ask) to abandon someone else’s pull request, unless they are asked to do it for someone. Would you like it if someone trashed your stuff in real life without telling you, because they think your stuff is trash?
- Developers aren’t brick layers or in kindergarten. They (mostly) behave like adults, so there is no need to try and control them, like children. Would you treat a baby like a grown-up?
- How long should a task stay on the board before being handed over to someone else?
In conclusion, if there’s one takeaway from all this, it would be this famous line from the Pirates of the Caribbean movie:
“The Code is more what you call guidelines, than actual rules.”
