Industry standard redundancy terms?
Wasn't aware there was one. There is a legal minimum (https://www.gov.uk/redundancy-your-rights/redundancy-pay). Why would you expect a bank to go beyond the minimum?
Metro Bank has put "less than 90" IT employees at risk of redundancy as it endeavours to "support our new agile way of working" – agile being that nebulous yet overused term that can be heard in certain circles. Disgruntled techies working at the retail and commercial bank contacted us this week to inform of recent events that …
Firing a director is a completely different situation where employment law etc is concerned. Firing a director is not the same as firing Dave in testing.
First off, Dave has no legal obligations or responsibilities outside of his job roles and generally isn't accountable for anything.
Secondly, you can't really fire a Director (if they are actually a director) because they usually hold some sort of controlling stake in the business, will be registered on the company paperwork with Companies House etc etc. Dave in testing does not.
You usually have to buy out a director or come to some sort of mutually agreeable package if that isn't possible.
Getting rid of a director is more like a divorce than a straight up sacking.
How many directors of banks have controlling stakes? There are normally several directors on a board they cant all have controlling stakes. The fact is that directors are all chums, witness the idiot who crashed RBS and was promptly rehired. They can do 'no wrong' and arent fired, they are always given huge payoffs. Dave in testing will have done far more for the company if he has persuaded John in development to do the correct thing and checked that no crap is being released than a director who has expensive expense lunches, trips to Ascot and spends most of his 'working time' smoozing on the golf course. Of course those in charge of smaller companies are regularly stuffed because they cant afford the expensive accountants and lawyers, but this is a largeish company
Not so long ago the redundancy terms in the Financial Services sector were extremely generous. I know RBS was 4 weeks for each year of service when I joined, and prior to the takeover by RBS, some NatWest employees were on 8 weeks for each year of service, and I'm not talking Managers, "Appointed" grades (that's middle level techies and many other back office roles) were on these terms. Other Financial Services companies I interviewed with or worked as a contractor offered similar terms.
So "industry standard" was a thing
Times have moved on, and those who have started more recently do not get such good terms, but as an industry Financial Service was at one time a good place to be.
I was told a story by one of my managers that the head office of one of the then big four banks held a competition to name the new bar in the building (this was about 50 years ago, and I was told the story about 25 years ago).
Apparently, one popular suggestion was "The Weary Banker", which was obviously very appropriate (at least for the time), but excluded from the competition for fairly obvious reasons
Also where voluntary redundancy schemes are implemented as it can be cheaper and vastly less hassle for someone to choose to be made redundant than actually have to make people redundant.
Provide better terms to try and incentivise people to jump. It can work.......
Where I am you have to make a business case when the VR schemes come round. If manglement don't like who goes then they block it on the business case, now then problem that is left is there is now a record in the form of the business case as to why your post is not required........
In the current times the reorganisations that always involve cuts to the people actually doing any useful work come round annually. Unless you are very confident of either not needing employment in the next year or so or have something lined up, it can be a very risky step to take. We have seen a VR refused only for the post to be "deleted" in the next reshuffle.
I know several places this has happened... One place let go most of their network team, cause they were acquired and thought the parent company would let their network team take over - they were forced them back in ad contractors.. within a couple of months those folk went from driving banged-uo VW Golfs tand Focus's to top of the range shiny Aldo's and BMW.
What goes around comes around.
Because you'll find that historically a lot of blue chip companies offer more than the statutory minimum for redundancy. There's a legal minimum for holidays and salary in this country too, you're not surprised that these companies offer more than that too I assume?
I expect that the historically heavy unionisation of banking employees are part of the reason that they generally offer more generous terms. I suspect a new company like Metro Bank doesn't have much of a strong union though.
You are right there isnt a 'standard' but there is a 'norm', a lot depends on whether the company reckons it wants to recruit. The bad publicity of getting shot of staff is bad enough for recruitment, getting rid of them on bad terms will mean they have the choice of only those so desperate they dont care, never a good idea! The strange thing is that 90 jobs are removed, 65 created and yet they dont seem to make the obvious step of taking 65 from those doing the 90 now defunct jobs and retraining them.
Engineers and testers are still required regardless of waterfall or agile. The roles of program and project managers go but in their place you need product owners, someone with a strategic oversight to come up with the 'products' for the product owners to take forward (unless you are thinking they are going to find these new products themselves) and depending on the particular flavour of agile you may need all sorts of other people ... if you go the normal not really agile but it sounds like it route of SAFe you will need even more managers than before, of course with different titles on their clipboards like release train engineers etc. If you go scrum then you will need some scrum masters, if you go kanban you have probably made the right choice.
Why support a race to the bottom? Do companies pay the legal minimum, seeing people merely as a cost to be minimised, or do they see people as an primarily responsible for the wealth a company creates? Not all companies are the former. Most long-term successful ones are the latter.
It should end up better managed to be honest. You should have an agreed idea of what done looks like and that should include the required test coverage etc. You should have decent source control and automated build and test (regardless of what the process is to be honest).
I've come across software developers talking about "Agile" for many years now. My personal experience with Agile developers is that they're anything but -- they're good at buzzwords, UI prototyping and so on but very poor at actual deliveries. They also don't seem to be able to cope with any kind of technology that doesn't come pre-canned in some manufacturer's library or another.
FWIW -- I'm an embedded developer so while the work I do is strictly speaking 'software' I merely have to interface with the real software teams rather than be part of them. Our particular work is quite agile but it stems from design choices and the need to respond to changes (and humour the programmers with their limited toolsets) rather than being the consequence of a manifesto.
Agile should really be considered to be smaller, incremental and easily testable changes rather than large horrible very occasional updates to systems that are shite for years before a sudden large update that require many more weeks/months of tests to go finally test. Keeping updates to smaller, focussed areas and combine this with sensible compartmentalised code (hahahaha) and smaller updates should be less painful and easier to plan into normal operational workload.
Or, alternatively, use it as a buzzword bingo bullshit term about offshoring to cheaper, and unfortunately not always as good quality, technical labour.
The article almost reads that due to marketing fuck ups, other departments have to cut their head count. No mention of similar head counts in the marketing departments that cost the organisation so much in fines.
It's not a marketing fuck up, it's a failure to follow the regulations fuck up.
They are required to send SMS messages that you are in going into an urranged overdraft, and that additional fees may apply.
It's covered under the treating your customers fairly provision.
And that is why when anyone who has an account with elevated privileges should actually be with whoever is doing the end of contract procedure to verify that they have been:
disabled at the very least
disabled and random password unknown to person leaving
deleted (my preference)
The challenge comes because there is a fear of disabling elevated accounts "in case something breaks".
Just do it in advance but whatever, the person leaving should know that their access has been revoked. If someone then decides to reauthorise the account(s) no finger pointing can them come back to haunt the person who has left.
All too often basic user accounts get handled correctly but subsidiary accounts are left.
I had root access to all the linux and unix machines at the time.
The outsourced sysadmin company only managed the Windows network and external connection. They had no idea about the other half of the network and systems I managed. I doubt that they had the root passwords either...
I probably still have root access if I could get physical access to the building...
However given that I'd gone to work for one of the companies non-exec directors on a large payrise it was not sensible to be stupid.
stating "while investing in our colleagues and technology to enhance accessibility for customers." while putting almost 90 roles into "at risk of redundancy" & then wanting to retain 65 of those roles.
I'd hang on for redundancy and then take a break while looking for that next role.
"I'd hang on for redundancy and then take a break while looking for that next role."
Given Metro Bank was founded in 2010, and the terms are allegedly "not very good", how many of those impacted actually have enough years of service to take the risk of being out of work. Market does appear to be buoyant, but given the rest of the omnishambles hitting the country, how long will that last...
But it is a term very often used incorrectly by people, and then described badly by others!
It all stems from this and anyone that actually understands it can gain significant benefits that, I suspect, Metro Bank has never managed to grasp:
But that's the OPs point. "Agile" development with the deadlines defined at the start isn't Agile. Agile requires the whole business to adapt to incremental deliveries. That's what makes it so difficult to do properly.
My current project is supposedly Agile yet every quarter all the teams plan what they be working on for the next 3 months. That's not Agile. Nevertheless the Agile process (refinement, review, retro) is proving useful in driving out requirements, and while we've still not connected to the back end the customer has the first 4 pages of the journey. We've prioritised what we can deliver and the customer now has the value of being able to see the stupid design decisions they've made on screen rather than have us explain what's wrong with them.
You can rail against Agile all you like, it won't remove the requirement for you to understand the process for your next job. Learn it so you can use it to help deliver software better. Unless you genuinely believe the best way to deliver software is to spend 3 months thinking then a year building exactly what you thought about.
Agile, I always worry that such extreme short term planning will end up with LOTS more remedial work.
It is difficult to "half" design a screen and the whole back end and then later on think. Now how do we finish it? Agiles does NOT mean NO planning, total tosh.... Agiles does NO mean no documentation!
Smaller steps maybe , more frequent releases but except where you are working on a Micky mouse project if you do NOT plan you will fail.
Yes, it builds in small increments, no that doesnt mean that you have lots of fixing to do later.
It is up to the engineers to find out about the long term goals and design an architecture suitable for that. Yes agile CAN design things in the early increments. Yes the product owner should have a decent backlog with work in it you can look at. Yes of course it will change, but the point is that even if you spend 6 months up front deriving the absolutely correct architecture and building blocks, planning all the tasks to the nth degree, allocating work to Fred, Bob, Jim, Sam etc etc you will find a few hours/days/weeks in that some bright spark has decided to ask for a change and you go through the whole change process and the rework to all those months of planning that is caused.
Change is inevitable, the architecture can make the change easier or harder, but change is going to happen
From the comments in here it's clear that being "fully aware of the Agile manifesto" and understanding how to build software using the Agile manifesto are two completely different things.
Yes, every waterfall project now has a veneer of Agile. That doesn't make Agile bad, it means management are stupid. We don't have to join them.
Understanding how to build software using Agile is easy. Understanding how to manage cascading dependencies between Agile teams while reducing total cost of ownership for a large "heritage" IT estate is a little harder and the Agile manifesto doesn't really do operational support or cost management, it's all about fast delivery of, frankly, prototype software and changing it before it gets through internal compliance let alone the industry regulator.
it is a term very often used incorrectly
Never a good sign that your manifesto is gaining traction.
Agile, as widely practised (relatively short development cycle, only high-level design, small and discrete functional units) is fine for projects that are susceptible to that way of working - for example incrementally-changing UIs that are basically shuffling data between the screen and JSON talking to incrementally-changing back-ends shuffling JSON over an API in and out of a data store. It's probably fine for your average online banking system.
The trouble is that average online banking systems are ten-a-penny. There are loads of "disruptive" fin-tech outfits with very similar online platforms desperate to get their customers to pay over the odds for "premium" features they don't actually seem to want. It would probably make more sense for Metro just to buy one of them.
Though, in truth, they have other problems.
That depends who we let define it. If we all agree that the only true agile is the agile that can be agiled from the manifesto people, assuming we can actually arrive at a factual definition from their list of rather vague principles, then the statement can work. Otherwise, we end up with about ten things all called agile which basically boil down to "whatever we used to do in this company, but now we call it agile and use some words that came either from the agile manifesto or some other people who also liked it". To me, this morass of definitions is a great case for using the word nebulous.
But let's assume that we can throw out the many companies who use agile only as a buzzword. They're using it incorrectly. That still leaves us with the manifesto and principles list as you have linked it. Which I still think is incredibly nebulous. Starting with the manifesto itself, we get lines like this:
"Through this work we have come to value: Working software over comprehensive documentation"
I've debated this with people before. We cannot agree whether this means that documentation can be ignored (a lot of people take it this way and I think that's bad) or calling for a balance (essentially saying nothing). The manifesto has several things like this, where the comparison either leads to harmful absolutism or provides no information whatsoever about how to do both things.
The principles have more instructions. Maybe they will be clearer. Let's look at the first two (numbers mine):
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
So deliver early, then accept changes late. Have a development timeline which has a late, but deliver continuously. These aren't entirely contradictory, but it doesn't really answer anything. It ends up meaning "do whatever the customer tells you to do when they tell you to do it, whether or not it's reasonable". I can guarantee that while an employer might occasionally "[g]ive [the workers] the environment and support they need, and trust them to get the job done", the customer will never do the former unless informed about the needs at the beginning and the latter can't be guaranteed either. So how does one balance the desires of a nontechnical and demanding customer (or manager) with all these lovely sentiments? I certainly don't know, and the manifesto doesn't really say. That is why it is nebulous.
The thing is, argue against the statement?
Would your customers prefer exquisite documentation about the project and the code base, or actual working software? Yes, as professionals we know the value of documentation but it's not the point of a software project.
Would your customer prefer working software now, with continual updates to improve it, or wait a lot longer and then have to wait another lengthy period for any changes?
Would you adopt a development methodology that doesn't support changing requirements, even late in development? Have you ever had the luxury of an implementation project that didn't have those?
They're not vague statements, they're basic positions and principles. They're not prescriptive, they trust you to be a professional and take ownership of your own methodology. They don't tell you to do this or that, they encourage a mindset.
Is that wishy-washy nonsense? Only until you sit and think about it, properly, and explore how to incorporate those principles into your own work. Successful software development in a rapidly changing environment with constant resource constraints is hard, bloody hard, and the Agile Manifesto merely articulates the approach that a very large group of experienced professionals have found to be the most effective.
Disclosure: I've successfully delivered software into a production environment at a bank using Extreme Programming, and worked in and alongside teams using agile methods and methodologies for two decades. They deliver.
"The thing is, argue against the statement?"
Sure. Let's try that.
"Would your customers prefer exquisite documentation about the project and the code base, or actual working software?"
Both, usually. In a project where documentation is weighted as heavily, then things take longer, but the documentation matches. Compared to the many projects I've seen where the documentation has problems, that is usually better. What happens there is that documentation is patchy, sometimes out of date, and you get more support requests. That's taking up your time and theirs because the docs were incorrect or missing. If I leave a job with documentation in place, someone can pick it up later. If I leave with patchy docs, they will either read those and come to hate me the second or third time the code doesn't match what they read or will have to call me to ask for help.
"Would your customer prefer working software now, with continual updates to improve it, or wait a lot longer and then have to wait another lengthy period for any changes?"
This one is easy: yes, they would prefer the agile method in most cases. However, I generally wouldn't. If the customer wants something, they should mention it at the start so I can plan for it. If they request a change 80% of the way through their original request which requires a redesign, they've wasted a bunch of my time. If they don't care how long I spend working on it and they pay me for it, that's fine with me. They do care about both things, so it's not. I'm fine with change requests that are minor, but nontechnical people rarely understand what is a minor change and what is massive.
"Would you adopt a development methodology that doesn't support changing requirements, even late in development? Have you ever had the luxury of an implementation project that didn't have those?"
Of course not. However, my methodology is to try to gather enough information so that there are likely to be few major changes at the end, not to embrace the chaos and let anybody change whatever they want.
"They're not vague statements, they're basic positions and principles."
Which get constantly redefined and which don't actually tell you anything.
"They're not prescriptive, they trust you to be a professional and take ownership of your own methodology. They don't tell you to do this or that, they encourage a mindset."
They encourage a mindset of basic platitudes. "Trust [the workers] and give them what they need" isn't original and it doesn't tell people anything. It's like telling people to be nice; it's better if they are, but exactly how that gets implemented and what benefits it brings need more elucidation.
"the Agile Manifesto merely articulates the approach that a very large group of experienced professionals have found to be the most effective."
Except the only thing I can understand clearly from their proposal is "accept change all the time". Everything else has multiple possible meanings.
"Disclosure: I've successfully delivered software into a production environment at a bank using Extreme Programming, and worked in and alongside teams using agile methods and methodologies for two decades. They deliver."
And I work on an agile team as well. It's fine. If we're actually agile, though how could I know? Our documentation does have the patchy problem, so maybe that's a good sign.
I think a lot of companies that do internal coding already did a lot of the agile process. Probably less in contracting or consulting, though I am young enough that I haven't seen a lot of what things were like before the manifesto. Accepting change didn't have to be written into the requirements if managers were still demanding things get changed, and knowing managers like I do, I don't think they just started doing that.
"agile", "nebulous", "balance the desires of a nontechnical and demanding customer"
Well.....at one large retail shop where I worked, the business side had a fantastic answer to the first two words....and an established process for handling their IT requirements. It worked like this:
1. We are fed up with IT (and external IT consultants) talking about "methodology", "agile" and so on.
2. Our senior business leaders went to a show, saw some demos and came back and bought a package. Yup....cash on the barrel head....we own the package.
3. Sorry, we forgot to involve IT.....see item #1.
4. But now we've told you folk in IT, you need to step up and INSTALL AND DELIVER the package. By the way, the vendor says it's easy, should only take a few weeks.
5. We've already started doing our user training.....
That's how one group of "demanding customers" got the "solutions" they were looking for!!
And the IT group was ALWAYS on the back foot. What does the Agile Manifesto have to say about that?
Well, the Agile Manifesto principles list says that the business people and the techs should be working together, and they weren't doing that, and it said to trust each other and give them what they need. I'd say it disagrees on two points. Why I'm being asked to support a manifesto I mainly opposed in the original post is beyond me though.
As for this circumstance, I don't know the organization and I don't know what the IT department was doing. From your tone, it sounds like the external vendor provided a product which accomplished the goal, so the business got what it needed. I must also caution you that it can and does frequently go the other way--the vendor sells a product, IT is told to install it, it takes forever, breaks a lot, doesn't do what the business needs, and the business people have lost their purchase price. That's one place where the manifesto is actually correct: the business people and the techs should work together in the meetings in order to test out the products being offered to ensure the first option happens and the second is avoided.
So, it looks like they're busy sacking 90 devs and whatever work was previously being done by 90 people will henceforth be done with 65 because Agile. It smells like they're trying to clear out the current crew in order to replace them with a fresh-faced bunch.
The Manifesto came out in 2001 (IIRC). Metro's been going 11 years. What's been going on for the past 11 years there if they're not already at least partly using Agile? Do they now have all the proper frameworks in place, or are they expecting to do that with the new 65 people, who may or may not be experienced in the finance world? It all just looks like cost-cutting.
I predict future security excitement when this shambles hits the fan. I'm glad I don't bank there.
I spent six months at Metro. The non-tech side of the business is a friendly gig, if a bit big on drinking the Kool-Aid. But the tech side of things... Depressing was what I thought. Their timing was awful, as they launched just before or just as a lot of new technologies came about that were transforming online banking. So despite being new, they were stuck in the past. Because the techies were given short shrift, there was a lot of churn in the teams and everything was reactionary. I left out of sheer terror of being left on call, since it was guaranteed you'd be woken up 5x a week.
That being said, people were mostly good at their jobs and the horror behind the curtains was rarely public facing. People were friendly enough, but most of them wanted to transfer the hell out of frontline support asap. Ironically, most of them wanted to go to the teams being shredded now.
You know you're in for some fun when you read "A spokesperson at Metro Bank...". What is wrong with "Metro Bank said..."? Or "An official speaking for Metro Bank..."? Or even "An entity speaking for Metro Bank..."?
Thinking that "spokesman" always has gender is illogical.
When used in the context of someone authorised to make a statement on the behalf of a company, the context of the word "spokesman" implies the fact that it represents an authorised company official. The gender of an official is not assumed, implied or relevant.
The gem of the article is the spokesdroid 's reply though:
"We are moving to an 'agile' way of working and as a result are resizing and restructuring our change and IT teams. Fewer than 90 roles are impacted and we are creating 65 new roles in the IT and change world to support our new 'agile' way of working." ... "Colleagues impacted by the restructure are free to apply for the new roles if they wish to. We are currently running a consultation process with impacted colleagues."
The killer being the single quotation marks around the word "agile", I can just see the spokesman making quotation signs in the air with their fingers. I won't even discuss what "Impacted colleagues" brought to mind!
Let me try translating this utter lizard speech into conventional English: "We need to save money or the CEO can't afford his next yacht. So, all of you who are over 40; you are all going to be fired with two week's pay. You're welcome to apply for a new job here, we're hiring! (Just for less than we used to pay, on a weekly contract with no pension, holidays or health benefits.)"
Who would write this kind of effluent as a company statement?
My last place introduced Agile.
It turned into anything but...
It was used by management to micro manage development teams and resulted in a huge increase in costs and development times.
On one project I was told to only implement exactly what was in the sprint and ignore everything that will be needed later... we were implementing something that had to meet an external standard and set of tests...
Each sprint resulted in more and more rework. This was probably one of my most demoralising periods of my life.
Upfront thinking and design was considered a waste of money...
I'm still using Agile concepts but I'm being very pragmatic about how and when. I still keep my Scrum masters and product owner certification upto date though...
It's called refinement in Agile. Wondering how closely you were following the manifesto if you thought "bung stuff out we know isn't going to be any good" was part of it.
People over processes is just a simple of way of allowing the team to work around procedure. For example, we had a story that wasn't sized but looked like the next decent piece of work we could pull in. We're not supposed to pull unsized work into sprint. So I started on it a day before we pulled it in. People over process. It's not tricky.
I argued in every retrospective and show and tell that what we were doing was not sensible and did not match the Agile manifesto.
I tried in the planning and grooming sessions to engage with refining the stories. On more than one occasion we were told not to read or re-read the standards or look at the backlog before the meetings.
At one of these meetings I was told to stop reading the standard and to put my estimate forward based on the single paragraph presented by the product owner... Given that I was also a subject expert in what we were engaged to develop, maintain and support this just resulted in an infinity estimate with the rest of the team declining to estimate or withdrawing their estimates.
I was told in no uncertain terms to shut up multiple times in front of both the team and management at the retrospectives and 'show and tell'...
I had a record at that company of delivering large software projects within 5% of estimate (within the contingency), usually on time.
It took around 9months for the whole system to collapse... I spent another year there delivering a large project which was driven by an external customer which I managed. TBH I wish I had left when I'd been told to shut up....
......and then there are another interesting words......"architecture", "scope" to name two.
The Agile Manifesto is SPECIFICALLY ABOUT SOFTWARE, and it implies that everything about "software" can be focused on the development process for a specific application. The participants in this very limited scope definition are:
- a customer (see "product owner")
- a defined software application
- a development team (see "scrum", "scrum of scrums", etc)
Now with this narrow definition of "agile development", the Agile Manifesto reads quite well! But in the real world, the enterprise "architecture" is comprised of multiple processes and multiple IT assets, some of which may have problems with a wider definition of "agile":
1. Many enterprises have many package applications (maintained by third parties). How does "agile" work there?
2. Then there's the problem of "scope". How to ensure that different "agile" teams don't end up trampling over one another. After all each team has its own set of "user stories", many of which will only be assessed in the future. And (of course) there are no "project requirements" which might be compared across teams....eliminating "requirements" after all was the main reason for "agile" in the first place!
3. The IT planning process probably spans a multi-year timespan. Architecture and budget planning both need to use this horizon. But the average "agile" project only has estimates for resources and cost for the next five minutes! So.......is "No long term planning" the answer. I guess the CIO and CFO would say "You are kidding!"
I suppose this rant could go on for a while.....but I guess that's enough for now!
Biting the hand that feeds IT © 1998–2022