Forum menu
“Road Map” – to describe a set of pre-planned, cast in stone, organisational changes.
Sounds like an efficient use of language.
Iconic - it seems that every article on the radio has to reference those little Russian paintings.
Reach out - As has been said before, OK If you're in the Four Tops
In and of itself- Uh?
Just get on with it - it's like saying "I'm a stupid person".
It needs to lose a lot of the * language though Scrum master (really!) Sprint – what about sustainable pace you *tards?
And don’t get me started on ceremonies – ceremonial they are not.
😀
A few months ago i came across someone who used these....
Metadata Universe (A single software platform with lots of data in it) and;
Metadata Multiverse (two or more of the above that connect with each other)
Needless to say he was a consultant.
Look guys, if the scrum master can just organise a stand-up meeting we can all get with the programme.
"You do you" - I can't tell whether the people who use it are unwittingly or intentionally sounding passive aggressive by using it.
Ive just in-boxed an email with the phrase ‘commencement of our coordination engine’.
"In-boxed"? Is that a verb?
slowoldman
“In-boxed”? Is that a verb?”
Keep up grandad.
I quite like using Agile for project management, but it suffers from the usual bollocks so people can make money out of consultancy and training.
Get out.
Agile is bollocks speak from PM's that simply means taking on too much work and under delivering on everything.
This is the reaction of everyone I know when a PM comes into a room and talks about agile.
Agree on KPIs/Metrics as well, too often they are an excuse for piss poor managers not to actually show any leadership or critically appraise a situation - they just fall back on KPI's in lieu of doing any actual thinking.
Not management speak, but one I hear too often these days which really annoys me is "Curated". A radio playlist, curated by X... most moving film sequences, curated by Y...
What's wrong with "chosen", FFS?
From a grump old fart who works in the museum sector (where actual Curators actually Curate).
I get the : “...just go to the client’s site and report back on the art of the possible”
Energy projects by the way, we’re not producing watercolours of unicorns.
#prick
“Road Map” – to describe a set of pre-planned, cast in stone, organisational changes.
Sounds like an efficient use of language.
if its cast in stone... how are you supposed to fold it?
Metadata Universe (A single software platform with lots of data in it) and;
Metadata Multiverse (two or more of the above that connect with each other)
🤣
Thanks, I'm totally gonna use this at work (analyst in a scrum team that's not really agile but we like to pretend it is when it suits us)
Wow, just wow.
Most of this unnecessary word origami comes from the US initially I take it?
Keep up grandad.
Sorry, I still use "received".
“Curated”
Or indeed "specially curated". To quote another mad phrase "get in the sea".
Agile is bollocks speak from PM’s that simply means taking on too much work and under delivering on everything.
If you say so grandad.
I get the : “…just go to the client’s site and report back on the art of the possible”
English not as a first language, perhaps? Sounds like it's out of the same stable as "please do the needful."
Metadata Universe (A single software platform with lots of data in it) and;
Metadata Multiverse (two or more of the above that connect with each other)
That quote ^^ makes a lot of sense..
The big company I work for has gone from waterfall to agile delivery of everything and I mean multiyear longterm investments. Quite how the hell that works is beyond me. I kid you not they are actively searching for unicorns, wtaf.
The big problem with waterfall, which anyone using it for long projects seems to have forgotton/ignored, is that it is pretty imposible to completely specify everything you will want in a piece of software, almost certainly impossible to specify the best way to provide that functionality, and by the time the software is delivered there may no longer be a requirement for that functionality.
Hence with agile/xp/similar you basically come up with a prioritised list (the 'backlog') of functionality you want and then iteratively build the piece of software, with regular releases so people can examine what has been built and confirm that it is what is wanted or whether there are actually better ways to do it, whether some impending bits of functonality from that list are not now required or should be modified, whether there are new bits of functionality that have been recognised and are required, and whether the reprioritise items currently on the list.
It is the business that performs this review and can regularly reprioritise the list of what is to be delivered in the next iteration, and the development process is 'agile' in that it can react to this and redirect itself.
It is up to the business to not get carried away changing requirements and therefore keep to budget, but the premise is that at the end what is delivered is what is actually required, even if that has morphed from the original vision of what was going to be delivered, so even if you have gone over budget it will be a lot better than having just delivered a load of dysfunctional software that doesn't meet the requirements and nobody wants.
In terms of the software development process then applying the agile delivery processes to even something that externally has to follow a waterfall delivery for contractural reasons is still beneficial because the regular, short, delivery increments force things like a constant development velocity, constant testing of deliverables, etc.
To do this successfully though involves a lot of expertise in setting up automated testing (ideally there is no manual testing) and expertise in writing the correct tests at the correct level.
This is not easy - we've just had a greenfield development which has still ended up with problems in this area.
And it's compounded by young developers reading blogs of the internet and thinking they know best and ignoring any prior 'art' - even though lots of the principles behind what they think is state of the art can be tracked back to the late 60s...
The ideas behind it are simple but there are, as said, a lot of people trying to turn it into formal processes that they can sell books and consultancy on. e.g. scrum masters...
Read 'Extreme Programming Explained' to see how simple and successful it could be.
Read 'Organizational Patterns of Agile Software Development' to see where it came from.
If you say so grandad
I’m 30. Grrrrrrrrrrr
The big problem with waterfall, which anyone using it for long projects seems to have forgotton/ignored, is that it is pretty imposible to
Not get soaked through and damage your hearing?
I too am a scrum master, although this time they are calling me an agile delivery manager.
Preferred working @ the 7-11 in Whistler in 2003 tbh...
The big problem with waterfall, which anyone using it for long projects seems to have forgotton/ignored, is that it is pretty imposible to completely specify everything you will want in a piece of software, almost certainly impossible to specify the best way to provide that functionality, and by the time the software is delivered there may no longer be a requirement for that functionality.
Hence with agile/xp/similar you basically come up with a prioritised list (the ‘backlog’) of functionality you want and then iteratively build the piece of software, with regular releases so people can examine what has been built and confirm that it is what is wanted or whether there are actually better ways to do it, whether some impending bits of functonality from that list are not now required or should be modified, whether there are new bits of functionality that have been recognised and are required, and whether the reprioritise items currently on the list.
It is the business that performs this review and can regularly reprioritise the list of what is to be delivered in the next iteration, and the development process is ‘agile’ in that it can react to this and redirect itself.
It is up to the business to not get carried away changing requirements and therefore keep to budget, but the premise is that at the end what is delivered is what is actually required, even if that has morphed from the original vision of what was going to be delivered, so even if you have gone over budget it will be a lot better than having just delivered a load of dysfunctional software that doesn’t meet the requirements and nobody wants.
In terms of the software development process then applying the agile delivery processes to even something that externally has to follow a waterfall delivery for contractural reasons is still beneficial because the regular, short, delivery increments force things like a constant development velocity, constant testing of deliverables, etc.
To do this successfully though involves a lot of expertise in setting up automated testing (ideally there is no manual testing) and expertise in writing the correct tests at the correct level.
This is not easy – we’ve just had a greenfield development which has still ended up with problems in this area.
And it’s compounded by young developers reading blogs of the internet and thinking they know best and ignoring any prior ‘art’ – even though lots of the principles behind what they think is state of the art can be tracked back to the late 60s…
The ideas behind it are simple but there are, as said, a lot of people trying to turn it into formal processes that they can sell books and consultancy on. e.g. scrum masters…
All very good if you're developing software. Not so good at all when you're building the infrastructure for a new factory on a multi-year project moving through design, construction into the deployment of office/meeting room equipment and machine tool integrations.
All very good if you’re developing software. Not so good at all when you’re building the infrastructure for a new factory on a multi-year project moving through design, construction into the deployment of office/meeting room equipment and machine tool integrations.
I've used it successfully on large infrastructure projects. Because requirements on those change too.
Not so good at all when you’re building the infrastructure for a new factory
Thats the fun though of the trendy methodologies. Find a nice square peg which fits nicely into that custom hole used in one sector and then use the biggest sledgehammer you can find to smash it into the round hole of every other sector. Take six sigma and various other previous flavours of the month I cant remember right now.
I am sure agile works right in certain situations but so far in my experience its mostly used as an excuse for not having the faintest idea of what the business actually wants and to just stumble along week to week in the hope might get somewhere.
I'm still not wholy convinced by the Agile stuff even though it had worked in my last place of work, went on a conference and everything (when it was XP). Required a huge huge amounts of trust from players and managers as well - pair programming was very difficult to get head around.
At least I have tried to take some of the key bits in my current job but one part in Agile TDD and the rest in standalone waterfall method is tough sell. It does help having the unit test philosophy though.
Other stuff that was very valid was always present client, short sprints, always buildable code - I reckon a lot of that is very valid.
I’ve used it successfully on large infrastructure projects. Because requirements on those change too.
+1 £90 million water treatment plant design and construction
Look at Project 13
Agile is great but it seems to have little to do with "scrum" which is awful and what most people mean when they say agile.
Answers on a postcard please, or if you prefer, reply 😉 - all used in a meeting at work today:
"...this gives us our North Star..."
"...in the space of..."
"..colleague immersion sessions..."
I am sure agile works right in certain situations but so far in my experience its mostly used as an excuse for not having the faintest idea of what the business actually wants and to just stumble along week to week in the hope might get somewhere.
Sounds perfect for the mining industry!
"Business as usual, maintain good behaviors"
=
"We're going to tell you to do the most effective thing whilst actively incentivising things that harm the company as a whole."
just go to the client’s site and report back on the art of the possible”
Funnily enough I've just been watching a 1985 World In Action documentary about a charity car race across the outback in which the narrator refers to the 'art of the possible' in relation to outback ingenuity so its not that current or vogue-y
from 28.39
I'm just imagining trapping up to some manky building site portacabin for a site progress meeting and the reaction I would get if I said some of this stuff.
The company i work for has Sector Directors, not a clue what they do but sound like they should be in some SciFi or war film .
Anybody not convinced by the ideas behind agile should go back to the 90s and try using something like SSADM and see where that gets you.
If you read the books by the guys that came up with the ideas, like the XP book, Jim Copliens book, etc, it is evident that these are people that were actually 'at the software coal-face' and determined what methods were actually working and delivering.
The famous line is that a good software developer is a lazy developer, they don't like doing wasted/redundent work. The methodologies involved in agile/XP are formed from this view.
For instance the two week delivery schedule.
Classically a project starts and everyone is working normally on it, in the usual over-optimistic manner of software developers.
Then the deadline approaches and everyone starts to panic as they realise they have underestimated and start to work long hours and take short cuts, and probably write more defects.
Then that deadline passes and everyone relaxes and tries to recover, but then the next deadline approaches and then the panic starts again...
And repeat, over and over again.
The two week delivery window is designed to keep everyone at a constant level of 'panic', and because the window is only 2 weeks the consequences of the under-estimation are more easily recovered from.
User story points are used to estimate the amount of effort a development ticket will take, rather than time, because developers are shit at estimating, but they can probably remember the last few tickets they developed and can compare the complexity of this ticket to that one.
After a few sprints they know roughly how many points the team can get through in a 2 week cycle - known as the velocity - and so the future workload based on the backlog can be estimated.
A velocity burndown chart can be used to monitor the teams progress through the 2 week cycle and used for both motivation and tracking.
Story points use the finonacci sequence to encapsulate the fact that the more complex an item of work is the more likely it is that the estimate is unreliable - and so encourage the breaking down of larger pieces of work into more manageable bits that can fit in the 2 week cycle.
Test driven ensures that you write the system to accomodate automated testing from the start, as developers are lazy and don't like manual testing - but they like writing code and they can therefore write clever testing code instead.
Constant deliveries also means that the users will get what they want - which unbelievably is what the developers actually would like to deliver, rather than just being jobsworths who have delivered what was on the spec.
So it is based on pragmatic methods - I can't really see the sense in anyone with any experience wanting to go back to waterfall - but there seems to be more 'clickbait' articles on the internet proclaiming this is the way to go.
The key thing with an agile project is that you MUST commit to an automated testing framework from the start, not take shortcuts to deliver stuff that isn't covered by this framework, and have QA closely collaborate with the developers rather than follow behind writing the tests.
If the client is external and won't look at the deliverable regularly then you have to take QA or your business analysts to take on that role internally.
I wonder if Poopscoop envisioned this becoming the most boring thread to ever grace the pages of STW or is it just a fluke that this is how it has turned out?
Find a nice square peg which fits nicely into that custom hole used in one sector and then use the biggest sledgehammer you can find to smash it into the round hole of every other sector.
Yep. This is the problem, not an agile approach to elaborating, prototyping and changing requirements.
People who have never run a project in their lives listening to consultants who have "done Agile" elsewhere and deciding that it's the panacea for everything so we'll base the entire organisation around it. How do I deliver customer value in a 2 week sprint when the end product needs six separate workstream deliverables, taking six weeks each to contract, resource and deploy, from six different suppliers to join together?
It’s quite interesting to see IT people dismiss every other industry that does stuff.
Tail wagging the dog. And most of the time not wagging it it either.
What you sayin' bruv?
funkmasterp
Subscriber
I wonder if Poopscoop envisioned this becoming the most boring thread to ever grace the pages of STW or is it just a fluke that this is how it has turned out?
Well, it had turned out different to how I thought it might but that's ok, this is stw after all.
I've read all the thread but only understand about 30% of it though.😁
I feel embarrassed at 5 posts in completely derailing a thread that otherwise might have been amusing (altho it has been done 100 times before on STW). At least TurnerGuy ^ gets his moment of glory, I read the first couple of sentences.
Deliverables
Flexagility
Functionality
Leveraging synergeies
Capitalising internal markets
All of this and more within what was an old school, traditional law firm FFS
Flexagility
I'm so using that 🙂
Have you lot not been ‘bringing your best selves’ to work recently?