|
From a rational and logical point I agree completely. But we're talking Management here...
This pre-supposes that the company are prepared to invest time, money and resources into 'cross-training'.
What if they aren't?
What if they are so out of touch with the jobs you are doing that they literally don't understand it or what it entails and aren't interested in finding out? Because then they might have to pay you more...
I have to put up with this management-wish-fulfilment crap on a daily basis.
"Just teach so-and-so how to do it (wave of hand) - how do I teach so-and-so when they have no knowledge of the subject whatsoever, no interest in learning it and no time from their own work?
Will be interested to see what happens when I retire next year.... 
|
|
|
|
|
All this training others to do your job. You can do that, but 1 month after you get them trained, they get another job with another company. You cannot pre-plan life. Like most things, you deal the hand given you at the time. Crap happens.
Meanwhile while you are training, you are losing money in time spent on another dude that could just as well take off next week.
And don't start me on Agile, the nanny philosophy...talking about what you should know and do without the crowds. Oh, the waste of money and time.
|
|
|
|
|
The original concepts for Agile were based on one programming Language (I believe it was Java).
And I don't believe the DBA was EVER imagined to be interchangeable with programmers.
Neither was the team lead, or the customer representative.
I say this because you are correct, it is kind of insane, in todays technology stack, to expect anyone to know every piece of technology.
On the other hand, Agile is supposed to be "anti-fragile", meaning the steps to recompile and redeploy a system after any change MUST come along for the ride.
So, the natural tendencies of people is specialization. And we sometimes forget that at any given point, someone green should be able to come in, build the system, and test it without fear or favor.
That's the CONFIDENCE in the system that I believe Agile was solving (at least that's the core part of it we leveraged).
Now, when you bring in all of those "specialties", you are trying to run a very complex system in a lean manner. And if you are a HUGE company, then I would DOWNGRADE the rule to say "Anyone from X Development team (RPG), should be able to come in, and replace the previous X developer".
So, Everyone is REPLACEABLE, not not interchangeable. These could also be called Domain Experts, or Domain Developers in my book.
The Utopia your company seems to be aiming for has a cost to it. From my perspective it will either cost too much to maintain, or it will cost too much turnover to maintain, and yet another company will FAIL Agile, and Blame Agile for the failing.
Finally, I will remind you that the guys who created this were worried about MONOLITHIC systems that would become fragile over time because the knowledge that created them had left the building, and anyone new was fundamentally (or should have been), paralyzed by FEAR over compiling a system that had not been touched in DECADES, and needed the confidence to know that nothing was missed. So even a small change could introduce bugs. Hence the "Testing" (more like panic checking)... That's My Opinion, and I was an early adopter of MOST of their ideas.
|
|
|
|
|
The history of economies is one of specialization. In a shop that has its fingers in as many pies as yours, thinking that the developers should all be interchangeable reveals a shocking level of ignorance.
|
|
|
|
|
Agreed!!! Very frustrating also. I have pointed out that it is a lie like the other misinformation that curses our society, and quite dangerous. They simply ignore it and since they seem to believe in (Agile) process over people, I'm a bad guy for objecting. I'm not always popular in Agile Training sessions. I am the last developer standing though. The C++ guy is retiring because of the absurdity of this. I could go on about the intellectual crime this is , but ...
What I want to know, is where did that Interchangeability of skills idea come from? Then maybe I can answer it.
|
|
|
|
|
I'm no Agile expert but am unaware that Agile mandates this. It can happen wherever managers have little knowledge of software development and think that developers are like assembly line workers.
If one guy is leaving because of this, the reason for his departure should be conveyed to management. If they're not willing to listen, maybe you should start thinking about your next job.
|
|
|
|
|
One of the core agile principles is “people over process”. Has anyone actually read any of the literature in the org.
Interchangeability comes from outsourcing.
I am a proponent of don’t learn it until you are going to use it. If you cross train someone and they don’t use it for 3 months they will have 1% retention.
|
|
|
|
|
That's the cute part. I'm trying to slip that in as "Process Over People" because that is obviously what they have chosen and I don't think they are bright enough to realize what I am doing. I want it to become the company Agile canon. Eventually, someone will notice. We have one contractor on PTO that would notice immediately but he might think it funny enough to say nothing. I want to hear it repeated just once by the Agile leadership team.
As for outsourcing, what do you think the chances are of picking up a resource with really great C# in AWS Lambda skills as well as the CloudFormation expertise to make the system? My company decided to go all in with Lambda, many thousands of lines and many libraries in a single application. AWS says not to do that. Even our Cloud executive says Lambdas should be no more than 70 lines. This project is over 135 .cs files. I warned them it would be unmaintainable but they ignored that too.
I've spent 3 years ramping up from MS C# ecology to Open Source, .Net Core, AWS. I got my AWS Assoc Arch cert. Tell me about trying to retain what you aren't using. According to this I also need detailed knowledge of iSeries as well since we consume that data. There are some skills in our original team that I can't even describe well, but everyone is supposed to know them. The interesting thing is that their Interchangeability ideal is very similar to the communist ideal. I doubt they are aware of political history though.
|
|
|
|
|
The salient point about Agile is that, with great agility, management can declare their company to be Agile, without any clue. Not that anyone actually has a clue as to what Agile means in terms of skill sets and practice.
Thank goodness neurosurgeons can't willy-nilly declare themselves to be brain surgeons.
|
|
|
|
|
I am a brain surgeon. Thank you for respecting that.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Yes, my company is apparently agile. Or so they tell our customers.
Luckily this isn't very noticable for us developers.
|
|
|
|
|
To any organisation and 3000 devs is a lot, having and indispensable person is a risk, having a small team is a larger risk. You really can't blame them for trying to mitigate the risk.
While you are doing all that cross training you will of course be expected to produce at the same pace or faster.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
They aren't mitigating the risk at all. The rest of the remaining team members don't even know C# or C++ so I don't see how cross-training is feasible. I'm the last developer resource for 3.5+ important projects and while I've been working for a long time for cloud expertise, there is a lot of it and they do not see that as requiring time to develop. They have lost one totally indispensable person at least, perhaps 2.
Again, I am most interested in where they got the idea that all members of an Agile team had interchangeable skills. Then maybe I can figure out the context of this. It was not HR. Any idea?
|
|
|
|
|
I would assume you have a risk management team or even person and they should certainly have identified the glaring operational risk you represent.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
No. We've had a great deal of management churn and their main focus is digital transformation. They are still panicked from the ransomware attack. It was recognized long ago by my manager that I owned too much, but the C++ guy could have gotten a new C# person up to speed. He's on Run now and soon gone cuz he hates the way things are going. When it was proposed, I told them not to use AWS Lambdas for huge projects. There is little advantage and takes great expertise to maintain. Expertise that is rare and that I am still working to develop. Lambda is supposed to be small functions for micro services. The Lambda project I wrangle now is over 135 .cs files. Hey, it will be OK. We have lots of new VPs. I was known for risky behavior as a skier, big wave eater, and lobster hunter. These folks would really impress me if it was a calculated risk. Too many lies and illusions. I do push back. Lies have never worked as a strategy for me.
|
|
|
|
|
The idea of team members being able to do your job isn't far-fetched.
When you go on vacation or resign, your work should continue.
The idea, however, is that people with the same skill sets are interchangeable, not people with different skill sets.
Just tell your manager you'll do his job today and he can do yours.
When he tells you that's ridiculous just tell him the difference between your two jobs are about as big as between you and the RPG guy.
Although I think you and the SQL guy, at least, should have some overlap (not necessarily vice versa, most programmers know some SQL, but DBA's often aren't programmers).
|
|
|
|
|
This is great! I'm fairly well trained in Agile and I could find my way around JIRA. Let them find their way around my work. Thanks for a great tactical suggestion... I am working my way up the chain today though, asking where they got that interchangeability idea. At 2 is the meeting with the top Agile person and I'll ask her.
As for me resigning, they broke up the band already. Two of the critical people are now on the Run team and both want to quit. I'm the only developer left on the Build team... as we do the digital transformation dance to AWS ... Lambda. You tell me how that's going to happen. I told them when they proposed it that it was an unmaintainable system. AWS says not to try to convert big applications to Lambda. Even our Cloud top executive said a Lambda shouldn't be over 70 lines long. Ours includes over 135 .cs files. I'm stressed out enough that I can't sleep.
modified 10-Jun-21 6:05am.
|
|
|
|
|
Michael Breeden wrote: I'm stressed out enough that I can't sleep.
This is a sign you need to switch over to Team Run as well, after doing one last project on Team Build: An application that automatically locks your computer at 5PM on workdays and won't allow an unlock until 8AM the next day.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
When they want a generalist and specialist in one package 
|
|
|
|
|
So where did that idea of identical skills on the team come from?
higher in the hierarchy a thing must have changed. maybe as far as two years ago.
although it will be great for all of you to make that fast knowledge transfer, the situation smells like someone has been appointed to cut the workforce or someone (presumably new in the management) wants to show off by cutting costs.
if you stay and they cut somebody else you'll get overloaded with work. all i say is based on my personal experience, i may be 100% wrong.
my tendency is going to places that are more relaxed for work, even if they pay less. that is, if one can afford such a job.
|
|
|
|
|
It is a goal state that everyone can do any ticket. Avoiding silos is a Good Thing(tm). It's also good for your career if it lets you learn new things. That said, it is a management failure to think this will happen on day one.
If management wants this to work, they have to acknowledge that software development is an impossibly broad field to master (like, say, medicine). They then must dismantle all the specialist cross-functional teams and create teams based on skill set (a C++ team, a db team, etc). They also have to allocate time for cross-training and documenting. Betcha they didn't do that.
They probably expected agile to work by magic. Just by saying it's name, they could summon agile. I wish it worked that way but it doesn't.
|
|
|
|
|
I don't see how specialized teams could help any - C++, Db, etc.
I don't think they consider that SW development might be difficult.
I document. No one else does. ... Ya know, all the other teams are far bigger. Maybe that helps them.
I think there will be panic before magic.
|
|
|
|
|
I have run into the same Agile mentality at my last two companies. It seems that developer interchangeability is "the elimination of siloed skills" that is the Agile buzzword of the day. Both companies were experiencing developer turnover and reductions.
|
|
|
|
|
Fascinating. Now that sorta makes sense with what is going on. I wonder if they notice they aren't producing any software?
Were those companies choosing to reduce the number of developers or were they just leaving?
I think the question will be "are you still going to produce software"? And then "who is going to produce it"?
... So, "we need interchangeability of skills". "That sounds like a great idea, I could use some help". "How are we going to do get people up to speed with the tools we use"? Ya know, it really fits with the amazing loss of talent we've had. 2/3 of the team is gone. There is no one to maintain the systems I built and always maintained. Well, ... the pressure is on. Yesterday, my former manager said that the project timeline would need to be doubled. The new "HR manager" said that I and the two new guys (MS ecology, not Open Source) would need to step up and start that project moving. I mentioned that I've been working 11+ hour days. Better still, I told them from the start that that technology was unmaintainable by mortals. I wonder how long it will take.
|
|
|
|
|
First company was restructuring and attrition. Second company was a mixture of constant firings, attrition and dictatorship Agile driving good developers away. Three developers left my first month and the rate reduced a bit, but was still constant. I was a contractor let go after 9 months.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
