C
cantagril
I haven't used this in anger but I recall that when I first came across it (sometime in the late noughties, I think) it seemed uncannily like a rehash of Kanban/Lean/OPT etc etc.
I was involved in manufacturing for a while in the early '80s and had occasion to visit a Honda factory in Japan a number of times and whilst somewhat surprisingly, a lot of their production equipment was quite ancient, they were shit-hot on management techniques and happy to share info.
I later did quite a lot of research and applied some of the ideas in a factory in the UK but the only thing I can clearly remember was that Kanban (which just means "signboard" or something similar) was itself derived from a much earlier approach used in retail stocking systems and then developed by Toyota.
Imo, it's definitely a useful approach but not sure that one needs to shell out that much to learn it, as by now it must all be out there and pretty much open source.
.....of course, my experience had almost nothing to do with IT except for SPC type stuff which was also just getting started in a big way.
Rufus_Leakey
Established member
- Messages
- 685
- Likes
- 524
When I worked for a large bank doing software development, many projects switched to agile development. Management's philosophy was to consider every non-management employee or contractor a developer. So instead of specializing in writing requirements, writing software, testing software, etc., the goal was to have all non-managers be able to do anything. Also, any "feature team" was supposed to be interchangeable with any other feature team worldwide. Most of the people didn't like being turned into commodities, but they had no choice.
The main artifact to accomplish this was having many meetings of several feature teams with a scrum master and product owner to discuss dividing large features into small parts that could be estimated in terms of complexity. We did this by playing "planning poker" where after discussing the work, the feature team members revealed a hidden Fibonacci number representing the complexity. Then, the teams would come to a consensus on a single Fibonacci number.
The product owner would prioritize the parts, and the feature teams would choose parts until each feature team had parts with complexity totaling 13 times the number of members on the feature teams. Complexity 13 meant the work was estimated to take the entire time of the next two-week sprint (minus all the times for meetings).
The result of the parts would be demonstrated to the product owner at another meeting at the end of every sprint. If the product owner approved of the demonstration, the feature team would be credited with the complexity points. So we were encouraged to develop things fast and sloppy, but make the results look good for the product owner.
The end result was lower quality but continual improvement based on agile measurements like complexity points finished per sprint. This was like a trading account that never closes losing trades, where the balance goes up while the equity goes down.
The main artifact to accomplish this was having many meetings of several feature teams with a scrum master and product owner to discuss dividing large features into small parts that could be estimated in terms of complexity. We did this by playing "planning poker" where after discussing the work, the feature team members revealed a hidden Fibonacci number representing the complexity. Then, the teams would come to a consensus on a single Fibonacci number.
The product owner would prioritize the parts, and the feature teams would choose parts until each feature team had parts with complexity totaling 13 times the number of members on the feature teams. Complexity 13 meant the work was estimated to take the entire time of the next two-week sprint (minus all the times for meetings).
The result of the parts would be demonstrated to the product owner at another meeting at the end of every sprint. If the product owner approved of the demonstration, the feature team would be credited with the complexity points. So we were encouraged to develop things fast and sloppy, but make the results look good for the product owner.
The end result was lower quality but continual improvement based on agile measurements like complexity points finished per sprint. This was like a trading account that never closes losing trades, where the balance goes up while the equity goes down.
Atilla
Legendary member
- Messages
- 20,856
- Likes
- 4,033
It's not a fad and really REALLY good for developing and producing work.
If you are new to it compare it against Waterfall approach and then you'll understand the opposing weakness and strengths of the two systems.
Prince2 and Agile approach to project management is really good imo.
Some time back a good PM who I used to respect told me his approach was to brake down anything that took longer than 2 days into a smaller piece of work to make it more manageable. Same theory can be pretty much applied to other tasks; be it 2 days, 2 weeks or 2 months.
C
cantagril
I can't fault that as a learning approach (and a possible pathway toward more and bigger billing) but I do have a miniscule caveat in that all of these management tools are exactly that, i.e different kinds of hammer, if you will.
WalletInvestor
Active member
- Messages
- 143
- Likes
- 39
Seems like a good idea! I agree with those saying it is not a fad. In my experience there is a growing interest and demand for these skills. Agile management is exceptionally great for motivating employees, especially at firms where the work might be monotonous.
trendie
Legendary member
- Messages
- 6,875
- Likes
- 1,433
Just reaching last modules of the Scrum e-course.
(no more than 3 hours of stuff in this particular version.
have taken a couple of free on-line sample exams to test myself. all good.
feel really comfortable if I decided to take the exam.)
Seems like Scrum started off as a good idea, then someone tried to formalise it, then decided to pad it out to make it seem more prestigious than it is.
I like it in principle.
But, as the modules got more boring, I started to misread scrum as scrotum.
Couldn't help but think of that book, Bullshit Jobs, by David Graeber.
(no more than 3 hours of stuff in this particular version.
have taken a couple of free on-line sample exams to test myself. all good.
feel really comfortable if I decided to take the exam.)
Seems like Scrum started off as a good idea, then someone tried to formalise it, then decided to pad it out to make it seem more prestigious than it is.
I like it in principle.
But, as the modules got more boring, I started to misread scrum as scrotum.
Couldn't help but think of that book, Bullshit Jobs, by David Graeber.
Rufus_Leakey
Established member
- Messages
- 685
- Likes
- 524
C
cantagril
So, mainly bollocks then?
trendie
Legendary member
- Messages
- 6,875
- Likes
- 1,433
My initial impression is it so.So, mainly bollocks then?
Have joined a couple of local Meetups in Scrum and Agile, just to get a sense of it.
Problem is, they would, by definition, likely to be evangelical to the principles, rather than its practicality. I would tend to be looking to see its utility as a tool to enhance productivity, and ditch anything that was blocking work getting get done.
Anyway, Agile next....
trendie
Legendary member
- Messages
- 6,875
- Likes
- 1,433
Forgot about this thread!
Am doing AWS Cloud Practitioner now (easy, 6-8 hours), then might add Cloud Architect.
Toying about learning Azure Fundamentals as well.
'Cos it's what the cool kids are doing, innit, bro!
(keeping the brain active - all good)
Anyone else upgrading skills, for the hell of it?
Am doing AWS Cloud Practitioner now (easy, 6-8 hours), then might add Cloud Architect.
Toying about learning Azure Fundamentals as well.
'Cos it's what the cool kids are doing, innit, bro!
(keeping the brain active - all good)
Anyone else upgrading skills, for the hell of it?
P
postman
Just found the thread and no one is mentioning the most salient point about agile, when to use it.
You use waterfall (*PRINCE2) type methodology when you know what you want to deliver ie you actually have a business case with a requirement and a measurable payoff to track against.
You use agile when you want something quick and dirty and you deliver whatever is ready in the timescale.
Each has its application, but you dont want to be building a bridge that cars drive across using agile and you dont want to create a new forum on T2W's website using waterfall.
Agile is dumbed down project management for millennials who's attention span doesnt allow them to work on anything over 2 days.
(*yes I know they say PRINCE2 can be used for agile but no it cant it really cant)
You use waterfall (*PRINCE2) type methodology when you know what you want to deliver ie you actually have a business case with a requirement and a measurable payoff to track against.
You use agile when you want something quick and dirty and you deliver whatever is ready in the timescale.
Each has its application, but you dont want to be building a bridge that cars drive across using agile and you dont want to create a new forum on T2W's website using waterfall.
Agile is dumbed down project management for millennials who's attention span doesnt allow them to work on anything over 2 days.
(*yes I know they say PRINCE2 can be used for agile but no it cant it really cant)
Atilla
Legendary member
- Messages
- 20,856
- Likes
- 4,033
Agree with much of what you say but fwiw imo Agile fits well within Prince2 - Product Delivery when working on Work Packages and taking Delivery. It enhances the process and establishes a good approach and guideline for delivery. Also, if the lingo and processes are standardised, then as you say when everyone talks the same and knows what the expectations and deadlines are, it helps remove many of the project issues.
I do agree however, courses try and big-up Agile to more than what it is but to get noticed I guess one has to shout louder.
It is a good tool and set of values and principles that were missing from the obese Waterfall method.
Last edited:
trendie
Legendary member
- Messages
- 6,875
- Likes
- 1,433
(am only a paper practitioner on Agile)
Your first point, about context of use, is salient.
Agile came from the software world, so I can relate to the constant prototyping, and staged deliverables.
Users sometimes change their minds about what they want, or their needs evolve, so Agile makes sense, as it can evolve with them, until the funding runs out!
Forces people to make choices about whats truly important, and what can be discarded.
Any good 1-2 day courses you may have tried recently?
Might try Ericksonian Hynpotherapy next!
P
postman
Err users Constantly change their mind about what they want and having done agile development the limit to my patience is the "Great, can we try it in Blue" requirement.
Waterfall makes people think about what they want before the project starts and agile is 'I want to change something lets start today and keep on going until the money runs out'.
It analogous to you building an extension to the house, planning it, costing it, arranging builders contracts etc... (waterfall) and your wife constantly buying new curtains and cushions (and taking them back to swap them 5 times because she didnt like them the next day) in order to change the look of the interior based on how she's feeling on that day (agile).
Courses ... the internet is full of amazing places to learn new skills and techniques, and there's plenty of 'natural teachers' who love what they do and want to share it with everyone for free. Maybe someone should write an *app where people answer a set of basic questions (Do you like music / running / art) and then prompts them by saying based on our algorithm you might like to learn parkour.
*Patent pending, but probably already exists.
Last edited by a moderator:
Atilla
Legendary member
- Messages
- 20,856
- Likes
- 4,033
Agile does have some real significant value in looking at a visual backlog of deliverables which can be prioritised and costed allowing customer to pick and choose.
You are being harsh but not very fair.
trendie
Legendary member
- Messages
- 6,875
- Likes
- 1,433
I am / used to work as a freelance developer, working on projects that the client wanted me to work on, and constantly get extended.
The funniest thing my brother-in-law once said when I explained my recent client ended my contract after 18 months was "Couldn't you spin it out any longer?"
I love clients that can't make up their minds.
Sadly, I am looking at the other side of the coin with project management.
P
postman
True.Agile does have some real significant value in looking at a visual backlog of deliverables which can be prioritised and costed allowing customer to pick and choose.
You are being harsh but not very fair.
P
postman
6 weeks to 2.5 years was my best. 😂
Similar threads
