State of the Market

[Fraidycat]

Amazon laying off 30,000 corporate jobs. Not known yet how many of those will be in the UK.

There won't be a return to normal in IT jobs market until all these layoffs stop.

Why these companies carry so much fat around in the first place, some commentators are saying these firms did a lot DEI hiring and are now using AI as excuse to get rid.

[sadkingbilly]

and meanwhile, back in the real world, the market is still in a state.

[willendure]

Not my experience at all. Think Agile is a much better way of delivering projects than the old waterfall way. Agile projects are far more interesting and for testers you get much more involved with developers, so you get better technical skills. Only downside for Agile projects are Sprint Retrospectives, complete waste of an hour.

I think agile can be a much better way, when done well. More often than not, it seems to be done badly.

Same with the retrospective. Usually it is a waste of time as it changes nothing. Often seen it used just as an outlet for letting people vent, they get their say, and nothing is done. If it is done well, it is done to feed back change into the working process and iteratively improve things. This is pretty rare in my experience.

My last job the client used what I call "fake agile". They do sprints, so they think they are agile, box ticked. In reality it was waterfall. The agile bit just meant that everything was constantly in a state of disorganization and people could easily avoid doing much work. In reality, we just needed the spec to be signed off so we could get on with it.

So I would rank them in this order:

Best: Agile done well
Next: Waterfall
Worst: Fake agile/Agile done badly

[avonleigh]

She's clearing her throat.

qh

For 3 years?

[quackhandle]

Is contracting essentially dead? Feels like it to me - I'm lucky enough to be in a fairly comfy permietractor role, inside IR35 so whatever, but whenever I have a moach about there just doesn't seem to be anything to find. Not that I put huge effort in at the mo, but I can't remember the last time I got a recruiter phone call - when I first started contracting I'd have several a day, most days.

She's clearing her throat.

qh

[oliverson]

Not my experience at all. Think Agile is a much better way of delivering projects than the old waterfall way. Agile projects are far more interesting and for testers you get much more involved with developers, so you get better technical skills. Only downside for Agile projects are Sprint Retrospectives, complete waste of an hour.

Last place I used scrum the retrospectives were schedule for 2.5 hours with people bringing in coloured crayons and boards, cut out symbols, sweets and cakes. What a tulip show.

In fact this is opening some old wounds for me. In the team close to the one I was helping, the scrum master had a rubber horn, no joke. If somebody was late for the standup he'd sound the horn when they arrived! Not only that but he took great delight in throwing a ball at the assembled circle of participants in a random fashion, to signal their turn. WTF?! Next up the kanban board, or should I say 'information radiator'.

Think I may need some counselling to get over all this!!

[avonleigh]

Its so true!

I have only really had one very positive experience working in a scrum team, versus about 8 or 10 mediocre or terrible ones. And that was all down to the particular scrum master that we had who would never have accepted an answer like "still working on X". If the team was so much as a single story point behind his burn down chart he would go into hyper-mode and chase down where his missing point was. We hit every sprint goal, adapted how we worked as we went along, kept the stakeholders in the loop with regular demos etc etc. It was a lot of work and I did not always enjoy the process due to the amount of meetings, but ultimately came away with a good deal of respect for our scrum master - who also was an ex-dev and still a competent engineer, I should add.

The rest of the time, scrum was done in a half-assed way, led by non-technicals, just played lip service to the ideas etc.

Went to an interesting talk by Martin Fowler around the dotcom era time - he talked about a study carried out by IBM on the "mythical man month" where they put together various teams to solve the same problem. Their conclusion? The biggest factor affecting team performance was how well the team members got on with each other! I definitely agree. If you get stuck with a bunch of free loaders, or narcisistic personalities, or off-shore workers that you will never meet or give a tulip about, its usually terrible. Good bunch of UK workers that enjoy working together and go out for a drink occasionally - much better.

Not my experience at all. Think Agile is a much better way of delivering projects than the old waterfall way. Agile projects are far more interesting and for testers you get much more involved with developers, so you get better technical skills. Only downside for Agile projects are Sprint Retrospectives, complete waste of an hour.

[oliverson]

I agree. SCRUM/XP has changed things considerably. There is less wastage in a teams effort to deliver quality software.

It does mean that developers, testers are working harder in smaller, manageable, measurable chunks of work. Effieciency has increased and there is no hiding if you are a sub par contractor.

Although I prefer it the other way round, the new way of working is here to stay.

I'm afraid I don't agree with that. My involvement with 'agile/scrum' has been since 2008 after reading the article 'Scrum and XP from the Trenches'. Seemed like a good idea on paper versus 3 years of speccing out the system in an waterfall world, but reality is it's the biggest drain on resources imaginable. And 'waterfall' doesn't necessarily have to be this massive speccing up at the outset, depending I guess on the size of projects you're working on.

There's just too much pissing about and not enough doing with agile, planning meetings, retrospectives (repeated fortnightly maybe = overhead) daily standups (micromanagement in disguise), etc. Mega bloat. What started out as some lightweight idea has been industrialised by the consultancies and pushed into big business. It's anything but agile! Big business has been 'leaned on'.

Just looking at my contract history spanning 20+ years and 15 projects, around half of which have featured agile, by far the most successful outcomes did not use it. What was there instead was some kind of documentation / design document, drawn up either by the project 'visionary', including screen mocks, or documentation that has been created by devs in conjunction with the visionary's vision. To me, those succeeded because some upfront thought, analysis and design had taken place and it was quite clear what the developer(s) were required to deliver, and what the testers were required to test. Contrast that with a bunch of 'agile professionals' (PM's who can't get a traditional PM role and have had to market themselves as agile specialists), a bunch of devs who aren't really interested in 'as a [foo] user, I want to [blah, blah, blah] so that [blah, blah, blah]' kindergarten type, painting by numbers templates, with noddy notion of effort in the form of 'story points'. Utter nonsense. The business wants to know when something will be delivered, not this nerdy abstract notion of effort that maps to **** all in the real world. And don't get me started on TDD or BDD FFS!

Rant over.

[vwdan]

Is contracting essentially dead? Feels like it to me - I'm lucky enough to be in a fairly comfy permietractor role, inside IR35 so whatever, but whenever I have a moach about there just doesn't seem to be anything to find. Not that I put huge effort in at the mo, but I can't remember the last time I got a recruiter phone call - when I first started contracting I'd have several a day, most days.

[willendure]

I think that depends completely on the team. My last contract sure had its share of "sub par" developers. Sprint planning ends up with small tasks given increased story points, developers not necessarily picking up anything new when finishing said tasks early and daily standup a consisting of people saying "still working on X" even if it's gone over. Everyone accepts it implicitly because barely anyone is paying attention in these meetings anyway.

The amount of items completed in a sprint decrease naturally with team performance and some projects just take forever. Especially when you consider the additional time spent in meetings to communicate and coordinate it all.

Its so true!

I have only really had one very positive experience working in a scrum team, versus about 8 or 10 mediocre or terrible ones. And that was all down to the particular scrum master that we had who would never have accepted an answer like "still working on X". If the team was so much as a single story point behind his burn down chart he would go into hyper-mode and chase down where his missing point was. We hit every sprint goal, adapted how we worked as we went along, kept the stakeholders in the loop with regular demos etc etc. It was a lot of work and I did not always enjoy the process due to the amount of meetings, but ultimately came away with a good deal of respect for our scrum master - who also was an ex-dev and still a competent engineer, I should add.

The rest of the time, scrum was done in a half-assed way, led by non-technicals, just played lip service to the ideas etc.

Went to an interesting talk by Martin Fowler around the dotcom era time - he talked about a study carried out by IBM on the "mythical man month" where they put together various teams to solve the same problem. Their conclusion? The biggest factor affecting team performance was how well the team members got on with each other! I definitely agree. If you get stuck with a bunch of free loaders, or narcisistic personalities, or off-shore workers that you will never meet or give a tulip about, its usually terrible. Good bunch of UK workers that enjoy working together and go out for a drink occasionally - much better.