I don’t think that people who don't write or never wrote software should have a place in a software development team. We don’t allow scrum masters and agile coaches in hospitals and ask them to “improve the process”, because we know the only “improvement” we will get is millions of dead and injured. But for whatever reason we allow freshly minted certified scrum masters to lecture seasoned professionals on process, to organise 19 meetings a day to discuss the differences between scrum and agile and, in general, to unleash havoc and destruction.
You should collectively have just refused to work for them in this case.
They're not called scrum masters but the healthcare industry is absolutely full of them. One peculiar thing about the covid crisis was, at least around this particular corner of the planet, in the all-hands-on-deck situation where everyone on the floor in healthcare had to help out, these people suddenly found other things to do. It was impressive to see what could be accomplished when everyone was focused on a singular goal, without a coach in sight. I'm sure there's a lesson there somewhere.
Concluding: It is certainly refreshing how efficient groups can be once a crisis forces all attention towards one single goal. (Perhaps unfortuntately) that is not a reliable (crisises are usually not predictable) nor sustainable (other goals tend to get neglected in crisis mode).
Since the purpose of a hospital is not to make money but to improve health-related outcomes, this is usually bad.
On the other hand, it turns out that focus on improving health-related outcomes by applying science and statistics works really well... and usually decreases costs, too.
This is no guarantee any more. Newly minted managers coming from a development position that have only ever worked in dysfunctional organisations (and got promoted from within) will only reinforce the existing bad practices.
Give it a few years.
Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.
It's easy to blame management because developers and engineers haven't the foggiest idea what management actually does.
Instead of engaging with that problem, they retreat to themselves where they hiss the name management in dark corners.
Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.
I absolutely hate how accurate that is because I always thought I was a big boy and I wouldn't need management if I just had "1 good tech idea".
Docker had the philosophy.
Now they are dying after losing the container wars. That's what happens when you have no idea what a product actually is...
>but insist to intercept every decision
Yes, because left to our own devices, developers will not contribute meaningful business value.
There is a better way, evidently it's not agile, but it needs management's buy in, because well they're in charge (get over it in all honestly, none of us actually want the job, trust me).
WE as engineers need to find a better way to engage management.
But those of you who just grumble "management ruin everything" deserve the pain that such a divide causes and we need to stop wasting lifeboat's on that mentality please
I beg to differ.
A dev team doing agile, with a team leader who is a manager/dev, can definitely self-organise. The team leader interfaces with non-dev management, removes roadblocks, and in collaboration with the rest of the devs sets the direction for a sprint.
You need this team lader role to keep the suits off your back, and to ensure the demands are achievable.
Project managers used to be people who wandered around with GANTT charts, and signed-off expenses and timesheets. Very rarely, I worked with a PM who saw their role as removing roadblocks, and shielding devs from suits. Those few PMs were a delight to work with (this was long before the appearance of Agile etc.)
> Yes, because left to our own devices, developers will not contribute meaningful business value.
I think that's rather obvious; management runs the business and sells the products. They set the business objectives, and there has to be clear communication between the devs and management, otherwise you get the "rewrite it all in X" syndrome.
When I first started we would be doing 1-off feature requests "because the client would _really_ like it". Everything was justified because money and because "we cant afford to lose that customer!" in our SaaS product.
I saw our main product being neglected because we'd invest so much time in these 1 off features only 1 client would use. All we would ever do would be client features, I was going crazy. It took a lot of talking, and still to this day I have to get him to think in terms of the product instead of the individual client.
Now we make more money, have more clients, and better our product for everyone which in turn gets more clients to get more money.
Open source does self-organise, and manages to produce some products of exceptional quality. It’s just almost completely unsteerable.
In a company, you can pretend to order people around. But the truth is that what really matters is how all the personal and political goals happen to align.
If that's true in an organization, its only because either management has failed to hire developers that can self organize, or management has constructed structures and incentives which inhibit self-organization by developers. Usually, both. Often deliberately, because line managers are often more comfortable passively recieving directives from above and crafting directives for below than any other mechanism of management, since this minimizes conflicts with those in organizational power positions.
Problem is that the industry is full of untrained individuals who hustled their way ”fake it until you make it” and will use all their political and manipulatoy clout to justify their positions and fight back any attempt at effective process engineering.
It is very convenient then to shift attention to inadequacy of others.
I don't understand how your vision of things is not also contributory to a strong divide.
Heard of Linux?
Can you find one dev that has ever disagreed with this?
The naïve thing to do when you’re a manager is to manage more in response to problems. When you start out with an agile process, and you manage more / manage harder, you end up with no agile process at all.
Scrum masters / agile coaches are very hit or miss. Just like managers, just like programmers. Management takes the blame because their failures have a larger blast radius.
