|
W∴ Balboos, GHB wrote: Now I am contract manager for Agile projects
I don't believe: do you really dislike Agile? I am trying to convince you to like it.
In software development, agile practices approach discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change.
Which one of these beautiful Agile goodies looks like complete crap?
|
|
|
|
|
Agile - where the tail wags the dog.
And as a bit of insight, you know which end of the dog has the tail and what it's for.
| 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 |
|
|
|
|
|
W∴ Balboos, GHB wrote: Agile - where the tail wags the dog.
I expected something like this... Looks like my advocating ability needs to be improved. Maybe I will try some time later. Meanwhile, I need to complete my sprint (scrum? sprint scrum? whatever).
|
|
|
|
|
The last environment I worked in where Agile was "practiced" had reduced it to worship. The only thing Agile represented was a dictatorship with a religion. The code coming out was worked and reworked until it matched the tech lead's code, whether it worked or not. Deadlines were blown and customers left waiting, but it was Agile.
|
|
|
|
|
The aims of aguile are laudable, though I'm not convinced that it produces good code in the long term - there is too much emphasis on short term goals and not enough on joined up thinking.
But as far as implementation goes, it's usually terrible: an excuse to get costs down by throwing code out the door without much if any quality control. Think about it: do car designers use Agile methods (outside the software component)? Do aircraft manufacturers (other than Boeing obviously)? Why not? Simple: their products have to pass actual independent testing to ensure they don't kill the customer ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: Do car designers use Agile methods? Do aircraft manufacturers?
I wanted to answer here "Boeing, obviously", but fortunately, decided to read the whole reply.
|
|
|
|
|
Let me tell you the story of the agile bicycle. After the first sprint, minimal viable product was a frame, wheels and a set of handlebars. It could only go downhill. Fast - without brakes.
It was pretty dangerous until sprint five, where we put on a bicycle seat.
Lesson: Some things just don't lend themselves well to agile.
|
|
|
|
|
11917640 Member wrote: Which one of these beautiful Agile goodies looks like complete crap?
All of them?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
Agile like all these 'processes' is great if people do it properly and stick to it throughout the project. But in my experience, after a few meetings everyone loses focus, or other pressures are put on people. The result is that they do "agile lite", which is as good as not doing it at all. I have never seen (in 40+ years) a project following any of these processes that actually delivered what it promised.
|
|
|
|
|
Agile like all these 'processes' is great if people do it properly and stick to it throughout the project.
sounds like class oriented programming.
I have never seen (in 40+ years) a project following any of these processes that actually delivered what it promised.
my experience is different. i have never seen (in 30+ years) any of these processes that actually delivered what it promised.
|
|
|
|
|
Never having used Agile--my salaried days predate it--I will make some observations.
Let's start with this. A process will not produce good software without skilled developers. But skilled developers will produce good software without a process, though a process can help them work more effectively.
In software development, agile practices approach discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).
Discovering requirements, yes. Developing solutions iteratively, yes. But those who don't write code have nothing to do with development except providing user feedback. And cross-functional activity must be managed, lest it significantly increase the number of lines of communication and totally busy people out responding to every twit who invokes their name.
It advocates adaptive planning, evolutionary development,
no different than any software process, because the nature of software is evolution
early delivery,
as long as everyone understands what alpha and beta releases are
and continual improvement, and it encourages flexible responses to change.
again, no different than any software process
|
|
|
|
|
Greg Utas wrote: as long as everyone understands what alpha and beta releases are
Microsoft do, though they use different names. "RTM" is "Alpha", "SP1" is "Beta", ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
They talk the talk, but don't know how to walk. Scraps for beggars (users); one scrap at a time.
An elephant is like a snake, except it isn't. But Agile says to focus on the snake; then the tree stump; etc. until you have not the elephant the user wanted.
Agile is like web development. One grotesque mismatched part after another.
One "trains" to be agile; you don't know Agile until you've done it; but it doesn't work "as described" out of the box. (i.e. no experience, you'll never get agile / Agile).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Gerry Schmitz wrote: One "trains" to be agile
Dogs are trained, people should be taught / educated.
|
|
|
|
|
11917640 Member wrote: Which one of these beautiful Agile goodies looks like complete crap?
The ones where managers say "we don't need a planning because we're doing agile!" and "we're going to adopt an agile approach, but we really need it done by [insert specific date]."
Another classic, switching priorities every other day because "we're agile".
Also a favorite, "we're doing agile so you're self-managing teams [I'll be out on the golf court]." 
|
|
|
|
|
"discovering requirements and developing solutions through the collaborative effort"; well yes, unless you're a lone worker (I am) then you're in a team, and this is what "team" means. Even if you're a lone worker, then you and the customer are a team - always have been, always will be. (Increasingly I'm my own customer!  )
"adaptive planning"; if project management doesn't adapt, it's not "planning", it was a plan. By definition, "planning" is ongoing and can therefore safely be understood to be adaptive.
"evolutionary development"; again, a tautology really. Unless you write a single line of code that completes the solution, it's an evolving solution.
"early delivery"; no sh*t, Sherlock. Which project management methodologies advocate late delivery?
"continual improvement". Well, I'm sure we have, as a species, always wanted to learn from our mistakes, and thereby continually improve. Right now, we're improving on "agile".
"flexible responses to change". Does "flexible" mean sometimes saying "no"? Hopefully...
I could apply the above description of Agile to any of the development paradigms I've had to work under in the past 40 years. They could all be summarised as "listen to the customer, help each other, and learn as you go".
|
|
|
|
|
Continual improvement in agile? That may be questionable. I have found, over time, that the codebase gets worse over time. That is due to the business pressure to get the software out. Then, later, when we need to add more features, we don't have time to adapt the similar part of the old code base to what the new feature demands (even when the calculations are the same) and the new feature is in another subproject. Either, it is easier and quicker to duplicate code, or use a cross dependency to the original code (with some minor changes to accommodate the new feature), then hopefully, later we will have time to fix up the bad code decision(s). Hence, technical debt. Then when we do want to fixup the code debt, it becomes difficult to convince the product owners and QA that retesting will be necessary and time will be needed to make sure that we didn't break something along the way.
I agree that it would be better to have allotted the time when adding in the new feature for correctly setting up the needed dependencies in the lower level projects, but management doesn't want to spend a lot of time testing (even regression testing) even for a new added feature. So, having the time to do a good engineering job is severely limited.
In other words, if we are not making revenue generating features (or fixing inhibiting defects), we are not encouraged to make the changes.
|
|
|
|
|
Bollocks. Collaboration is a waste of time. It usually devolves to extended meetings discussing the best color for a specific button.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I believe Agile is a pipe dream. In theory, it's the best, but in practice it falls far short. I attribute this disconnect, at it's origins, to a complete bastardization of the paper that started it all, The New New Product Development Game (Harvard Press, 1984), which doesn't mention scrum (a rugby term) but does mention rugby. They basically said that new innovations to existing products could be produced faster/better if 1) a small interdisciplinary team worked together, 2) management gave them goals and then got out of the way, and 3) the team was free to take risks. What we got was Agile/Scrum, which is basically a management control layer used for new and existing products where risks are avoided. Completely not the same thing.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Over the years, I've worked on numerous projects with various project management methodology. Each has its own strengths and weaknesses, and each has a situation where it should never be used. I won't restate the obvious.
Agile is an ideal project management method where you might have a stakeholder or manager that has severe ADD and is always chasing rabbits. The rabbits become the project. Feature creep that is deadly in other management methods can be embraced with Agile, usually with good results. If somebody is paying for the development, then why complain? You will tend to create a product that is more what the customer wants (admittedly guided by a subset of end users).
If you have a product that is continuously being tested by users, the feedback that you get might be quality input and provide direction for the order ("sequence") that you implement certain tasks and how to create or adjust certain UI features. If you get an informed set of test users, you might get ideas for implementing useful sub-features or workflows that might not have been conceived at the product design stage.
With Agile, you tend to have a releasable product sooner and with better end user acceptance.
With Agile, management and stakeholders have a more visible window into progress of the project/product. Showing continuous visible progress can have a good job security angle.
Agile can be useful when writing a software product used by many people. UI, Web page, tax software, spreadsheet, word processing, technical calculation app, scenario handling, ...
Agile should not be used if the objectives are very clear, or deviation is a failure. It should not be used for software projects launching a rocket, calculating orbital mechanics, security tokens, SSL/TLS, financial transactions.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
You mean that I am personally responsible for that many people failing courses, and not joining the workforce as developers?
Do I get a medal? 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: Do I get a medal?
Are 2.6M (and rising) rep points not enough for you?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: Are 2.6M (and rising) rep points not enough for you?
Of which, between 94.6% and 98.3% are using that boilerplate post.
Brilliant - P.T. Barnum would be proud - it's never a bad idea to go for the low hanging fruit, first. Unfortunately for my, due to time zones, I don't get in on this until most of these have been answered.
I'm not bitter. I though about it and am not even vengeful. Perhaps awestruck or starstruck?
| 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 |
|
|
|
|
|
No, but you have become part of the process of weeding out the duds.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
