|
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.
|
|
|
|
|
I think this rant is more against scrum than against agile in and of itself. I also think that mindlessly implementing Scrum is a very bad idea.
The scrum ceremonies (stand up, planning, review, and retrospective) all take too much time in 2-week sprints. Personally, I think that for any kind of mature product, 2 weeks to develop a shippable feature is too short, unless you can do it all in parallel, which is unlikely.
Agile should be about taking the ideas that work for you, your team, and your project. And it requires that management and client understand what you're doing.
As for pair programming: that is not a necessary part of agile. I never worked in a full pair-programming environment (I don't believe it would work), but pair programming sessions do yield good results, IME. It doesn't double the cost, because it's much more likely to be correct and it helps in sharing knowledge around in a team.
That said, if your employer starts talking about implementing SAFe: run and don't look back.
|
|
|
|
|
The Agile Manifesto is tiny, the implementation is the problem.
Scum is an implementation of agile.
How people implement it, and then actually execute on it is the pain point.
Pair programming (or over seeing a junior) via screen share is far better for ME (emphasis on opinion) then sitting next to someone and the screen further away then sitting on own computer and seeing their screen.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
|
|
|
|
|
And you need Agile to perform those 4 items?
They all seem like common sense to ME (emphasis on opinion too).
|
|
|
|
|
I agree that the implementation is the issue, and I think that the OP suggests that it's the Agile perfectionists who ironically don't embrace the spirit of the thing and force the processes and tools of agile implementations to prominence over the individuals and interactions.
I've never worked in an Agile office, but I do love the manifesto, if not the reports of implementation. In our office, we meet twice a week for basic concerns and discussion of things upcoming, and we share online workspace in a way that allows us to be an extra pair of eyes on any issue (not paired programming, but old-fashioned lending a hand). I would like to have more input into future projects, especially the refactoring and updating of the site, as the agile way seems to inspire.
|
|
|
|
|
Nearly half of what I read in your post has nothing to do with Agile.
I'm not an Agile evangelist either - I think a waterfall/agile blend works best.
At least for our group.
|
|
|
|
|
Interesting. https://codeproject.global.ssl.fastly.net/script/Forums/Images/smiley_confused.gif
Can you be specific about the half?
|
|
|
|
|
We use Scrum.
1: Pair Programming
2: Cubified Environment
3: Poorly Run Meetings
In all the Scrum training I've received no mention of paired programming at all.
As for the open workspace, that is just ridiculous. More frequent communication != distracting work environment.
Also, our morning meetings are timeboxed to 15 minutes - so poorly run meetings aren't Agile either.
If you're in a poorly run Agile environment then yes, it will be chaos and a waste of time; however that can be said for any poorly run methodology.
Sounds like you have really bad management.
|
|
|
|
|
And it was the primary reason I quit after 9 years.
Now, 2 developers, no Agile, private office. It's called developer heaven. https://codeproject.freetls.fastly.net/script/Forums/Images/smiley_smile.gif
|
|
|
|
|
I left that environment for an Agile team.
The problem I was having in the situation you now find yourself in is that management was totally uninvested in what we were doing. Turns out bad management can ruin heaven.
That doesn't mean you're in a bad place - I just suspect you went from bad management to good management thereby bolstering other claims made here: Methodology is secondary to management.
|
|
|
|
|
Actually, I went from a large monolith company to a smaller company that respects our work environment and abilities, and leaves us to do our job we were hired to do, not attend kindergarten every day.
|
|
|
|
|
Someone correct me if I am wrong, wait - I'm in the lounge, that happens naturally here....
My perception, and it's been a few years that the roots of agile come from extreme programming (there is a great book somewhere here, maybe my attic) which with the exception of pair programming, opened my eyes to some serious issues in our industry. At the time, I was a manager of a DB development team. After I read this book, my conclusion was we're doing this wrong.
This is where Agile just made things way too complex for me. KISS is better for project management - hence I understand the OP's rant. Nuggets and epiphanies I pulled from this book:
|
|
|
|
|
Good details and excellent background on what the real problem is.
https://codeproject.global.ssl.fastly.net/script/Forums/Images/smiley_biggrin.gif
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
