The Agile Cult
-
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
-
Agile has been praised in the IT world almost as a religious cult; and a cult it is. Those managers who buy into this IT kindergarten principle have created an increase in IT costs that wouldn't make sense to those who see it for what is it - a huge time waster that can be replaced by being accountable for your work. Furthermore, paired programming has certainly been curtailed because of the push to work from home. Yes, virtual meetings can allow the process to take place, but now in a more cumbersome way. I say this because I watched a company I worked for go from getting praises and glory emails from the business partners to silence, crickets. Business meetings that turned into an hour long dead silence, or worse, many that did not even show up, or those attended became much more muted or even silenced; afraid to push back on the nonsense of it all. We went from cubes to cubified areas, to picnic tables where noisy phone conversations, casual chatter, and people shuffling around the room, reduced concentration to a trickle. With the meeting schedules, you are lucky if you get 2-3 days of work done a week. Multiply this times the number of days for the project to complete and you get into a real problem of proving that the expense is truly worth the time. I won't even get into the paired programming philosophy, where you have just doubled the cost of development on an on-going basis. Projects that took several months to complete now take a year or more. Anyone with any common sense simply cannot justify the added time and expense that is supposed to be offset by the claim to reduce scope creep and code errors. IT groups who push back and slam the door on businesses who attempt to add additional functionality many times end up losing in the end as being inflexible. Agile preachers will produce data and charts pointing to how you will really save time by suffering through all this. Large sessions are put on by Agile evangelists praising the Agile gods for giving us this process. This is especially true of projects where only 1 or 2 people work on it. While I would admit that the IT groups in a project that requires more than 3 people need to have meetings to make sure everyone is on point, it does not need a full blown carnival of meetings and daily stand-ups to accomplish this.
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:
- Customers set features. Customers won't know exactly what they want until you put something in front of them. Customers lie. They think they know what they want. Beware.
- The requirements / features will change. Stop your bitching. You best have a management model to deal with it. I've listened to developers complain for 40 years about changing requirements. It's normal. I think agile addresses this with gold plated story boards, etc. I don't know. Just recognizing the facts that customers do not know what they want and things will change is the first step in recovery.
- Customers do not do estimates. The people doing the work do. Again, over many years I have seen really smart people go green and puke having to come up with estimates. Software and systems development is hard. The people doing this work (not customers, PMs, management) are the ones that should be estimating. What I have seen again and again is a developer coming up with an estimate, it's too long, and some individual whacking it by half or more to meet some artificial schedule. The developers never learn how to properly estimate in this environment, so the entire system is set up to fail.
I actually consult with a well managed company. I truly mean that. Even so, they make these same mistakes. The only way customers are allowed to change the schedule is to change the priority of the features they want. They are actually starting to understand this. Even so, how many of us have been asked, "How long will this take?" with no requirements, no feature list, no h/w spec, etc?
This gets back to estimates. I've seen estimates get whacked to meet artificial delivery times (usually there is a trade show involved :)) and then listen to PMs and management complain bitterly that "the development team missed their scheduled commitments"
-
charlieg wrote:
Do PCs work with two keyboards?
Yes, and 2 mouses as well. I even used dual mouse for a game...
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
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?
-
Video or it didn't happen! :laugh: Seriously, details please.
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.
LOL no big deal, in Gabriel Knight 3 there is a part of the game where you have to collect fingerprints and it requires a lot of clicking. My game craqshed, I had to redo it again and had no patience, tried using both the plugged mouses (dual boot system and one mouse didn't work on Linux) and I manage to click hyperfast using both hands. I then used it a bunch of other times in some stupid minigames where a crapton of fast clicks were needed to have a slider go up, I forgot the games though. Also I had two keyboards on because my pro gaming wonderful keyboard... doesn't work in BIOS. So I have a basic second one always plugged in.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
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:
- Customers set features. Customers won't know exactly what they want until you put something in front of them. Customers lie. They think they know what they want. Beware.
- The requirements / features will change. Stop your bitching. You best have a management model to deal with it. I've listened to developers complain for 40 years about changing requirements. It's normal. I think agile addresses this with gold plated story boards, etc. I don't know. Just recognizing the facts that customers do not know what they want and things will change is the first step in recovery.
- Customers do not do estimates. The people doing the work do. Again, over many years I have seen really smart people go green and puke having to come up with estimates. Software and systems development is hard. The people doing this work (not customers, PMs, management) are the ones that should be estimating. What I have seen again and again is a developer coming up with an estimate, it's too long, and some individual whacking it by half or more to meet some artificial schedule. The developers never learn how to properly estimate in this environment, so the entire system is set up to fail.
I actually consult with a well managed company. I truly mean that. Even so, they make these same mistakes. The only way customers are allowed to change the schedule is to change the priority of the features they want. They are actually starting to understand this. Even so, how many of us have been asked, "How long will this take?" with no requirements, no feature list, no h/w spec, etc?
This gets back to estimates. I've seen estimates get whacked to meet artificial delivery times (usually there is a trade show involved :)) and then listen to PMs and management complain bitterly that "the development team missed their scheduled commitments"
Good details and excellent background on what the real problem is. https://codeproject.global.ssl.fastly.net/script/Forums/Images/smiley\_biggrin.gif
-
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
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.
-
LOL no big deal, in Gabriel Knight 3 there is a part of the game where you have to collect fingerprints and it requires a lot of clicking. My game craqshed, I had to redo it again and had no patience, tried using both the plugged mouses (dual boot system and one mouse didn't work on Linux) and I manage to click hyperfast using both hands. I then used it a bunch of other times in some stupid minigames where a crapton of fast clicks were needed to have a slider go up, I forgot the games though. Also I had two keyboards on because my pro gaming wonderful keyboard... doesn't work in BIOS. So I have a basic second one always plugged in.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
lol, now I REALLY want to see the video. :laugh: I can't play FPS games (current shading techniques make me nauseous) barely survive things like flight sims and prefer turn based strategy. I simply cannot play any console games. Years ago, we had a Wii. I could bowl, etc but trying to play ice hockey? All my defense men went into dance mode.
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.
-
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.
-
Agile is fantastic and the most successful way to go that I have seen in all my years. Small businesses were already doing Agile before Agile was even a thing. But pair programming is all kinds of wrong, I'll agree to that.
We use pair programming as a training tool, not an everyday occurrence. For example, I'm an expert in SQL, but my dev co-working is an expert in business logic for this domain. If they need SQL done in the BLL, we work together to get the job done. We look at each other's code and work on the same machine to get through the hard/tricky stuff. The easy stuff we go back to our own machines. It's very fluid, as needed, and agile. In short, we just work together to get the job done.
Bond Keep all things as simple as possible, but no simpler. -said someone, somewhere
-
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
-
Pair programming as intended is wasteful and almost never done. But sharing office space with one or more coworkers and exchanging small setbacks, roadblocks, pointers and basically rubberducking and soundboarding each other has worked very well for me in the past. Indeed I hope my next workplace will have such an atmosphere. As a programmer with ADHD I do poorly alone - I may write a metric crapton of code in a week and gaze at all wikipedias articles for a month because SQUIRREL!
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
Hmm, I'm wondering if I might have ADD. (no H though, I've never managed a crapton of code ever)
Wrong is evil and must be defeated. - Jeff Ello
-
Agile has been praised in the IT world almost as a religious cult; and a cult it is. Those managers who buy into this IT kindergarten principle have created an increase in IT costs that wouldn't make sense to those who see it for what is it - a huge time waster that can be replaced by being accountable for your work. Furthermore, paired programming has certainly been curtailed because of the push to work from home. Yes, virtual meetings can allow the process to take place, but now in a more cumbersome way. I say this because I watched a company I worked for go from getting praises and glory emails from the business partners to silence, crickets. Business meetings that turned into an hour long dead silence, or worse, many that did not even show up, or those attended became much more muted or even silenced; afraid to push back on the nonsense of it all. We went from cubes to cubified areas, to picnic tables where noisy phone conversations, casual chatter, and people shuffling around the room, reduced concentration to a trickle. With the meeting schedules, you are lucky if you get 2-3 days of work done a week. Multiply this times the number of days for the project to complete and you get into a real problem of proving that the expense is truly worth the time. I won't even get into the paired programming philosophy, where you have just doubled the cost of development on an on-going basis. Projects that took several months to complete now take a year or more. Anyone with any common sense simply cannot justify the added time and expense that is supposed to be offset by the claim to reduce scope creep and code errors. IT groups who push back and slam the door on businesses who attempt to add additional functionality many times end up losing in the end as being inflexible. Agile preachers will produce data and charts pointing to how you will really save time by suffering through all this. Large sessions are put on by Agile evangelists praising the Agile gods for giving us this process. This is especially true of projects where only 1 or 2 people work on it. While I would admit that the IT groups in a project that requires more than 3 people need to have meetings to make sure everyone is on point, it does not need a full blown carnival of meetings and daily stand-ups to accomplish this.
There has never been a replacement for quality, standardized software engineering practices. Many have tried but all have failed. Agile is merely the latest boondoggle and fad that our profession is currently experiencing. It was a pathetic paradigm from the beginning and will always remain so...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
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.
-
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
-
Agile has been praised in the IT world almost as a religious cult; and a cult it is. Those managers who buy into this IT kindergarten principle have created an increase in IT costs that wouldn't make sense to those who see it for what is it - a huge time waster that can be replaced by being accountable for your work. Furthermore, paired programming has certainly been curtailed because of the push to work from home. Yes, virtual meetings can allow the process to take place, but now in a more cumbersome way. I say this because I watched a company I worked for go from getting praises and glory emails from the business partners to silence, crickets. Business meetings that turned into an hour long dead silence, or worse, many that did not even show up, or those attended became much more muted or even silenced; afraid to push back on the nonsense of it all. We went from cubes to cubified areas, to picnic tables where noisy phone conversations, casual chatter, and people shuffling around the room, reduced concentration to a trickle. With the meeting schedules, you are lucky if you get 2-3 days of work done a week. Multiply this times the number of days for the project to complete and you get into a real problem of proving that the expense is truly worth the time. I won't even get into the paired programming philosophy, where you have just doubled the cost of development on an on-going basis. Projects that took several months to complete now take a year or more. Anyone with any common sense simply cannot justify the added time and expense that is supposed to be offset by the claim to reduce scope creep and code errors. IT groups who push back and slam the door on businesses who attempt to add additional functionality many times end up losing in the end as being inflexible. Agile preachers will produce data and charts pointing to how you will really save time by suffering through all this. Large sessions are put on by Agile evangelists praising the Agile gods for giving us this process. This is especially true of projects where only 1 or 2 people work on it. While I would admit that the IT groups in a project that requires more than 3 people need to have meetings to make sure everyone is on point, it does not need a full blown carnival of meetings and daily stand-ups to accomplish this.
I agree wholeheartedly. The principles found in the Agile Manifesto bear little resemblance to the resource-wasting, bloated bureaucracy of what is considered "Agile" today. Among the worst of the offenders in this current implementation is landing non-technical PMs and BAs in charge of managing software projects. Experienced software engineers can learn good project management and business processes FAR easier than non-technical business types can learn software engineering. FWIW, if you the reader have nothing better to do, here are some Linked articles I wrote a while back that are still true today and address this topic. Rethinking Software Development Agile Principles from a Traditional American View Soup to Nuts Software Development
-
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
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 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.
-
Agile has been praised in the IT world almost as a religious cult; and a cult it is. Those managers who buy into this IT kindergarten principle have created an increase in IT costs that wouldn't make sense to those who see it for what is it - a huge time waster that can be replaced by being accountable for your work. Furthermore, paired programming has certainly been curtailed because of the push to work from home. Yes, virtual meetings can allow the process to take place, but now in a more cumbersome way. I say this because I watched a company I worked for go from getting praises and glory emails from the business partners to silence, crickets. Business meetings that turned into an hour long dead silence, or worse, many that did not even show up, or those attended became much more muted or even silenced; afraid to push back on the nonsense of it all. We went from cubes to cubified areas, to picnic tables where noisy phone conversations, casual chatter, and people shuffling around the room, reduced concentration to a trickle. With the meeting schedules, you are lucky if you get 2-3 days of work done a week. Multiply this times the number of days for the project to complete and you get into a real problem of proving that the expense is truly worth the time. I won't even get into the paired programming philosophy, where you have just doubled the cost of development on an on-going basis. Projects that took several months to complete now take a year or more. Anyone with any common sense simply cannot justify the added time and expense that is supposed to be offset by the claim to reduce scope creep and code errors. IT groups who push back and slam the door on businesses who attempt to add additional functionality many times end up losing in the end as being inflexible. Agile preachers will produce data and charts pointing to how you will really save time by suffering through all this. Large sessions are put on by Agile evangelists praising the Agile gods for giving us this process. This is especially true of projects where only 1 or 2 people work on it. While I would admit that the IT groups in a project that requires more than 3 people need to have meetings to make sure everyone is on point, it does not need a full blown carnival of meetings and daily stand-ups to accomplish this.
Couldn't agree more. The customer facing side of agile with quick turnaround times and continual feedback is good. The management side is mostly crap. Pair programming? Who came up with that? That's way out there in left field. Agile is based on "collectivism" where the whole team "owns" everything which basically means nobody owns anything. When you don't have ownership for what you do, you are less likely to take care of it. Whens the last time you washed and vacuumed out a rental car before returning it? When you have complete ownership in what you do, its your baby and you will naturally do whatever it takes to make it a success. Its human nature. Developers should own the code they work on. If it breaks, they should be responsible to fix it. If its a success, they get the credit. Developers should be involved in all of the high level meetings with the customer, setting priorities, etc... In fact, there should be less project managers, more software engineer / rock star / project managers. Developers should be managing their own projects.
-
Agile has been praised in the IT world almost as a religious cult; and a cult it is. Those managers who buy into this IT kindergarten principle have created an increase in IT costs that wouldn't make sense to those who see it for what is it - a huge time waster that can be replaced by being accountable for your work. Furthermore, paired programming has certainly been curtailed because of the push to work from home. Yes, virtual meetings can allow the process to take place, but now in a more cumbersome way. I say this because I watched a company I worked for go from getting praises and glory emails from the business partners to silence, crickets. Business meetings that turned into an hour long dead silence, or worse, many that did not even show up, or those attended became much more muted or even silenced; afraid to push back on the nonsense of it all. We went from cubes to cubified areas, to picnic tables where noisy phone conversations, casual chatter, and people shuffling around the room, reduced concentration to a trickle. With the meeting schedules, you are lucky if you get 2-3 days of work done a week. Multiply this times the number of days for the project to complete and you get into a real problem of proving that the expense is truly worth the time. I won't even get into the paired programming philosophy, where you have just doubled the cost of development on an on-going basis. Projects that took several months to complete now take a year or more. Anyone with any common sense simply cannot justify the added time and expense that is supposed to be offset by the claim to reduce scope creep and code errors. IT groups who push back and slam the door on businesses who attempt to add additional functionality many times end up losing in the end as being inflexible. Agile preachers will produce data and charts pointing to how you will really save time by suffering through all this. Large sessions are put on by Agile evangelists praising the Agile gods for giving us this process. This is especially true of projects where only 1 or 2 people work on it. While I would admit that the IT groups in a project that requires more than 3 people need to have meetings to make sure everyone is on point, it does not need a full blown carnival of meetings and daily stand-ups to accomplish this.
