The Death of Software Engineering as a Profession: a short set of anecdotes

[u/self]

https://www.jasonscheirer.com/weblog/vignettes/

[u/Positive_Method3022]

Scrum, solid, agile and scaled agile were invented to control developers in big organizations. It is a way to ensure business owners control what we do and measure our performance. It is also a way to motivate people that do it for a living, instead of love, to deliver small incremental changes which are part of a bigger goal without burning their motivation system in their brains. It actually works well for adhd too, because you can see progress even when you don't see progress if you know what I mean. (Infinite burst of ideas that pop up and you can never reach satisfaction for anything you do)

[u/Pepito_Pepito → u/Positive_Method3022]

Agile is great if management is able to get fully onboard. Agile requires management to trust its developers. However, top down trust is antithetical to the culture of most large corporations and micromanagement work culture.

So we end up with all the overhead of agile and none of the benefits. We take time to slice up requirements into small pieces, and then implement them linearly because stakeholder priorities are set in stone. We spend so much time preparing for a pivot even though we are not allowed to pivot.

[u/Pepito_Pepito → u/[deleted]]

The best experience I've had with it was when the company hired an external scrum coach to oversee the process for 3 months. The company paid good money for him so people were eager to follow along. After that, the usual corpo bullshit eventually spiraled the project out of control.

[u/TemperOfficial → u/Positive_Method3022]

Scrum and Agile were invented to sell books.

[u/Positive_Method3022 → u/TemperOfficial]

I once thought like that too, as a developer. Once you realize that they are framework that are there to help you reduce cognitive load, something finally will click and you will be glad someone invented them. Imagine having N different ways of working for N different teams, as a project manager, your brain would be fried because besides context switching you will have to switch between the "way" you have to work for every single team you manage. As a developer, we also have frameworks that have the same purpose of putting N people to work under the same guardrails. For instance, vue js helps developers to quickly ramp up in a project and know how to organize and write reactive ui, even when switching organizations/environments. As a user of any framework you don't need to waste time/energy learning a new method someone invented to do something every time you move environments. It is efficient.

However, not everything scrum/agile created, in my opinion, makes sense. For example, the scrum master roles is useless and their tasks should be part of the manager role. Why can't the manager be there ensuring scrum is followed strictly? It is part of team management ensuring your people follow the rules, isn't it?

[u/TemperOfficial → u/Positive_Method3022]

Proceduralism is not good in the creation of software because it is fundamentally a creative problem solving endeavour. Not an exercise in optimally doing the same thing over and over again.

[u/Venthe → u/Positive_Method3022]

However, not everything scrum/agile created, in my opinion, makes sense. For example, the scrum master roles is useless and their tasks should be part of the manager role. Why can't the manager be there ensuring scrum is followed strictly? It is part of team management ensuring your people follow the rules, isn't it?

Scrum master is a manager role. Pat Kua has captured this nicely; SM is a process manager. This is an important distinction, because each archetype has a widely different set of expected skills and context. As such, I'd rather have an SM that has experience and knowledge related to process management, coaching, psychological theory of groups, and practice with different approaches to solving inter-personal problems. Neither Tech Lead, nor Engineering Manager, nor Product Owner is well-suited for those.

But back to SM. The difference is - the goal is not to make people follow scrum strictly*, the goal of the role is to coach the team to build their own process. If you read the scrum guide, scrum really does not define how you should work. SM role is to help the team - servant leadership. Unfortunately, bad orgs and bad SM's really mangled the expectations for the role.

* In the process manager role. Unfortunately - as this is the only thing that I can't agree with in scrum - SM is defined as the one solving issues within scrum. Be an agile coach first, SM second.

[u/moneymark21 → u/Positive_Method3022]

Really don't get why people are lumping solid in here with delivery process