The Agile Cult
-
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.
-
raddevus wrote:
You were less agile with Agile, but more agile without it.
What this highlights is that whenever there is a Hot New Topic in town, it takes on multiple meanings: 1. The original meaning, which was usually a bottom-up, emerged kind of way in which developers, through trial and error, came up with a fruitful way-of-work that was a natural fit to them. In this case it was "agile" (no capital used), agile, as in, agility, flexible, to-the-point, and additionally to that, a team where members would operate in mutual trust and a shared understanding of the job at hand which turned out to be pretty darn effective. 2. The way it was landed into the belief system of a management party (colloquially referred to as "the boss"). This is no longer a first-hand experience and loses its initial authenticity and it much depends on a kind-of self-discipline exerted by the aforementioned manager, in how authentically and truthfully they process whatever information comes to them. Now, it so happens that the position of manager is a major attraction to those individuals who have a combination of, say, being verbally apt, but factually feeble, and shall we say, gullible, or sometimes, just short-sighted. It's not hard to imagine how a fad can grow out of proportion in such hands.
I've mentally broken it into four five levels: 1. agile 2. Agile 3. "Agile" 4. Aaaaarrrrggghhhh!!! 5. The Madness of Cthulhu Sounds like he's somewhere between 4 and 5.
-
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.
Member 14840496 wrote:
But since pair programming IS part of Agile, not practicing it means that one is not doing pure Agile.
Pure "Agile", there is a laugh. So many flavors, so many opinions on what Agile is you can do almost anything and call it "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.
I agree with you, aside from your point that just talking to each other is enough in large teams. From a certain team size on (maybe ~8+ programmers), I don't see how it can work without agile. In an innovative environment, where the project goals change several times over time, it's almost impossible to keep everyone heading in the same direction without any formal procedures. I also find them painful, but I see the necessity.
-
I agree with you, aside from your point that just talking to each other is enough in large teams. From a certain team size on (maybe ~8+ programmers), I don't see how it can work without agile. In an innovative environment, where the project goals change several times over time, it's almost impossible to keep everyone heading in the same direction without any formal procedures. I also find them painful, but I see the necessity.
Can you not have a simple group meeting once a week together? Does it require Agile to MAKE you do what you should be doing anyway? Do you need all the retro, what went right, what went wrong, what can we do better, business meetings where many are not present, stand up every day? Really? Do we need to be herded around like cattle in order to do something we should do on our own? Good grief. :sigh:
-
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
-
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.
It has it's place. In the right place it can work well. My 2c. Any methodology can be made to work with the right people involved. I've seen really slick implementations of Agile that were doing great work. More often though I've seen really sick implementations of Faintly Resembling Agile (Fragile) that are like a big ship in search of an iceberg. I think Agile is reliant heavily on the cohesion of the people and their shared vision in a way that other approaches do not suffer. And in my experience it gets worse as the team size grows. The only other thing that I would add is that the current fad for Agile for everything is dangerous. Agile procurement, Agile quality control. . .For starters it does not fit well with fixed price solution procurements in Government. PS: I'm a Certified Scrum Master.
-
It has it's place. In the right place it can work well. My 2c. Any methodology can be made to work with the right people involved. I've seen really slick implementations of Agile that were doing great work. More often though I've seen really sick implementations of Faintly Resembling Agile (Fragile) that are like a big ship in search of an iceberg. I think Agile is reliant heavily on the cohesion of the people and their shared vision in a way that other approaches do not suffer. And in my experience it gets worse as the team size grows. The only other thing that I would add is that the current fad for Agile for everything is dangerous. Agile procurement, Agile quality control. . .For starters it does not fit well with fixed price solution procurements in Government. PS: I'm a Certified Scrum Master.
There has been a lot of back and forth about Agile in here. The majority do not like it. While this link is 6 years old, it fits best. https://toolshed.com/2015/05/the-failure-of-agile.html