|
Contradictory opinion.
Obviously, we are suffering from too many meetings, but we're doing good progress with Agile.
We have regular releases, we work hard to define issues/stories.
We have good people in all of our teams, from programmers to product owners to management.
I rarely do pair programming, but we do it.
it's not perfect, we're improving the process by adapting it to our need.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
I fully expected Agile followers to sell some successes, and you certainly are entitled to your contradictory opinion - for sure.
I guess my retort, and I mean this more as a humorous remark - to me the word progress and Agile is an oxymoron. https://codeproject.global.ssl.fastly.net/script/Forums/Images/smiley_biggrin.gif
|
|
|
|
|
Agile smagile. I'm enjoying myself much more now that I'm a team of one and can just code.
Real programmers use butterflies
|
|
|
|
|
|
Yep. Doesn't have much fail-over, but that is never my problem when I am the one on the team. 
|
|
|
|
|
you are weird. you will never approach a customer. Thou must be cloked.
Just kidding. 
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
You're not entirely wrong. I am weird. But I eat customers which involves approaching them, especially when they're unsuspecting.
Real programmers use butterflies
|
|
|
|
|
lol. You'll just confuse them. Back to the lab with you.
I've worked with a couple of people with really high intelligence and passion (over the years). Nothing wrong with the rest of us or you, but some of you are just in your own little orbit. I made sure to send food to engineering from time to time. *Always* got my bug fixed.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Well, to be fair I'm nursing a Cluster-A condition and so I am quite mad. That sort of comes with its own orbit.
Real programmers use butterflies
|
|
|
|
|
It's the equivalent of letting amateurs wire your house for electricity (IT management that has reached its level of incompetence). In the case of software, it's legal.
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
|
|
|
|
|
IOW, Agile is like teenage sex:
- Everyone says they are doing it
- Very few are actually doing it
- Those who are doing it are doing it wrong
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
So in short: Managers forced you to work in direct contradiction of the agile manifesto and from this you can conclude that agile does not work?
|
|
|
|
|
I never said it didn't work.
I was pointing out the negative aspects, which seem to be ignored by those enthralled by it.
- Significant increased development costs.
- Business rebuffs due to strict IT rules.
- Loss of independent accountability - matrix development.
|
|
|
|
|
Probably because people who come from the world of Gantt charts detailing a 12 month waterfall project have seen development cost go down while accountability and flexibility increases.
If you start with a lean small team already following the agile manifesto (probably not even knowing they do so) and then add process for the sake of the process, is it surprising cost goes up and flexibility and ownership are lost?
Isn't this confirming the agile manifesto is on to something? When prioritizing processes over people and interactions, then you are doing the wrong thing?
|
|
|
|
|
There are some good things about agile - iterativeness, going step by step, the fact that the developers themselves decide on how long implementation of a feature would take, the fact that the QA of a feature is done right away when a feature is implemented, so that the current KNOWN state of the project is close to its real state. Peer programming on a regular basis is nonsense - never saw it being practiced successfully.
A leader should take only good parts of Agile, employ his own good sense and not to follow it by the book so to say.
Nick Polyak
modified 22-Nov-21 12:06pm.
|
|
|
|
|
All those items in your list are good, and can be done by 1 person without the kindergarten aspect. Been doing it myself for decades - developing since the late 70's and still at it.
|
|
|
|
|
Yes they can be done, but often they are not. Agile kind of forces people to do them.
Nick Polyak
|
|
|
|
|
And as an adult, you need to be "forced" to do them?
Not trying to be snarky here, but that is why I use the kindergarten description for Agile.
|
|
|
|
|
"Agile" doesn't force anything.
|
|
|
|
|
warning, member *** is an old fart and has not adjusted his/her BS filter No disrespect intended.
I'm pondering the gripes.
What *I've* seen is a somewhat whorish worship of the process rather than the product. But I admit most of my exposure has been to management that is "goaled" to achieve agile with no support, no resources, no understanding of the process, etc.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Quote: the fact that the developers themselves decide on how long implementation of a feature would take
Nick is that really true? Agile says that, then reality sets in. I've never seen a schedule respected.
Practical experience?
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
It was true in most places where I worked.
Nick Polyak
|
|
|
|
|
Quote: ...developers themselves decide on how long implementation of a feature would take,
In my experience, the non-technical PMs and BAs ignore what the engineers say about how long a task should take, and simply pick whatever suits their promises to management. The scrum approach is fine for deterministic manufacturing processes, but wholly unsuited to almost all software development. Kanban is a better approach, as software development time estimating is a venture best accomplished with a crystal ball. There are usually too many unknowable variables when it comes to estimating time.
|
|
|
|
|
I think you read too much blah blah or is in a poor working environment....
From the last 5 company I work on agile is kind of we decide what's next every 2 weeks... And also it's not other methodology. Like it's NOT waterfall. (I dunno what other "methodology" there are.. and Project Manager love these, so they need a name to describe what they do)
|
|
|
|
|
Not sure what you are saying about 'reading' blah, etc. I described what I was experiencing - a poor work environment created by the Agile leader and management conducting kindergarten classes for adults who they believe are not responsible and need to be herded around like cattle.
We had every 2 week intervals as well; and after removing daily standup times and business meetings, we all realized we were only developing about 2-3 days a week; which is ridiculous and expensive.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
