|
OK, my company decided that we are Agile. Fine, I've been in agile shops before and it worked but this has a few oddities. OK, many oddities. My C# niche has always been leading edge technologies. I tend to write BIG C# AJAX base Intranet or data processing Windows Services. I could go on about the reasons my development fits the agile model poorly but I end up with two questions. In a large company (> 3000 developers), my previous (Db master) manager created a very small (< 10), very highly skilled team that provided a service to the to the rest of the company. (We never had layoffs, our team was too lean.) With the re-org, we lost critical skills and knowledge including our C++ guy, our Db cultural knowledge and LF who is a as red as I am blue, but I love her for her mad skills... that I can't describe but rely on. The team is no more than 8 people now. I'm a C# expert writing YAML and PowerShell scripts for AWS. Our Db guy does his thing and helps me. We have RPG specialists because we also consume data from iSeries machines. We are told that we all interchangeable and all should be able to do any of the tasks in the backlog as they come up in priority (or write user stories). This interchangeability of skills seems absurd but is "easily" fixed by "Knowledge Transfers". (Seriously? No one can even test my software without my technical help.) Knowledge transfer? I've spent years upping my C# skills from MS ecology to .Net Core, Open Source, git, AWS, etc. If needed though, I'm supposed to be able to do a Knowledge Transfer to any other team member so they can work on my ... their project. Same thing with them doing a Knowledge Transfer to get me up to speed with RPG, iSeries or the crazy SQL that T writes. So where did that idea of identical skills on the team come from? It seems like on surgery day, the anesthesiologist, vascular surgeon and the neurologist decide what role they want to do... maybe pull in a nurse to do the skull opening.
|
|
|
|
|
I think that idea came from the one thing you already mentioned. You have had no layoffs and someone in HR noticed that your team hasn't had any layoffs. So they wonder why you are too lean and then they think like most people in management that a coder is a coder is a coder and you are all interchangeable and they begin to think hey lets make them cross train each other so we can make them even more lean. and the cycle repeats until the team goes away.
Having been part of one of these teams that was highly qualified and doing great work. And watching it happen where we had to cross train each other. It sucks.
To err is human to really elephant it up you need a computer
|
|
|
|
|
This interchangeability is supposed to be a feature of Plan, Build, Run or maybe Agile. It's not coming from HR. The company has only been able to hire one contractor with the C# and AWS skills I've worked to develop. Ain't gonna be no cross training to a SQL specialist or RPG person.
|
|
|
|
|
You may wish to explain to them that the knowledge transfer they want, or as you may consider it, interchangeability, can be explained to them thusly:
Next time you need your teeth cleaned or a cavity filled, just go a the proctologist. A doctor's a doctor, after all.
You can add to it that you mean that both literally and figuratively.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Quote: Next time you need your teeth cleaned or a cavity filled, just go a the proctologist. A doctor's a doctor, after all.
Or the reverse. Need your backside checked. The Dentist can do it. The drill will work wonders on your firmament.
Thanks. I loved your quote by the way
To err is human to really elephant it up you need a computer
|
|
|
|
|
As a (possibly) self promoting note, the Ravings en masse[^] (just above the quotes on the page) has a lot of quotes - the ones on the right side are mine. Also, one on the left (guess which one?). I don't expect anyone to like them all . . .not even me.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Michael Breeden wrote: This interchangeability of skills seems absurd but is "easily" fixed by "Knowledge Transfers"
It's not absurd.
If one of you die and everything stops because he was the only one to know how one specific things works then it is a failure on you, your manager and the company.
You do not need to be 100% replaceable, but you need to have some sort of internal training to share as much knowledge as possible.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
In a group of n, the truck (lorry) number has to be >1, not n.
|
|
|
|
|
That might be a management failure but some of the skills were developed in house. You can't hire them. How are you going to hire a C# AWS Lamabda specialist? Worst of all, our C++ specialist who designed the system 20 years ago... and is going away, is a real live genius. Are they supposed to hire a backup for all of us? I was supposed to transfer one of my systems to another team. It never happened because the resources simply aren't there to take on a fault tolerant WAN project I took two years to develop.
So, am I supposed to teach everyone my AWS, C# skills? Not gonna happen.
What I have done that management should have is I have interviewed everyone I could about the critical processes only they knew about, recorded on Zoom. No one knows that. Still, no video is not going to teach anyone my skills.
I make videos just to show how to test and use my Intranet pages I make. ... I don't do simple. That is not what my team does either.
|
|
|
|
|
Michael Breeden wrote: So, am I supposed to teach everyone my AWS, C# skills? Not gonna happen.
Maybe not everyone, but surely you want at least one other person to be able to step in if you're not available. Or do you not take vacations, have a daughter who's graduating, a son that's getting married or parents celebrating their 40th wedding anniversary? If so, what's the plan when Something Bad happens within your bailiwick? Do you have to leave off your family/personal time and deal with it?
What's the plan when your C++ guy goes away, who can fill in for him? It doesn't sound like you'll be able to hire in to replace him. All that specialized knowledge is going with him. If you were management, what would your plan be to be able to continue to provide service to your customers when he leaves?
Maybe rather than the proctologist/dentist example given elswhere, consider that both a cardiologist and a brain surgeon would be able to assist in a mass casualty situation. And both are continuously training the next generation, and you should be, too.
Keep Calm and Carry On
|
|
|
|
|
Nope, no backups and it's unlikely that you can hire that kind of .Net AWS expertise. Our CloudFormation requirements are nutso partly from lack of Cloud support personnel and residual panic from a ransomware incident. I took two days of PTO (Pretend Time off) for my son's graduation and still did a 60 hour week. My motto is "no rest for the wicked" but I'm leaning towards "work till you drop" as it is the only way I can see to solve my professional and personal problems. ... I exercise during Zoom meetings as it is the only time I have for it.
As for the C++, I made videos of what I could. No one really knows about them though and I'm not sure I'm telling. Also... he was a genius. A dangerous thing to rely on in an IT group.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
