cygned

Try MJML, works wonders

Concern was that it still turns down too many, maybe we were too careful.

We have another vacant position soon, I might try it.

We don’t post salary ranges right now. We are a small firm and cannot keep up with the salaries from enterprises in our area. We are looking for (and finding) candidates that are willing to sacrifice parts of their salary for 100% remote, flexible work time, PTO and others.

We decided to screen applicants in an informal phone call and discuss salary options at the end, after they had a first impression of how we are as a firm.

> what I am arguing is that SCRUM as most enforced things "micromanage and/or ignore human psychology".

I think you are arguing Scrum can lead to these situations - which you cover in your other thoughts. And I agree, I have seen that often, however, I’d still don’t say it’s inherent to Scrum itself.

> how SCRUM is not micromanagement when every day, a guy (which in my decade long experience has always been either a manager-role or someone wanting to be a manager) comes and gets the report on the tasks that you work to the granularity of one hour (sometimes even 30 minutes for properly crazy SCRUM masters) and intervenes afterwards if he considers it needed.

Yeah that’s awful micro management. I know it’s easy to dismiss that way, but what you are describing is not Scrum, that’s just saying Scrum and making people miserable.

In the end, I do not want to argue for Scrum as the solution for everything. It’s really hard to do it right. On one of the teams I am consulting right now, we went away from Scrum because it didn’t work - fascinatingly due to different reasons as you mention, different mindset in terms of what management does and how control is exercised.

Isn’t that why many teams opt to use Fibonacci sequence?

Aren’t these interactions put in place to create transparency across the team regarding progress and purpose as well as empirical validation? I am not sure how that necessarily clashes with social structures inside the Scrum Team or micro manages its members.

> Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process.

That is not the way Scrum is meant to be implemented. The goal is to have a cross-functional, empowered team with the ability to make their own decision. The Product Owner - as part of that team - makes ultimate decisions as to what the product will be.

> It creates unnecessary hard social situations

Yes, social conflicts in team can be tough. Following the values of Scrum, respect and openness in particular, helps teams sort these things out. I know that in practice, it involves a lot of skill to guide a team through those phases.

> the components of motivations in pretty much any other fields are autonomy, mastery, accountability

You are absolutely right. If you read through the Scrum guide, you will find all those aspects in there. I think what you are describing, though, is how Scrum is "lived" in many organizations, which have difficulties empowering teams and provide the environment necessary to do Scrum.

In these situations, the answer is often that Scrum simply don't work, it's clashing with your culture and structure. Many teams opt to implement parts of Scrum - which is fine and might work exceptionally well, but it's not Scrum.

Whenever I come across teams with situations outlined as in this article and I talk to the people involved, it becomes apparent that Scrum was implemented for the sake of implementing Scrum without understanding. The values and the concept of empiricism are important to grasp in order to effectively leverage Scrum - that is why you have a Scrum Master, not as a manager of any kind, but as a coach and facilitator.

The main challenge I see people having is that Scrum was designed in a way that it screams in your face when you screw up and many organizations fight that instead of inspecting and adapting their way of working.

Despite him not saying "Scrum", the structure he's describing is not Scrum anyway. It might be close to what some people understand when they say "Scrum", but it is not Scrum.

How does Scrum micromanage and/or ignore human psychology?

The lower entry barrier for a lot of things.

It allows the community to grow, learn and become more diverse.

On the other hand, I regularly read blog articles about complex topics from people that should rather not write about it. I know "senior software engineers" where I ask myself how they are capable of tying their shoes each morning. I see people get praised for achieving the bare minimum, like putting five pictures on LinkedIn about a topic they hardly understand at all.

Others will talk about the benefits, so let me give you a few gotchas from us:

1. It does not replace type checks at runtime (in integration layers)

2. Compilation and startup (in backend land) is slow

3. Some tooling seemingly caches (webpack? ts-node?), we regularly run into situations where rebuilding locally works but then building for prod fails with type errors

The thing is, though, that Typescript is not solving runtime type checks. Typescript is declarative, it does not check at runtime and if you have any code interacting with third-party data sources and you do not check there, things will explode down the line.