It’s easy to blame management. In my experience the radicalism of some agile coaches and scrum masters helps to fuel the divide significantly.
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.
Give it a few years.
I think the GP meant "in hospitals" as in "among medical people", doctors and nurses, not IT staff.
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).
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.
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.
Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.
Can you find one dev that has ever disagreed with this?
You need people that care about the how you do it as much about the why and the what. Everything else is going to be disfunctional rather soon.
If you care about quality and productivity, please quantify those and present your findings in terms of tradeoffs.
Get to rewrite the micro services, Kotlin, Cassandra, Kafka, mongoDb hardly documented, back into C# on top of SQL Server when the teams have left for the new jobs after haved pimped up their CV.
Both React and Vue.js are now older than jQuery was when both were released. Same for Babel and Webpack. Typescript is older than all of these. SASS/SCSS also older than Typescript. Those are the only things you see in 99% of the frontend job descriptions out there.
If anything, frontend is kinda boring, and it can be argued that some of those tools above need some disruption.
Heck, Microsoft has completely changed the way of writing native Windows apps in the last 10 years more ways than Javascript frameworks have introduced new stuff. Apple even changed the language to one that (unlike Typescript) is not backwards compatible. Complaining about the JS ecosystem evolving too fast is anachronistic, that happened more than 8 years ago.
No they haven't. You still write them in Delphi or Free Pascal / Lazarus just the same way you did ten years ago.
Oh, you meant "the way of writing native Windows apps" with Microsoft tools? Yeah, well... Heard the old joke about the guy who complains, "Doctor, doctor, it hurts when I do this!"? My answer is the same as the doctor's: Well, don't do that then.
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
It is very convenient then to shift attention to inadequacy of others.
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.
That’s a view in many large corporates. However, in product focused companies and many startups every developer has to have a customer focused mind. Every single day.
We have to specialise at some point - not everybody that gets hired is going to be an ace industrial strategist. Few devs know how to qualify a sales prospect. If you have such people in management, then as a dev I don't want to do their job for them; they should set strategy and find good customers.
I guess we all have differing perspectives on this kind of thing; one's perspective is partly formed by one's experiences.
I'm not talking about startups - I never worked in one. But I've worked for quite a few companies with < 20 staff.
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.
The project I work on has around 100 regular contributors, but also a few small teams, either volunteer or staff, who meet regularly and make sure things move forward in a coherent and sustainable way.
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.
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.
I don't understand how your vision of things is not also contributory to a strong divide.
Heard of Linux?
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.