'Agile Programming is Not Dead, Quite the Opposite' (heartofagile.com) 216
"Agile is not dead, quite the opposite," argues Alistair Cockburn, one of the co-authors of the original Manifesto for Agile Software Development in 2001:
Why then, do we read of agile's death? Three reasons: phony ads, misunderstanding ordinary movement of ideas through society, and looking at the wrong curves... The sales pitch is pretty obvious when you look for it. Ignore those articles, they are just cheap sales tricks...
The pundits you are reading typically are innovators and early adopters. They adopted agile 10-15 years ago. Quite naturally, they have moved on and are working on the 2nd or 3rd round of interesting things that have arrived since then... They have been looking at lean startup, hypothesis testing, and agile product management, for example. All agile consequences, just a little more advanced. They have quite naturally (for them) forgotten the joy of discovering the agile approach for the first time. Everyone they know is already using it or has moved forward. To them it looks "passé", "dead"...
Choice A: agile. Choice B: something else. What is the something else that you think is more effective? For most projects, I can't think of another way that is more effective. Collaborate, deliver, reflect, improve, in cycles, from first idea until final delivery. This works whatever the nature of the project (no, agile is not just for software). Even badly done agile (please complain away at this moment, it's fine, there is a lot of bad agile out there), tends to be better than whatever came before it. That only tells you how bad all the things were that came before...
Agile is not dead, on the contrary. It's scarcely gotten started. Collaborate, deliver, reflect, and improve, in tight cycles. If you can find something better, use it.
The pundits you are reading typically are innovators and early adopters. They adopted agile 10-15 years ago. Quite naturally, they have moved on and are working on the 2nd or 3rd round of interesting things that have arrived since then... They have been looking at lean startup, hypothesis testing, and agile product management, for example. All agile consequences, just a little more advanced. They have quite naturally (for them) forgotten the joy of discovering the agile approach for the first time. Everyone they know is already using it or has moved forward. To them it looks "passé", "dead"...
Choice A: agile. Choice B: something else. What is the something else that you think is more effective? For most projects, I can't think of another way that is more effective. Collaborate, deliver, reflect, improve, in cycles, from first idea until final delivery. This works whatever the nature of the project (no, agile is not just for software). Even badly done agile (please complain away at this moment, it's fine, there is a lot of bad agile out there), tends to be better than whatever came before it. That only tells you how bad all the things were that came before...
Agile is not dead, on the contrary. It's scarcely gotten started. Collaborate, deliver, reflect, and improve, in tight cycles. If you can find something better, use it.
It's not dead (Score:5, Insightful)
the same way judaism, christianism, islam, hinduism, or any of the other kajillion cults around the world aren't dead. It's still a cult, it's not really relevant to anything truly useful nowadays, and it still have a lot of followers who cling to it and won't listen to the voice of reason no matter what.
Re: (Score:3)
I started reading the linked article and it is hilarious. I had to double check and make sure I wasn't reading something from The Onion.
Why then, do we read of agile’s death?
The first, phony ads, is when writers are selling something and they promote their idea by bouncing off the fear and hope that something better is just around the corner.
Oh, you mean like taking a "Certified ScrumMaster course" from "the Scrum Alliance" that you just mentioned in your previous paragraph?
This is Laugh Out Loud stupid.
Re: (Score:2)
Re: It's not dead (Score:2)
I think agileâ(TM)s a lot closer to scientology.
Re: It's not dead (Score:2)
Since the organization I work in have introduced Agile it's not far from the truth - a lot less agile than before and a lot less ordered and structured action around documentation causing documentation to go sour while development moves on.
Re:It's not dead (Score:4, Insightful)
All movements die. Some movements are successful.
I started programming in the mid 1970s, and the first movement I can remember is Structured Programming. Don't hear much from those folks these days, do you? Or the Software Tools guys, either. Having observed the rise and fall of these things, what fuels their popularity is the heady conviction that Finally We Have Figured It All Out. But the problem with the Truth is that it's so big you'll never have *all* of it, you'll never have enough to usher in the promised Age of Aquarius.
Successful movements die when most people decide They Have Some Valid Points. At that point the limitations of the movement also become clearer, and the stage is set for the Next Big Thing. Agile addressed certain long-neglected sociological aspects of software development. I think most reasonable people would conclude at this point that the Agile Programming folks have some valid points.
Re:It's not dead (Score:4, Informative)
Or they become so ingrained we don't bother anymore. Structured programming is what we use nowadays - where you split blocks into functional units and call/return.
Unstructured languages include assembly and BASIC - these were unstructured in that you can jump to any line from anywhere and in general could do very clever things, but end up with a pile of spaghetti. If you do things right, you can do structured programming with them, but it's not enforced
Structured is what everyone else uses where you have functional blocks that you call and return from. You know, .like functions and procedures. You cannot in general jump to the middle of a function from some arbitrary point in the program - you call the function and it starts from the top and goes to the bottom. If you have a conditional, you evaluate the conditional, run the "then" block if it's true, or the "else" block if it's false. Everything is laid out in functional blocks of code that have well defined entry and exit points.
Of course, some structured programming languages offer limited ability to do unstructured programming, usually by having a goto keyword, but typically you're limited to where you can actually jump to (like in C, you can't jump beyond a function - a goto label has to be within scope). Granted, Duff's Device and the like are oddities in the language, but it happens.
We don't hear much from them because well, it's just assumed nowadays that new languages would be structured - it just made life so much better it is taken as a given.
Heck, it's why one of the things MIcrosoft did was make a structured variant of BASIC they used for Visual BASIC. Sure you still don't have to declare all your variables, but you do have to create blocks of code and no random GOTO jumping around anymore. There's even functions and procedures that take parameters so you don't have to use global variables.
Re: (Score:2)
It isn't dead because it is a great way for people to power trip. I've worked in many Agile environments where the Scrum master acted like a boatswain/judge in a court of inquisition demanding to know why devs didn't get all their stuff in, the devs pointed to other people, yelled, "He's blocking me!", the other person replies, it turns into a mini pissing contest, then the Scrum master makes some comment about competency or laziness. Then it goes to the next developer, and the fights start again. Finally
Re: (Score:2)
it's not really relevant to anything truly useful nowadays,
Oh it's still worth a loud groan from anonymous voices in the crowd, and a loud chuckle seemingly from the ether whenever any of the terminology is used.
Perhaps TFS is correct, it's alive at its core, but most of the trappings and holy scripture get nothing more than loud mockery. Just last week someone proposed using JIRA for something reasonable, and we thought the idea wasn't awful, but because their tool seems to have a very Agile mindset in
Re: (Score:2, Informative)
Re: It's not dead (Score:2)
Re: (Score:2)
Re: (Score:2)
Agile vs. Waterfall? Talk about false dichotomies. It's clear you only have heard about other approaches and only "know" Agile.
The thing is, in large companies, Agile replaced waterfall. When I graduated in the mid-1990s from college, I worked at a 40-person company that did waterfall. I worked there until I went to a startup where they did XP (Extreme Programming) which was a precursor to Agile/Scrum. I left there for a Fortune 100 that did RUP (really slow waterfall), and after 5 years went to Nokia which was doing scrum before it was cool. I've been doing scrum or some other variation of iterative development that was called
Re: (Score:2)
They adopted agile 10-15 years ago. Quite naturally, they have moved on and are working on the 2nd or 3rd round of interesting things that have arrived since then
No, they "moved on" because Agile was the flavor-of-the-month buzzword and they have now moved on to The Next Big Thing®.
People who claim to believe in Agile can't even agree on what Agile is or explain it in a way that doesn't sound completely insane. That's the red flag which let's you know that Agile, and Mr. Alistair Cockburn, is bullshit.
What I've always done can be loosely called Agile- we just don't really bother with buzzwords much. (I guess that's the difference between small operations and big multi-man teams... we do what works for us, we just don't come up with fancy names to explain how we work to the CEO and veeps).
Re: (Score:2)
Re:It's not dead (Score:4, Interesting)
All these systems stay popular long enough for companies to fully transition over to them have a few release cycles then realize it didn't accomplish the goal: make X months of work take less than X months.
That's my problem wherever I've seen agile applied it's people over process for about 2 sprints if you are lucky. Using scrum as the example as it seems to be the most common version of this virus. Then a PO has "one more thing" to cram into the print, or something comes in mid-sprint and oh can't you get this thing done and still met your sprint goals too? Estimates are notoriously hard, requirements are rarely complete, priorities change daily etc. Some of the agile practices help with some of these issues but as long as there's more work than people there won't be a silver bullet you'll just be rearranging tasks more frequently.
Re: (Score:2)
Some of the agile practices help with some of these issues but as long as there's more work than people there won't be a silver bullet you'll just be rearranging tasks more frequently.
Spot on.
Re: It's not dead (Score:2)
This exactly. As a consultant, I've seen "scrum teams" way too large and not subdivided enough task-wise (overlapping, dependent teams), grabbing tasks as the scrum master demands because the project lacks a dedicated project owner. Also I've seen grooming that is code planning and reviews, which is not grooming. Having been on two proper Agile teams, I can say it works when done right, but you need to throw out everything you've learned about waterfall and few teams succeed at that. Having worked on games
Re: It's not dead (Score:2)
You're holding it wrong.
Re: (Score:3)
Then a PO has "one more thing" to cram into the print,
So you are also an idiot who does not know what a sprint is?
No, the PO is not cramping anything into a sprint!
a) what is in the sprint is defined by the team, not by the PO
b) a sprint is a _FIXED_ set of work items. As soon as the sprint started, nothing is added or removed or changed! How the funk would you assess a sprint at the end of time when it was changed during its conduction? Oh, we did fail because of added this, or removed that or change this
Re: (Score:3, Insightful)
a) what is in the sprint is defined by the team, not by the PO
b) a sprint is a _FIXED_ set of work items.
This is priceless... I'm going to print it out and hang it on my cube. I'll show it to every PM / PO who comes by and says that (owner of the company / COO / etc.) insists that feature X be included in the next sprint, without anything else being sacrificed or else things won't look good for your dev team.
There's "By The Book" Agile which, in theory, is not bad. But realisms comes crashing through.
Re: (Score:3)
b) a sprint is a _FIXED_ set of work items. As soon as the sprint started, nothing is added or removed or changed!
Wrong. You can add or remove things from a sprint but what you can't do is add more items to exceed capacity. If you add something and you don't have the capacity, you must remove something and delay it off to a future iteration/sprint. The main concept behind Agile is flexibility. If you start working on a sprint and the marketing department determines all the work is no longer valuable in the market, you don't just complete the sprint and do something different next time. That's a waste of time and m
Re: (Score:3)
Umm... isn't the whole point of sprint planning to agree on sprint goals BEFORE it starts? Those "one more thing" requests are supposed to get added to the backlog so they can get worked on during the next sprint IF they are deemed worthy by the team to be added and there isn't something else more important to work on.
If management can't buy into this most fundamental aspect of sprint planning, you might as well just give up now and go back to the waterfall method. Your sprints are going to fail if you can'
Re: (Score:3)
Umm... isn't the whole point of sprint planning to agree on sprint goals BEFORE it starts?
No. The purpose of sprints is to not do 6-12 months of work and then later find out none of that work was correct and/or valuable because the requirements or market changed. Sprint planning in smaller iterations is for the purpose of better make sure that the work the team does is valuable. Capacity planning and agreement on work are really just side benefits.
Re: It's not dead (Score:2)
"isn't the whole point of sprint planning to agree on sprint goals BEFORE it starts?"
These so called "goals" and "planning" are not Agile(tm). You're holding it wrong.
Re: (Score:2)
[I]t didn't accomplish the goal: make X months of work take less than X months.
Agile is not, and should never be billed as, a way to cram more work in to a unit of time. It's a way to transparently give people enough information to plan future projects effectively.
The points crap isn't for the developers. Points are for management to see and measure progress. Velocity is to let management figure out, for themselves, how long the greater project will take.
Breaking projects down into manageable chunks is the one great benefit for developers, but that, too, helps define velocity, wh
Re: (Score:2)
Agile is not, and should never be billed as, a way to cram more work in to a unit of time.
Thank you. This is the only correct thing I've read so far regarding Agile in this thread. I think some developers have done this to try to influence management to adopt Agile over death marches (aka waterfall) and they needed a selling point to.
Re: It's not dead (Score:2)
"to adopt Agile over death marches"
Hahahahahahahaha! Instead of starvation, we're gonna have famine!!
Re:It's not dead (Score:5, Insightful)
Agile has its place... though like more formal project management methods like Prince2 I treat them like guidelines: they are useful to make sure you don't miss important steps or other aspects of the project, they help in having everyone speak the same language and understand how the methodology is supposed to work, and they help manage expectations with stakeholders. But they are still guidelines... I see a great many project managers treat the method as a security blanket and the Ten Commandments at the same time; they have this idea that following the method perfectly and religiously is a sure fire way to make the project a success (it really isn't, and I'd say it doesn't even improve your chances significantly). The sad thing about Agile is that - where the Manifesto preaches "people over process" - the methodologies have been co-opted and taken over by the process monkeys who now require ordinary team members to hold an "Agile Practitioner" certificate... because of course only total understanding of (and adherence) to the process ensures success...
Agile isn't dead, and it didn't start out as a meaningless buzzword. It was simply ruined by the same people who tend to ruin regular project management. But there's still plenty of teams out there who understand what Agile is good for, what the pitfalls are and how to work around them.
Re: (Score:2)
The practitioner gets to decide the length sprints, which stake holders, which changes are accepted, what the priorities
Re: (Score:2)
And Mister Alistair Cockburn is a figure head in Use Case based Requirements Engineering and Software Development. (Which I don't agree with, I prefer the Ivar Jacobson way of writing Use Cases)
As soon as you have published a book with half the pages he has in his typical books, and are remotely known as one who contributes to "knowledg how to do software right", I might take you serious.
I've yet to see a single proponent bother to support their methodology on the merits. It's always bullshit they spout like the above worthless appeal to authority.
Re: It's not dead (Score:2)
Re: (Score:2)
Yep, He claims that: "The sales pitch is pretty obvious when you look for it. Ignore those articles, they are just cheap sales tricks..." but really he's the one who's guilty of that. The users out there aren't the ones lying to themselves.
Re:It's not dead (Score:5, Interesting)
I have found Software Programming, Development and Project Management to be faulty no matter what form you are doing.
They all seem to make the same bad assumptions.
1. The End User of the product has an Idea what they want for requirements. The end user wants to do a job, but when trying to say what they need, they often will miss out important components, and ask for features that no one ever used.
2. Little understanding on what the problem they are trying to solve it. They assume a computer will solve all the problems, while there is already an optimal process that doesn't need a computer.
3. Wrong people make the decisions. How many times when in the design phase you are in a room of VP's who never use the application or ever will. They are just working of 3rd party info from the end users.
4. Impatient people. Why spend months getting a solid foundation, when you need to demo the programs every couple of weeks.
5. Timelines to do something is highly depending on who is doing it. A 5 minute coding job for one person can take weeks for someone else.
6. Programming isn't an exact science, there is an art to the work. When you say I need 5 codes here. You better code it so it can handle any number of Codes, because while it isn't in the specs, they are probably going to be asking for it next year. Where you just turn on the feature, you look like a hero. Vs hard coding those 5 codes, then for the ask to add a 6th, noting that it will take a full migration of the data elements for something that seems really simple. Experience really helps to determine what is a good idea on paper, and what will probably change.
7. When you get developers working on one project mistakes are amplified.
In short Software Development is a sloppy process, Bosses like to try to put a formal method around it, so it seems easier to manage, only to run into exceptions and rework every few hours.
I'm getting old (Score:5, Insightful)
Maybe it's just me getting old, but why does it have to be either "Agile for everything" or "Agile is dead"?
Why not just figure out what your situation is, pick a method that works for situations like it and then tweak it to make it fit.
Re:I'm getting old (Score:5, Insightful)
The people pushing Agile want it to look like it's good for every project ever.
It has its niche, but most of what it sells are the basics of effective project management, and it advises taking those to extremes that are actually harmful for a lot of projects. It is now past the fad stage, and people have enough experience with it to understand why it is limited in application, so it looks dead in comparison to Peak Agile. People who think they have now discovered the silver bullet for engineering management want to exaggerate reports of Agile's death, so their methodology can fill the void. (Narrator: There is no such silver bullet.)
Re:I'm getting old (Score:5, Insightful)
Re: (Score:2)
RUP basically is Agile before it was called Agile.
Re: (Score:2)
The original RUP not so much, in a sense yes, but the follow up is much more agile.
RUP introduced iterative and incremental build up of software. You could call that agile, but it did not focus on giving the developers the freedom they need, which is the true agile thing.
Re: (Score:2)
Agile before it was called agile was called extreme programming.
RUP is a corporate bastardisation that came much later, when XP started gaining traction, and the business consultants wanted to get in on the game without sounding "extreme".
Re: I'm getting old (Score:2)
I prefer to visit the dentist over Agile meetings.
Re: (Score:2)
Well, at least a dentist appointment does something productive.
Re: (Score:2)
but most of what it sells are the basics of effective project management, and it advises taking those to extremes that are actually harmful for a lot of projects.
Wrong again. "Agile" sells: you don't need project management. Because a _good_ software teams knows by itself how to do software. Just like a surgeon exactly knows by himself how to do a surgery.
Bold intended.
Re: (Score:2)
It is clear you have a specific interpretation of 'Agile' that you hold near and dear to your heart.
What is being discussed is the reality of what 'Agile' has meant in practice when inflicted by a company on its developers.
As the popular consultant jargon of the day, 'Agile' has become a way for managers to argue from authority to make software developers do things exactly how the managers say to do it, because the managers paied to receive Agile 'training' that inevitably tells them they are right and they
Re: (Score:2)
You sound like you have neither experience with software development nor surgery. How many surgeries are you familiar with that take more than two or three hours to complete? The ones that do generally require multiple surgeons, working in tandem, with a specific and detailed advance plan, and ongoing communication during the surgery. Even for short surgeries, the surgeon is not the only person working on the job, and everyone in the operating theater has specific jobs that they are responsible for.
Simila
Re: (Score:3)
Because people are trying to sell you something. There is financial interest in selling you Agile consulting services, or whatever alternate methodology someone else comes up with. Really, to write software you just need to break the requirements down into pieces and then write the pieces. It isn't exactly brain surgery.
Re: (Score:2)
Brain surgery is a manual task.
Software development is a mental task.
You would be surprised to learn how many people are actually super good at manual tasks but super bad at mental tasks.
In other words: if my brain needs surgery ... a failing software developer would probably the best surgian :D (spelling wrong agian, it sucks :( )
Doop (Score:2)
Dupe
Now *that's* an obvious sales pitch (Score:5, Interesting)
"Pundits look like and say they stopped doing agile because they're actually doing more agile! Anything good is agile, and anything agile is better than whatever came before!"
People were doing iterative development before agile came along, and they will be doing it after agile is good and dead. Agile makes a lot of specific prescriptions beyond just cyclic iteration, and those points are where it almost inevitably causes problems. Agile is useful for cases where neither the developers nor the customer (the actual one or their representative) know what the system should look like, and for cases where the developer wants to spend a lot of time and money building stuff they know they will throw away.
For example, I was recently in a quasi-milestone review for a safety-of-life aviation system. The independent review board came from a government contracting line of business, and they more or less insisted that the system needed to adopt Agile DevSecOps -- never mind that the safety certification process requires pretty much the opposite of DevOps, that the technical subject matter is well-known to both the developers and the customers, and that the particular solution either does everything it needs to or is not fit for its purpose, Agile anything is an effective way to spend customer money and claim to be making progress regardless of close the work product is to being actually useful.
Re: (Score:3, Insightful)
It seems like one of the real problems with agile, waterfall, whatever, is the strict adherence to someone's definition of the proper way to do all development. Instead of rigid adherence, understand your industry, your customer, your stage of development, etc and be... cough... agile and use the development methods needed for where your development is at.
Re: (Score:2)
Almost. Every project has a broad model for its delivery that will be most appropriate. That model will be different for different projects. The biggest factors that determine the "right" model for a project are the team culture and habits, and their familiarity with the technical issues they'll face, followed by how well the customer understands their needs. (That last is less important than it might seem because even halfway decent developers usually have effective ways to elicit requirements and prototy
Re: (Score:2)
It seems like one of the real problems with agile, waterfall, whatever, is the strict adherence to someone's definition of the proper way to do all development. Instead of rigid adherence, understand your industry, your customer, your stage of development, etc and be... cough... agile and use the development methods needed for where your development is at.
Yes, that is the ultimate irony.
There is nothing agile about Agile development. It is extremely rigid -- the exact opposite of what the name implies. Agile is the Islam of programming methodology.
Re: (Score:2)
Every method is rigid.
The method is no supposed to be "agile". Unless you perhaps think about Boehms Spiral (meta) model.
The team is supposed to take the instruments the method gives them to be agile.
Can't be so hard to grasp.
Re:Now *that's* an obvious sales pitch (Score:5, Interesting)
Agile makes a lot of specific prescriptions beyond just cyclic iteration, and those points are where it almost inevitably causes problems
Agile makes no specific prescriptions. Scrum does. Kanban does. eXtrEME programming does. Whatever the consultants want to sell you this week does.
Agile is just "plan for the customer to change his mind by making it cheap to change". Not sure how that became the cancer killing software development that it is. You can't just blame consultants - not enough of them.
Agile has never made sense where the requirements are fixed in stone -- regulatory compliance, and the like -- because it's optimized for changing requirements on the fly and minimizing throwaway work. Pretty much the wrong answer if the requirements are fixed external to the company, and are unlikely to change in any given year.
Re: (Score:2)
never mind that the safety certification process requires pretty much the opposite of DevOps,
That does not make any sense. What has safety to do with DevOps (or Agile with DevOps)?
Agile anything is an effective way to spend customer money and claim to be making progress regardless of close the work product is to being actually useful.
Wow, if you think that: you are not doing it right (idiot?)
Re: (Score:2)
People lump DevOps with Agile as a way to increase their buzzword compliance, or at least to claim they are aligning business processes with customer values. DevOps conflicts with safety-of-life systems because such systems are typically heavily regulated, with extensive documentation and verification requirements, and that is mostly incompatible with the DevOps philosophy. Even the deployed use of such systems is typically heavily related, requiring specific training, testing, and certification of operato
I'm not that agile (Score:4, Funny)
I'm old.
Well of course _he_ says that (Score:5, Informative)
He's one of the originators of the Agile Manifesto.
His example misses the point. The point is that while the original Manifesto had great ideas, people - like Cockburn - have corrupted it with ridiculous practices. So we now have the open team room where no one can concentrate, 15 minute meetings where everyone has to stand and be interrogated, an obsessive focus on the backlog and story grooming instead of design discussions, "scrum masters" who play lead but have never coded, and almost no attention to integration across teams.
The original ideas of Agile were sound, but the movement itself went off the rails, partly because of Scrum certification encouraging lots of non-programmers to get into the field. That's why DevOps is a much better paradigm today - it restores the technical dimension that Agile lost.
Re: (Score:2, Interesting)
I'm not sure I agree with you, but I did mod you up because you bring up some interesting points. I don't think Agile has gone off the rails, though I think a lot of folks try to call themselves "agile" without really understanding what it is or communicating to their teams how it's supposed to work. Of course those people struggle to get Agile work.
I do see where the Scrum certification stuff has put a profit motive into the mix, but let's be honest, if Agile didn't actually work for some folks, nobody wo
Re: (Score:3)
You've never heard of group think have you?
People pay for all kinds of crap. People fall for all kinds of fad. So no, paying for something is not evidence of its success. Its evidence of how gullible people are.
Re:Well of course _he_ says that (Score:4, Interesting)
I'd be very hesitant about agreeing with DevOps recovering a technical dimension.
I've worked alongside quite a few DevOps adherents. My own history is about 40 years of coding (including going into Real Time systems, along with software engineering), then moving into Ops fully about 20 years ago and then to systems architecture, so I've got a fair handle on what it really takes to build a system and keep it running.
Most DevOps people I run into are developers who've effectively learned to search on how to install Docker and cut and paste bits and pieces without fully understanding what's going on.
The advantages are the very obvious "get up and running quickly", and "have a visible product quickly", but completely ignore the vast technical debt being built up. This includes both the disaster recovery/business continuity side (no, restarting the containers doesn't always work, especially when the issue is somewhere else) and the security side (I've been party to many a conversation concentrating entirely on one technical aspect, and assuming that this deals with security, while being blissfully ignorant and dismissive of all the other avenues that exist and casually baking in insecurity by design).
Generally, I've come to see it as Developers who want to believe that they understand Ops. Mostly, they don't. The corporate environment believes it's got the silver bullet of getting both jobs done by one person, so who needs Ops (they're treated as an expense, not a department that protects your infrastructure, and an insurance policy when things go wrong).
As a small team of hybrids between Dev and Ops, I've found them useful (or perhaps in a very small team where there simply isn't resource), but I'm finding it a large distance away from the panacea for all ills that people believe it is.
Re: (Score:2)
5 minute meetings where everyone has to stand and be interrogated, an obsessive focus on the backlog and story grooming instead of design discussions,
As mentioned many times today. If that is happening in your case:
you are doing it all wrong!
Sorry, bold is intention ... and you are either an idiot or super dumb.
Re: (Score:2)
you are doing it all wrong!
Funny as shit.. keep sayin it. Makes me laugh every time.
Re: (Score:2)
hat's why DevOps is a much better paradigm today
For funk sake, DevOps is not a software development method,
It is a damn job description, like driver, clerk, pilot.
Comment removed (Score:5, Insightful)
Re: (Score:3)
Hmm...so as long as all the players are competent, the Agile succeeds. And this is different from any other methodology how?
Re: (Score:3)
Re: (Score:3)
The problem I see is that many developers argue from their 'niche', and in software development those niches are wide and deep. If you're an embedded systems developer, solid project requirements are very much the norm. Deviating from them can cause considerable trouble (eg 737 Max). OTOH, a web developer may be lucky to even get half the project requirements defined up front. Agile, Waterfall, or whatever, a competent team lead by competent management will choose the right tool for the job.
I would argue th
Re: (Score:2)
That is actually a good description what leadership in a software company is about.
You don't manage teams, you remove problems for the teams, and the team is focusing on: getting stuff done!
Joy? There is no joy. (Score:2)
Choice A: agile. Choice B (Score:2)
You're either with us or against us. (where did you read that one?)
Childish worldview at best.
I was using agile in the 1970s, but we didn't... (Score:5, Funny)
Re: (Score:3)
Exactly. I still do that. Well, I do a bit of design up front. But people somehow think that writing software is like building a building. It isn't. Software is easy to change. If you write something, and it needs to be tweaked, or a layer needs to be rewritten, then just do it. No one dies.
Re: (Score:2)
Yah, it is called the Dirty Snowball Method of building software. And as long as you have really, really good people, and the system is small (and hence small number of people needed to build it), then it works. Otherwise, it goes down in flames and after the snow has melted you are left with bits, bytes, and nibbles splattered across the offices of the people who built it.
Re: (Score:2)
Re: (Score:2)
That has nothing to do with agile, it is simply busy and no one can blame you for being lazy, but: it is foolish.
Re: (Score:3)
https://dilbert.com/strip/2007... [dilbert.com]
Re: (Score:2)
Something better? (Score:2)
" If you can find something better, use it."
Thanks, we did long ago, it wasn't hard. We'll leave Agile to the pseudo religious nutcases like you Mr Cockburn (what an apt name) who still believe its the One True Way. You ever read any L. Rob Hubbard btw?
Re: (Score:2)
L. Rod Hubbard? Is that any relation to Jethro Clamplett...or possible L. Ron Hubbard?
Re: (Score:2)
Cockburn (what an apt name) :D
The name is of french ancestry and not pronounced like you believe it is is.
It is more "Cogh-bun" or "Co-bun", I hope Alistair forgives me if he reads this
You ever read any L. Rob Hubbard btw?
No, I did not. Did you? Actually the claim is his first SF stories where quite good, so I'm indeed looking forward to read them once, will you?
Hereâ(TM)s whatâ(TM)s so wrong with Agil (Score:3)
https://github.com/rayfrankenstein/AITOW/blob/master/README.md
Re:Here's what's so wrong with Agile (Score:2)
Mod parent +1 interesting!
Wow, that was a depressing read. Many, many points brought up are definitely pain points!
Agile could be called Fragile for how brittle it is. =P
The first red flag should be anyone claiming to have found a "silver bullet" in software development. The "best" methodology depends on the team, scope, customer, management, etc.
Micro-managing a task doesn't make it go faster, it actually makes it go slower. Sometimes big tasks really do take a long time. Sometimes you have external block
Not dead, nor the opposite. (Score:2)
It's not that 'Agile' is bad.. (Score:4, Interesting)
It's that in practice 'Agile' means whatever snake-oil salesmen want it to mean.
Any meaning of the brand has been diluted by consultants using the brand to sell self-assurance to executives wanting to believe they are transforming their business into one that will see success. 'Agile' methodology hits the critical buzzword in the name and so it is pitched as a magical dust to put on your failing business effort to make it succeed.
A critical facet of this is the consultant ultimately has to agree with their client's views, lest they lose the client's money. So they have to find a way to operate within their client's world view to let them carry on the way they want to, but at least believe they are transformative.
The original manifesto was ultimately a short collection of obvious frustrations with how the people in the room felt things should be versus how they really were in practice. If somehow magically the current state of 'Agile' came into being without that manifesto, then a group of people getting frustrated with Agile shops would likely write down the exact same four complaints.
Religion is right (Score:4, Insightful)
Agile / scrum is no different to the others except apart from the shrillness and zealotry of its acolytes. I suppose in a few years another One True Process will appear promising to right all the wrongs of agile and we'll go around this tedious merry-go-round all over again.
Re: (Score:2)
Oh, we do not need a sail, we have an engine (the engine makes 4 knots and you have fuel for 100 miles - less actually) and with sails you make 7 - 8 knots and can go indefinitely ... but you are so smart and handling the sails looks so complicated at first glance that you simply drop them ... big stupid mistake. You are not sailing. You are running a motor boat which is not supposed to be run by motor except when leaving the harbor or entering it or having an emergency.
At least it's possible for someone to objectively point out a boat doesn't have enough fuel on board to make it to a destination.
At least objective benefits and drawbacks of sails can be communicated.
Either of these are more than any Agile priest has done to provide a merit based case in support of their methodology.
Agile is not dead (Score:2)
It just smells that way.
Re: (Score:2)
'Ere, he says he's not dead.
Yes he is.
I'm getting better.
No you're not, you'll be stone dead in a moment.
It is working! (Score:2)
You're just holding it wrong.
Agile was a fad, get over it (Score:2)
scrumbags and agiletard leave behind a trainwreck of long lists of unresolved bugs stuck in meetings and no documentation
fuck 'em
From a developer's perspective Agile is a cult. (Score:2)
When I hear "Agile" now a days I just tells me I need to up my billing rate and make sure
Vagueness as virtue (Score:2)
Agile is too vague to be dead. You will always find projects to fit your definition of agile.
What is the normative definition for "Agile"? (Score:4, Insightful)
We get told "If it's not working, you're doing it wrong." So what is the normative definition of "agile," sufficiently rigorous to allow someone (whether a manager, a tech lead or an external evaluator) to be able to say "Yes, you're doing it right." or "No, you are not doing xyz." ??
What is agile really? (Score:2)
I can never decide whether "agile" is nonsense or obvious. Is it a cult or is it just a summary of what I've been doing all along? It seems to depend who I'm talking to at any moment.
I'd never just dive in and start coding. I always take time to do a proper design first and get buy-in from everyone involved. But that doesn't mean a huge multi-month design process. It just means I've taken the time to clarify the problem in my own mind and consider possible approaches. The "design description" might ju
Re: (Score:2)
Re: (Score:3)
"Agile is not dead, quite the opposite,"
So ... it's undead?
Re: (Score:2)
I'm more surprised it's not a name George Lucas invented.
Re: (Score:2)
So what do you want him to "sell" instead?
Is t a crime or morraly wrong to teach people in a thing you are convinced about it is right?
Re: (Score:2)
"So what do you want him to "sell" instead?"
Something that is useful, that doesn't wreak havoc on businesses.
"Is t a crime or morraly wrong to teach people in a thing you are convinced about it is right?"
No, it's not "morraly wrong". No more than any other charlatanism. When the person who stands to profit from a thing is at odds with multitudes who gain nothing, it should be enough to make one pause.
I noticed my post was down-voted. I must have raised the ire of Agile "true believers".