The Agile Cult
-
The group I was in was doing Agile already, but without the kindergarten classes. But since pair programming IS part of Agile, not practicing it means that one is not doing pure Agile.
-
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.
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.
-
Because it was forced on us by management. I think Gerry Schmitz's response sums it up quite nicely.
-
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 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
-
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.
-
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.
-
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
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.
-
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
-
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.
-
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?
-
Because it was forced on us by management. I think Gerry Schmitz's response sums it up quite nicely.
-
Interesting but the problem here is that the manager was also an Agile instructor/guru/etc. Again, I will defer back to Gerry Schmitz's response - it applies here.
-
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.
I saw a lot times when managers who have no clue, are trying to figure out by the reaction of the developers to their suggestions how long a certain task would take. Agile just forces them to ask without being afraid to betray their ignorance.
Nick Polyak
-
Interesting but the problem here is that the manager was also an Agile instructor/guru/etc. Again, I will defer back to Gerry Schmitz's response - it applies here.
Huge difference between being a good Agile instructor and being a good dev manager. The former requires good speaking skills and good knowledge of the material. The latter requires good listening skills, a great BS filter and the ability to herd cats.
-
Interesting but the problem here is that the manager was also an Agile instructor/guru/etc. Again, I will defer back to Gerry Schmitz's response - it applies here.
As far as I can see, Garry and i say the same... Incompetent managers in charge of process or architecture decisions is the problem. Neither should be the responsibility of managers. Having the manager being the process "guru" is even worse - no chance of a second opinion if he does not listen. Knowing when not to apply a process - even if you had success with it earlier - is hard to do, and just because you are seen as a "guru" does not mean you have mastered this.
-
As far as I can see, Garry and i say the same... Incompetent managers in charge of process or architecture decisions is the problem. Neither should be the responsibility of managers. Having the manager being the process "guru" is even worse - no chance of a second opinion if he does not listen. Knowing when not to apply a process - even if you had success with it earlier - is hard to do, and just because you are seen as a "guru" does not mean you have mastered this.
This article sort of confirmed my assertion. The article seems more like a psychology brief.https://codeproject.freetls.fastly.net/script/Forums/Images/smiley_biggrin.gif Agile Ready Leaders Get Their Start in Kindergarten Published on December 23, 2016
-
Agile smagile. I'm enjoying myself much more now that I'm a team of one and can just code.
Real programmers use butterflies
Team-of-one is the best.
-
Yes they can be done, but often they are not. Agile kind of forces people to do them.
Nick Polyak
"Agile" doesn't force anything.
-
Our team went through the same pain years ago, when consultants in the US tricked convinced management to go this route. So we followed the rules until the deadlines got too near, when we were told to revert to our normal mode of working, and get the job done.
-
Member 14840496 wrote:
it means that one is not doing pure Agile.
No. There are lots of flavors of Agile. Regardless, take what is good and works for you from Agile and go with it.
