Should Developers Abandon Agile? (ronjeffries.com)

An anonymous reader quotes InfoQ: Ron Jeffries, author, speaker, one of the creators of Extreme Programming (XP), and a signatory of the Agile Manifesto back in 2001, shared a post on his blog in which he advocates that developers should abandon "Agile". The post further elaborated that developers should stay away from the "Faux Agile" or "Dark Agile" forms, and instead get closer to the values and principles of the Manifesto. The terms "Faux Agile" and "Dark Agile" are used by the author to give emphasis to the variety of the so-called "Agile" approaches that have contributed, according to him, to make the life of the developers worse rather than better, which is the antithesis of one of the initial ideas of the Agile Manifesto...
Jeffries writes that "When 'Agile' ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to 'go faster'. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing 'Agile' poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing 'Agile'...

"it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers' lives worse, instead of better. It also saddens me that the enterprise isn't getting what it could out of the deal, but my main concern is for the people doing the work..." He argues developers should instead just focus on Agile's good general software development practices -- like regularly producing fully-tested software and consciously avoiding "crufty" complex designs.

But what do Slashdot's readers think? Should developers abandon Agile?

Comments

One problem: no normative definition of "Agile"

[david.emery]

This makes it really difficult for an organization to determine if they're truly doing "Agile" or some bastard form. It also calls into question methods and even formal standards built on 'Agile'.

But when I've pressed Agile Evangelists on this, usually when we've had problems and I've asked, "So are we doing Agile", all I've gotten in return is, "If it's not working, you're not doing it right."

Re:One problem: no normative definition of "Agile"

[Hognoxious]

I initially read that as "If it's working, you're not doing it right."

I'm on the fence as to which is more accurate.

Re:One problem: no normative definition of "Agile"

[93 Escort Wagon]

Problem is -“agile” is often used as a management code word for “understaffed, overworked, and unsupported”.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

Agile does not fix broken teams.

Agile can work just fine for non-broken teams.

You do not fix your communications process by forcing a high communication process on them.

Re:One problem: no normative definition of "Agile"

[HornWumpus]

There is not much to argue about in the Manifesto. Pretty much truisms. My only criticism is: 'Management won't get it, will only see the parts they like. If they got it, they wouldn't need it. If they need it, they won't get it.'

IMHO the key part of the manifesto was 'hire competent enthusiastic individuals'...which can be used to validate claims of agility. Those people DON"T work for industry average. If an organization is paying industry average, it _cannot_ be agile. Most likely it's 'agility' amounts to management's ability to maintain a bidirectional circle jerk.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

True Agile only works on the Cloud. And the more IoT AI you use, the better it works.

Re:One problem: no normative definition of "Agile"

[phantomfive]

There is, though. Right there at the top it says, "We value individuals and interactions over processes and tools." Is Agile a process? Primarily it's not. Ask your consultant what they are doing to value individuals over processes. Watch the blank look of fear, followed by a stream of BS coming out of their mouth.

Re:One problem: no normative definition of "Agile"

[turbidostato]

"Problem is -âoeagileâ is often used as a management code word for âoeunderstaffed, overworked, and unsupportedâ."

Problem is, as always it is, that managers are morons.

Well, in fact they are *not* morons, but clever people that cleverly respond to their environment -that's the fundamental difference with the minions. Minions see -and look for, what is needed. Managers offer what is wanted -at face value. Do you want me to shoot you on your head? There. Done.

But, anyway, managers are always and without possible dispute, the real and absolute culprit.

Now, back to the main issue: this is no news. It's been known for ages that a good team will offer a good result even against the methology imposed by (fucking moronic -all of them, that is) managers. On the other hand, on not so good teams (aka, most of them) no amount of methodology (fucking moronic -all of them, that is) managers throw at them will work.

To compose the problem, "the system" has perfected itself on past decades so, while, say, back in the 80's, you might end up with a performant team basically by sheer luck, nowadays "the system" makes that impossible.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

That's essentially, the "no true Scotsman" fallacy.

Re:One problem: no normative definition of "Agile"

[khchung]

Problem is ANY BUZZ WORD would be used as a management code word for "understaffed, overworked, and unsupported".

In short, problem is in the management.

Re:One problem: no normative definition of "Agile"

[alvinrod]

Yeah, this has been known for a while.

Re:One problem: no normative definition of "Agile"

[arth1]

The "No True Scotsman" fallacy is one of the most annoying things about Agile. "You're not doing it right" has become a mantra for explaining away any shortcomings, of which there are more than a few.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

Agile is the academic equivalent of letting grade school kids help create the rules. The problem is if you have shitty managers that only care about getting "more done" then it doesn't matter what process you use, they will still demand "more done" without proper long term planning or realistic time frame spent on research, design and testing

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

Agile is a lie, I agree with posters. Agile means a foreign H1-B worker (likely Indian) with no rights is being overworked 14 hours a day. It also means no black and definitely no latino workers on projects. Fewer and fewer white males and females in manager and above roles due to HP purposes. Everybody knows that. Just ask traitor companies like Google, FB or Apple. I just do not understand why? These giant companies do not even have competition anymore. Why do they have to suck the life out of their workers?

Re:One problem: no normative definition of "Agile"

[plopez]

"Agile" has no definition because it is supposed to be an adjective, not a noun.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

> "Agile" has no definition because it is supposed to be an adjective, not a noun.

Adjectives don't have definitions??

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

Yeah. It's a sign of tunnel vision when you think your methodology is always right, and if it isn't, it's still right.

No methodology is always right, for every job, all the time. If "not using Agile" is part of using Agile, then yes, I'd say they're correct. But I haven't heard that from any Agile evangelists.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

One sign of trouble for Agile is that PMI has worked it into the PMBOK, which ensures that poorly trained (but PMI certified) hacks will be destroying its effectiveness for years to come.

Re:One problem: no normative definition of "Agile"

[HGG]

Why is Agile a moving target? I think it goes like this:

The original vision was great: Many projects are hard because they require high-quality human interfaces. Humans are lousy at pre-specifying what they want for interfaces, so waterfall specs are slow and useless. The better approach is to just prototype stuff and have the user try it out. If your development cycle is vastly faster than users review cycle, you do real code instead of prototypes. Continue to grow the app as users' understanding of their needs evolves.

What's missing? Agile is all about doing one new app very well/quickly. Often (in my experience ) the app shouldn't have been done in the first place -- it was a workaround to a workaround, adding one more plop to the enterprise steaming heap. Instead we need to do systems (portfolio-wide) architecture at the start of a project to determine business case go/no-go, impact to data model, impact to data allocation to logical resources (which apps handle which data?), and external interfaces. Then use Agile for evolution of the user interface.

Isn't architrecrture too slow -- defeating the purpose of Agile? On a small project the architecture phase is 2 days. On a serious project it is maybe 2 weeks. Anyone doing 2 months of architecture either a) doesn't know what they are doing, or b) is dealing with a topic too loose to architect much less code. Assuming the project proceeds, revisit the architecture when the data model, data allocation, or external interfaces change

So why does Agile itself change? Agile gets in trouble when its true believers claim it is the revolutionary solution to everything software engineering. And then has to jump and jig to handle what it calls special cases. “Uh, we meant of course to include interface control governance; we just forgot to mention it". Calling something "Agile Enrterprise Architecture" doesn't make it so.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

Yeah. Or it will get corrupted by ISO or similar.

Look at the notion of 'continuous improvement' (aka Kaizen). It's now part of ISO9001:2015 with a formalised continuous improvement process.

I can imagine it now. ISO9001:2020 formalised agile software development procedure part A section 2...

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

Problem is not every methodology works well for every team or every project. People that think Agile or Waterfall or one of the other thousand variants is the be all and end all to project development are destined to fail. Anyone that has the view that "If it's not working, you're not doing it right." fundamentally doesn't understand the dynamic requirements of various projects.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

Does this remind anyone of the "No True Scotsman" falacy? https://en.wikipedia.org/wiki/No_true_Scotsman

No true implementation of Agile fails. ... but my organization's implementation of Agile is failing
Then your organization is not doing a true implementation of Agile.

(Personally I find agile, even when done well, is much better than any alternative I've worked with so far... I just found the logical fallacy interesting.)

Re:One problem: no normative definition of "Agile"

[Maxo-Texas]

Yea, but even as a non-agile developer you can see when the agile team has decayed to waterfall method, has stopped timeboxing, and abandoned other core behaviors and features.

I always preferred RUP. It seemed to work better with business partners.

It was very clear that you identified risk and eliminated it *first* before starting generic ("construction") coding, that you *always* timeboxed, you never delayed a release for a "really important feature that wasn't quite ready yet", you had regular updates on the status of each feature point.

It was similar to agile but it wasn't agile. I like the theory of agile, but in practice it usually collapsed to waterfall under pressure.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

At least the overworked part is correct. I've worked "Seattle Hundreds" for most of the past fifteen years, and that has sucked. In case you don't live in Seattle or the Bay Area, that's 16 hours each day Monday through Thursday and 12 hours a day Friday through Sunday. That eventually wears you down. Adding Agile to the mix just makes things worse since you usually have two scrum meetings per day where you have to talk about what you accomplished since the last meeting and what you commit to completing before the next meeting. Saturdays and Sundays weren't as bad since no where I worked had more than one scrum meeting per day on the weekend. When you add-in all of the other Agile ceremonies like weekly retrospectives, sprint grooming, sprint planning, and sprint demos. you can easily spend twenty+ hours a week in Agile meetings.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

https://en.wikipedia.org/wiki/Agile_software_development#Agile_software_development_practices

Re:One problem: no normative definition of "Agile"

[Tough Love]

The noun "agile" has no definition, that is, not until now, where it basically means "wanking".

Re:One problem: no normative definition of "Agile"

[Z00L00K]

Regardless of which way you work you should try to look at the pieces that works well and improve the pieces that don't work well. Just nuking a whole company structure for a new process is never going to end well, it's like putting the building on fire because there's a few spiders in it.

Instead you should try to figure out why the spiders are there in the first place - maybe it's because they are the symptom of something worse in the house that you really don't want. Or the spiders are just opportunists themselves and will go away when they see that there's nothing to catch.

Processes shall always be built and improved slowly from the bottom to the top over time. Sometimes you need to re-arrange your organization, but it's a rare occurrence and done right you can do it step by step. The responsibility of the management is to know their organization and actually be present on the floor from time to time and talk with the people working. That will give a lot more than following the How Shit Happens procedure.

Re:One problem: no normative definition of "Agile"

[tlhIngan]

I've never gotten Agile.

Our company doesn't use Agile anything. Strictly speaking, it's waterfall - we get a project from a customer, and we (engineers, sales and customer) work hard figuring out a list of requirements (we have to know what we're building, after all). This can take a little while - often engineering will scrap a list of requirements, step back, and ask the customer "what are you REALLY wanting here?"

As in, the customer gave us a list of stuff, but we stepped back, asked what they really wanted in the end (i.e., we go from the detailed view to the 10,000 foot view) This makes it possible to see if there is a better way to accomplish what the customer actually wants.

Then once we have requirements, we start building. Weekly, we'd meet with the customer and provide status updates, and the customer can redirect our efforts - perhaps a priority changed, or it turns out the customer doesn't want something anymore, and we work on new stuff. When something is complete, or a milestone reached, we cut a release and give the customer time to play with it and redirect our efforts again. Lather rinse repeat.

We have no "sprints" or tasks to do in a sprint - we have a list of what the customer wants done, and for the most part, those tasks take far longer than most sprints. (We have had many customers who do Agile and asked about what we'd do in the sprint, and we'd have to explain that the feature they want can't be broken down into one week work periods - it's a task that will take 3 weeks. We could break it into meaningless subtasks but that makes a huge assumption that you can work on a subtask alone - most of the work in a task is closely related so you may work on subtask A, switch to subtask B because A needs a modification in B, then go back to A, switch to C, etc.).
'
For the most part, it works - customers are generally quite happy, they know where the sore points are and we fix them immediately, and it's happened that many projects start out as a tiny little one that grew into a huge multi-year thing as customers want to try us out, are satisfied and impressed with our work and then give us more bits and pieces to do.

And no, our releases are on the order of once a month or so - the systems are complex enough that builds can take a day or so (often customers get source code, but some parts they can't because it requires licensing they don't have, so we have to make partial binary builds. And yes, we test to make sure those actually build). And there's also a QA process too to ensure no regressions. Customers cannot skip QA (builds often signify milestones), but they can get "early releases" which mean they get builds as soon as they hit QA with the caveat that some things may be broken And it does mean sometimes we've halted the release because of a showstopper and take time to fix it and re-release.

Re:One problem: no normative definition of "Agile"

[mikael]

Those white males and females are either getting out of the industry by the time they are 50, or becoming tech writers, software consultants and/or running their own businesses.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

If you are implementing features incrementally, showing the customer on regular intervals and then allowing the users to provide feedback and then re-prioritize stories during the project, you are pretty much following the "spirit" of Agile. I see the most important part of Agile as delivering the most valuable features to customers in an iterative fashion so you can constantly make sure you are on the right track. The problem with the old, pure-waterfall approach was the fact teams would take a huge amount of time up-front to come up with requirements (which are often poorly captured and change over time) and then go on to design and build a system for many months/years before actually showing the customer. This results in building something that really doesn't meet the users' needs due to the fact the customer may not have articulated the requirements properly, their actual needs changed over time, and your analysts may not have captured the requirements properly.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

"If it's not working, you're not doing it right."

Standard excuse of leftists and so-called Progressives to the failure of communist regimes everywhere, everytime.

Re:One problem: no normative definition of "Agile"

[Cytotoxic]

This is the nut of the problem. It always comes down to people, and the most productive teams are going to rub some people the wrong way because often times the most productive way of getting something done is to say "no".

I've worked with the "just give them what they ask for" crowd. It is just awful.

It works for a while. They are sooooo happy! You gave them that stupid thing that will never work in a million years! Then after a while, things are a mess and they still blame the dev team.

The only way that I've found to work with them is to have the backing of their superiors when you look them in the eye and tell them no. Anything less than the full backing from the top levels ends in disaster - methodology be damned.

This is why outsourcing can be so bad. You need the institutional knowledge that a good group of developers will have. And you need an executive team that has confidence in their developers so that when they push back against some dumb initiative they will have their backs.

I can't tell you how many times I've had near mutiny when I explained why something was stupid and had the CEO tell me to do it anyway, just to keep someone happy. No competent developer wants to waste his time building something he knows isn't going to work. But at least I was able to tell them that their concerns were heard and why they were dismissed. (and at least they knew I wasn't crazy, and their CEO wasn't crazy... or stupid)

Absent that connection, I don't know how things can work, long term. With good managers and executives, you could make outsourcing work. But eventually that guy who just doesn't get it is going to come along and insist on his vanity project. And the guys from India are just going to say "Ok, here's the bill". Maybe they fire the local PM when the whole things goes to crap. Or change development companies. But will they even be able to see that the problem was the idea behind the vanity project wasn't any good from the start? Often it is the dev team that is uniquiely positioned to know this, because they've had years of experience with all of the company's business rules and past mistakes.

So if there is no mechanism for continuity of business knowledge and no respect for that knowledge at the top.... well, I don't see how it could possibly succeed, long term.

Re:One problem: no normative definition of "Agile"

[Cytotoxic]

In fairness I've heard that about just about every management strategy I can think of.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

It's not an annoying thing about Agile. Anyone who says that means they are bad at managing/teaching/basic rhetoric, end of story. I'm not defending Agile here and saying it's great, but don't blame Agile.

Re:One problem: no normative definition of "Agile"

[swb]

Any sufficiently involved management system will be corrupted by managers to further their own narrow goals, which are usually personal enrichment and petty power.

It seems more likely when the management system is designed to "help" a class of employee be better. It provides great propaganda cover, early adopters may get the real thing and become evangelists for the system even after it has been turned into a system of oppression, limiting new and lower level employees from even complaining since the "rock stars" all promote it.

It would seem to have many parallels to utopian political systems. Sounds great on paper and the party pushes its loyalists' opinion, but at the end of the day it gets turned into a means of control and a way to maintain power by the elite.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

That was kind of my point.

If you have a terrible set of people and they do not want to talk about what they are doing. Then agile is a terrible thing to force on them. They will fuck it up anyway and on purpose usually.

I have seen agile work and fail. Almost always it is a failure to communicate or that somehow 'that part does not apply'. If you use agile you need to eventually do it all. All of the methods feed upon each other and expect you are doing the rest of it. If you skip bits you eventually fail. I saw one team decide 'fuck story points' and went with time. Eventually they became waterfall done with agile rituals. Another team I saw dragging in 80+ people per day for a 'standup'. Obviously that standup took an hour to finish every day. So they said 'oh we are wasting too much time' Then once a week. Then every other. Well that means no one cared so do not bother filling out the stories and saying 'here is what I am working on'.

Another org I have seen the teams call each other out when they are skipping things. It keeps the teams honest. If we all are doing this *you are too* no special snowflakes. Whoever is in charge of the team has to be on it all the time. It is easy to just say 'screw it'. They have not degenerated yet. But they are one manager away from it not happening anymore correctly.

I have used waterfall, agile, kanban, scrumm, pair. You name it. I am NOT going back to waterfall. That is the most fucked up thing. With pages and pages of detail plans that do not actually plan what you really are going to do. Agile types work better. Is it perfect? No, not really. But it is either that or spend months planing and then ignoring the plan anyway because 'shit happens'.

When it comes down to it these are just ways to have different styles of project managers. They work *if* you use them correctly. They are dead easy to screw up. Especially if your team communicates in a shit way.

Re:One problem: no normative definition of "Agile"

[angel'o'sphere]

"You're not doing it right" has become a mantra for explaining away any shortcomings ...
If something does not work, there are two options:
a) it can not work
b) it would work if done right: but you don't do it right ... shortcomings, of which there are more than a few.
So, which are the short comings of "agile" and which agile method do you refer to?

I always here the mantra that "agile" has shortcomings, but never anyone is able to point some out.

Re:One problem: no normative definition of "Agile"

[angel'o'sphere]

Sounds pretty like "agile" to me, and no one ever said a sprint should be 1 week. A sprint usually is 6 weeks to 3 month. Only hardcore agile teams that _do agile correctly_ can manage sprints shorter than 3 weeks.

Re:One problem: no normative definition of "Agile"

[Aighearach]

If you're doing it and have problems, you're doing it wrong.

Then if you're not doing it, and you tell them you're not doing it, but you don't have problems, they insist you're doing it.

Fuck that.

And news flash, there was no such thing as "old, pure waterfall." "Pure" waterfall is where an idiot reads a book about planning before building, and gets really confused and decides that since the book doesn't talk about mid-stream changes, they must be banned! And waterfall-book-guy, whatever his name was, came out later and reminded people, "it was never anything absolute, it was just a first version of the book" but they were all too busy patting themselves on the head to listen.

If you take the time to capture customer requirements at the start, and you did it poorly, that means you suck at capturing customer requirements! Starting work without even having attempted to do it well doesn't seem designed to address the shortcoming in any way. Would it help to know that not everybody sucks at capturing customer requirements? Or that if you suck at doing it at the start, you'll also suck at doing it by the seat or your pants?

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

no normative definition of "Agile"

Yes, there is. It's called the Agile Manifesto. Read it. Understand it.

If you do, you'll realize that all this 'Agile Coach' crap and SAFe silliness is the antithesis of Agile, not it's evolution.

The point of the Agile Manifesto is that organizations should focus more on getting the job done, on outcomes, and less on trying to bring structure and discipline and pedantry to efforts that are, by definition, unstructured, undisciplined, and vague.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

One addition to my above post...

Tech companies spend so much patting themselves on the back for hiring the best and the brightest, so why do you not trust those professionals to be self-managing? Why do you feel the best and the brightest need to be treated like minimum wage burger flippers?

If they are the best and the brightest, they should be given the room to be their best and brightest selves. Hence, the notion of the servant leader -- the person who's responsibility it is to enable, not control.

Re:One problem: no normative definition of "Agile"

[turbidostato]

"With good managers and executives, you could make outsourcing work"

That's an oxymoron, since "good managers and executives" would know outsourcing was a bad idea to start with. So almost by definition, you know they are bad managers and executives since they pushed for outsourcing (and that wouldn't be a surprise, since, see principle #1, "managers are morons").

Re:One problem: no normative definition of "Agile"

[MartinG]

From what you have said, it seem you are pretty much "doing agile" or at least following a number of the principles:

> customer can redirect our efforts - perhaps a priority changed, or it turns out the customer doesn't want something anymore

It seems like you value customer collaboration over contract negotiation and value responding to change over following a plan. That's covers half of the agile manifesto already.

The things you listed such as sprints/tasks are not agile concepts, but might be found in a scrum based process. My personal view is that scrum is not particularly agile when done how most folks seem to do it.

I have to say that builds that take a day sounds painful though. Isn't that painful enough that you want to do something about it?

Re:One problem: no normative definition of "Agile"

[sphealey]

= = = The "No True Scotsman" fallacy is one of the most annoying things about Agile. "You're not doing it right" has become a mantra for explaining away any shortcomings, of which there are more than a few. = = =

Yes, but of course the Waterfall and One True Spec adherents said exactly the same thing for 30 years in the face of evidence of failure rates over 50% as well. So perhaps there is no perfect method?

The wisdom of the industrial organization I once worked for that split any division that grew larger than ~ $100 million US/year into two divisions or product lines, each with an on-site and engaged general managers, appears greater to me as the years pass.

Re:One problem: no normative definition of "Agile"

[Maxo-Texas]

The biggest risk is doing the "easy" part first to "save time" while you try to solve the risky part. This results in huge sunk costs which drive the project forward even when it's obvious that the new risky thing will have performance problems or not even do what it promised at all.

Identify parts which may have performance impact or rely on new software or new features and address them before you start on the 80% of the work that is the 'easy' part. If you can't honestly give an estimate for some part of the work, or if starts sliding from that estimate immediately let that warn you that's a risky part that needs to be solved before you dump 50 million dollars worth of simple construction coding into a project. Failing to do that causes the most enormous failures (100+ million dollars).

Re:One problem: no normative definition of "Agile"

[Memnos]

Cross-cutting concerns, such as coherent error handling, logging (and metrics and alerting if you're more advanced), etc. do not produce visible benefit to the customer rapidly if they are done for a large-scale system. They get shunted aside

Management of technical debt gets relegated to secondary status because it's essentially invisible to someone not trained in software engineering.

User feature requests that are improperly curated (or not curated at all) lead to a system that has no coherent development evolution. Agile tends to be reactive, and tends not to be conducive to any vision of where the software should go.

Architecture, the stuff you wish you had done afterwards, gets short shrift.

Ready, fire, aim.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

+1. When "Agile" first came to our place in '05 I laughed and called it "normal development." Any work process that does not iterate is basically broken. You can't even make good pottery without iterating. Thankfully I am still here, and we still don't call normal software development by smarmy names. We just focus on the problem and the actual best solution.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

Basically what you describe are more or less the process of getting to agile for me.

Agile is to do the smartest solution to a problem once it's identified rather than to follow a list of things to do.
And I would say the most important part is to not waste time doing things that will not be used.

You do seem to have sort of sprints, in the bastard version of sprints they are deadlines, in the good version they are checkup on what different team members are doing, and the chance for other people to notice that someone else has problems and that they might help.

But the most important thing is to not get stuck planning. It's better to start build and build it wrong than to do nothing, it's usually a very good startingpoint for creating the product, and as soon as you have something to show, customer usually put the requirement list to the side or take upon themself to manage it moving the work of understanding it closer to the source.

Re:One problem: no normative definition of "Agile"

[bugs2squash]

First you have to define your enemy before he can define himself after all.

And besides, the process of agreeing a spec, meeting it in a cynical way and then arguing for more funds is the art of the deal.

Finally, Agile is fine, but is it vulnerable to someone high up saying "when will it be done to which the reply is "when will what be done" to which the reply is "whatever I was thinking about, I need a hard number now".

Re:One problem: no normative definition of "Agile"

[Hognoxious]

You need a formal process. Before something's developed there's an outline proposal[1] and then somebody - ideally a group - decides if it's worth going any further with.

But that looks like bureaucracy and overhead.

[1] Length commensurate with the magnitude of the changes. Say the shipping lists are sorted in product code order rather than assigned vehicle order and because of that loading takes longer and things get missed. Half a side of A4 might cover it.

Re:One problem: no normative definition of "Agile"

[Cytotoxic]

This guy gets it!

That is exactly the kind of scenario where a knowledgeable in-house IT staff will make a big difference. Because not only will they know that the guys on the loading dock need things organized by vehicle, they will know that the guys pulling stock need it in order by location - so they'll recommend two different versions of the same list on tablets with barcode scanners.

The guy in shipping wouldn't know or care about that. And the guy in fulfilment wouldn't know or care about the guy in shipping's issues.

But the IT guy would know that accounting really wants to keep track of inventory and needs to move items on the GL as soon as they are put in the truck. So they'll talk to accounting about automating that pull list onto a subledger.

Expert in-house staff is worth a lot more money than any perceived extra costs.

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

Why is Agile a moving target?

Isn't the clue in the name?

Re:One problem: no normative definition of "Agile"

[ath1901]

Yes! It is booth Straw Man and No True Scotsman.

Waterfall does not mean "capture requirements poorly and charge ahead blindly" and it isn't Agile if and only if it works.

It really bothers me that these kind of insights come so late. Obviously, different problems are best solved with different processes. If you're building a pacemaker, you do NOT wait for customer feedback. "So, how was your heart last week? Need any changes to it? ... Hello?"

Also, he does not address one of the major limitations of agile: The sprint. Not all problems can be broken down into 1-3 week jobs. I spent months working on a new model, probably not more than a few hundred lines long. Writing the first "version" took 2-3 days. Testing and proving it works as expected for thousands of test cases took months. Some of the tests revealed bugs in other parts of the system which was a nice unintended side effect.

  It was at no point "ready" before I could show with confidence that it worked with no unexpected side effects. I really don't see how that could be "sprintified". Agile seem to assume the task is easily dividable and the "atoms" are small and simple.

The best advice I ever read about design was along the lines of "Just do it. Try many methods. The more you think about it in any way, the more likely you are to come up with a solution". I think the same applies here.

There are good practices within TDD, XP, Agile, Waterfall etc and you should think about them and try the ones that MAY fit your project .

Re:One problem: no normative definition of "Agile"

[Anonymous Coward]

Adjectives have definitions, too. So do adverbs and articles. Besides, in this instance, "Agile" is short for "The Agile Development Process" or words to that effect.

Re:One problem: no normative definition of "Agile"

[angel'o'sphere]

Cross-cutting concerns, such as coherent error handling, logging (and metrics and alerting if you're more advanced), etc. do not produce visible benefit to the customer rapidly if they are done for a large-scale system. They get shunted aside
That has nothing to do with "agile". If you neglect this stuff, you would do it in any other development approach, too.

Management of technical debt gets relegated to secondary status because it's essentially invisible to someone not trained in software engineering.
Actually agile methods emphasize to have zero technical dept. If you neglect this stuff, you would do it in any other development approach, too.

User feature requests that are improperly curated (or not curated at all) lead to a system that has no coherent development evolution.
If that is happeneing: you are doing ti wrong. And you would do it wrong in any other development approach, too.

Agile tends to be reactive, and tends not to be conducive to any vision of where the software should go.
That has nothing to do with "agile". If you neglect this stuff, you would do it in any other development approach, too.

Architecture, the stuff you wish you had done afterwards, gets short shrift.
Never happened in a project I was involved.

Re:One problem: no normative definition of "Agile"

[The Cynical Critic]

Isn't everything just that?

I mean the goal of managers in software development is to produce as much well tested high quality code for as little as possible. What you're describing is pretty much the natural end result of managers going overboard on any software development methodology, agile or not. Hell, I'd argue that whenever that happens it's not even the agile methodology they've chosen that's to blame, but rather just the fact they've just been over-eager to produce as much as possible with as little as possible. Agile is just the way they've chosen to try to drive their developers to the breaking point.

Re:One problem: no normative definition of "Agile"

[Hognoxious]

If you take the time to capture customer requirements at the start, and you did it poorly, that means you suck at capturing customer requirements!

Right. It totally isn't possible that the customer sucks at describing them.

Leaving aside the fact that it's possible for requirements to change for reasons outside the control of anyone involved in the project - and the longer the delay the more chance there is for that to happen.

Re:One problem: no normative definition of "Agile"

[Hognoxious]

LOL, I nearly put that about having it in two formats, but I thought I'd keep it short.

Nobody had asked the guys on the loading dock what they wanted. You know why? Because it's bloody cold out there, that's why.

My example was roughly based on a true story, before tablets were even a thing, and in a place not famous for its pleasant climate. I wasn't in-house, but I'm pretty good at imagining what I would want if I was doing the job.

Re:One problem: no normative definition of "Agile"

[DarthVain]

From my own perspective it sort of goes something like this:

There is a requirement. You do the requirement, however on testing you discover a problem. The problem isn't a technical one. The thing you designed does exactly what it is designed to do. However there is an issue with the data that is related to how it is collected or entered, or inconsistent business practices. The ability to correct any of those 3 things (other than to point it out) is usually about zero. The net result being however is that the piece you just designed, while it works how you design it to, delivers results that are less than optimal. You can't drop it because it is something the business wants. You then alter the design to at least make it work a bit better given the limitations, but it will always function imperfectly. Over time as the data gets worse, so does the design until eventually it is broken to the point that no one uses it anymore. At which point they'll ask you to "fix" it...

I once had someone tell me from the business "you work for me, not the other way around", the gist being you make changes to your systems to accommodate our business process, we don't change our business processes to accommodate your systems. It is that attitude, not Agile or anything else that causes problems. It today's technological world if you want to modernize your business properly it really is a two way street. Doing one without thought of the other will only give you a system with fundamental problems that while it might be OK in the short term, will eventually catch up to you and cost you more in the long run.

Re:One problem: no normative definition of "Agile"

[DarthVain]

This.

I recall first going to Agile training, the definitions of "Waterfall" and "Agile", and thinking that well I guess I've never really done true Waterfall, and that a great deal of the stuff in Agile we do as a matter of course anyway.

I don't think I've ever collected requirements, and then not gone back to the users to further refine them. I also don't think we've ever developed something without a lot of back and forth until we got something right. We also routinely prioritize requirements, and do phased deployments... But again all of that was well before I heard anything about Agile. We'd have regular meetings with PM, Devs, and staff, but again not daily scrums and sprints, and all that nonsense. Anyway I think far too many people get wrapped up in the Agile buzz and methodology without really understanding the purpose of it all, thinking if they blindly follow a bunch of rules that they will have better outcomes...

Re:One problem: no normative definition of "Agile"

[Aighearach]

First you have to define your enemy before he can define himself after all.

That's pretty stupid. I mean, seriously.

You're basically claiming to be a troll, and I can just stop my analysis there.

Re:One problem: no normative definition of "Agile"

[Aighearach]

Yeah, if it is a guarantee that the customer sucks at describing their problems, the problem for the developer isn't the process being used, it is the low quality of the work.

And lets be real; customers who don't know what they want are just making crappy websites, and red or green, rounded corners or a little more rounded, it doesn't fucking matter anyways. That's the kind of shit that benefits, not actual useful features. If you don't know what your useful features are, you don't even have a business plan. Probably no investors. Probably the client can't even afford to pay out the estimated amount of the project, which is why they agreed to a weekly dev model in the first place.

The idea that in "waterfall" the requirements can't change when there are actual reasons for change is just a straw man; a version of "waterfall" that relies on misunderstanding the first edition of the book and adding in a bunch of absolutes that were never implied, simply because that first version of the book didn't include explicit steps for it; they simply presumed that if requirements change, a human takes a look at it and alters things ad-hoc depending on the realities of the situation.

The idea that assessing requirements at the start somehow positions you to be opposed to changes is just vapid bullshit with no logical basis.

When the customer has real requirements and the developer accuses the customer of not describing them well, it is usually just that the developer is an insufferable neckbeard who failed to recognize his responsibility to understand the use case and translate the requirements from business English. Often they even saw their mistake, but put their nose up in the air and intentionally got it wrong in order to try to emphasize through a passive-aggressive attack that the customer is non-technical; often they're so insufferable they don't even understand that their behavior is basically fraudulent.

Re:One problem: no normative definition of "Agile"

[Cytotoxic]

late to your response, but I hope someone sees this anyway...

This is precisely the attitude that causes failure. People view IT as a service and a cost, separate from the business. This is the way to failure.

IT is not separate from the business, any more than sales, accounting, finance, manufacturing... it is all a team. Anyone who doesn't get that is an anchor dragging the company down. Unfortunately, lots of people still don't get this.

I have been in a situation where I loudly preached integration to both my employees and to the business unit. And it worked great. We all sell widgets. This guy might do it on the phone with customers, that guy does it by editing the contracts, and my team does it by building business systems. It worked great. We all fought for the best way of accomplishing the goal of selling widgets.

I've also been in the situation where people think "I work for them", as you say. My team of highly experienced technical people are merely service providers, competing with outsourced development teams on price and "customer satisfaction". That was a disaster. That attitude leads to a world where some sales manager is now the "IT Expert" who is going to design how the systems should work and look. You end up with something that is the equivalent of a skyscraper built out of cardboard but with a lovely gold-leaf façade. And productivity plummets.

They got rid of an IT team that had more experience and knowledge of the industry than anyone in the business unit. A team that could tell them "that didn't work when we tried it 10 years ago, and here is why". All because they enjoyed having a relationship with IT that went "I ask, they build".

They were pretty happy with themselves. They built a system based on a "workflow" tool, so they could make changes themselves. The custom screens we built for the prior system that predicted exactly what an employee needed to be doing and presented exactly what they needed to accomplish the task were gone. The automated call routing based on exactly who among 7 or 8 different groups needed to speak with the customer was gone. The outbound predictive dialing based on dozens of criteria across multiple job functions... gone. The automation of all activity onto the accounting subledger and then to the GL...gone.

But they did get "wizards" that helped with training. So instead of having one screen specific to the task that presented exactly what information was needed and exactly what should be collected, they got 8 or 15 screens in a script that walked them through collecting the data. So if they just needed to add a birthday to a person's file, they had to step through 15 screens, instead of just one screen with the missing fields prominently displayed.

I don't know if they ever figured out that productivity had plummeted because of their choices. I don't think they ever connected the fact that they had to hire almost twice as many support staff under the new IT system with the fact that they deployed the new IT system. Managers were happy because they had control, and nobody to tell them "we tried it that way before, it doesn't work because of X". They just said "Ok, here's your work order to sign off on".

The way to run a business properly is to realize that everyone is a part of a team that is pushing for the same goal. This view values the input of the clerk, the shipping guy, the accountant, the IT guys, everyone. A good IT department is where this attitude lives, because they touch every aspect of the business.

A senior executive can discount the impact of lots of jobs. The IT business systems team can't. They need to know exactly what that staff accountant does. They need to know what that clerk does with the file that ends up on her desk. You can't handwave away a part of the business when you are building the systems that people will use. It doesn't work like that. You have to know all of the steps. So an intelligent executive will highly value his IT team's expertise and input, because they will likely know more details about the overall business than anyone else in the building.

Re:One problem: no normative definition of "Agile"

[DarthVain]

Yeah I've had the conversation before with little effect. Sometimes you can catch it early, and can say, we can build this thing for you, however it ain't gonna solve all your problems. The problems being the business rules, lack thereof, or inability or unwillingness to enforce business rule compliance.

You can typically built in exceptions to your system, even exceptions to exceptions etc, however eventually it is just a mess and unmaintainable. Alternatively you can build in what is typically oft referred to positively as "flexibility", but what it really means is the rules are so lacking that it is just the wild west so do whatever you like. Then the business will make changes to whatever rules they have every couple years to compound both the issues above...

Bottom line by definition a "system" is simply a set of rules... Remove the rules, and it isn't so much of a system anymore. Particularly when the business is trying to "automate", and you have to tell them that you need actual rules in order to automate anything. Anyway we always seem to end of being reactive to change rather than the other way around which is part of the problem...

Anyway having been around long enough I realize the other point of view also. While sometimes the rules are a mess just due to time and change, in many cases there is a reason for why that is the case, and why it hasn't ever changed, and to do so would be a "very big deal"... In such cases you really need a management group that is willing to take risks, but many are adverse to do so. Most would rather pay for the broken system, say productivity has increased by X percent, get their bonus, shake some hands and congratulate everyone on a mission accomplished, then jump ship and be long gone by the time the proverbial hits the fan as time goes on and things start shaking apart... Then the cycle starts anew... Keeps you busy and employed, but makes it tough on front line staff who have to use the system and get frustrating trying to just get stuff done... Don't know how many times I've said, well that is the way it was designed to work... To which the response is usually "that's stupid", and in many cases I couldn't really disagree...

Re:One problem: no normative definition of "Agile"

[Cytotoxic]

For anyone following along, I saw the perfect answer to this once. Only once. But it was a cool way of doing things.

These guys were starting a business from the ground up. In this case it was a mortgage business. So they went out and found the best of breed software for doing mortgages and designed all of their business processes around how the software works, figuring that many decades of experience across many dozens of companies was packed into that software.

So they did the whole thing "out of the box". Sales, accounting, finance, you name it. No customization costs. No clashes of ill-thought-out business rules. They even bought their telephone system based on the recommendation of their software vendor. So all of the integrations were ready to go right out of the box.

They were able to build and grow their business amazingly fast because of that decision. They told me that it saved them immeasurably in the "growing pains" that a startup would usually have.

It isn't a solution that is available to everyone, but if there is a best of breed ERP or CRM for your business, maybe that's the way to go.

Betteridge's law

[rsilvergun]

No. What make agile work is accountability. The agile shops I've seen have what's basically a case system that tracks User Stories which describe small amounts of work. That's used to manage the teams and make sure they're move forward to some definite goal. That's the reason agile works. You can keep tabs on what your devs are doing and if they go off the rails fix it in 1 sprint.

Re:Betteridge's law

[murdocj]

And yet, you can do lots and lots of stories, and in the end you have a big steaming pile, because the stories don't add up to anything. I recently worked on a product like that. There was one "feature" that I backtracked to about 8 different stories, each of which incrementally added a sub-feature that, ON ITS OWN, sounded like a good idea. But the sum total was almost impossible to understand, and I'm sure people blamed the devs, not the managers who insisted on the "stories".

Re:Betteridge's law

[Anonymous Coward]

The large data logging project I worked, they did all the small tasks first. These were all rendering tasks, new ways of visualizing a screen worth of data, new colour rendering modes, magnification modes. They more or less added features as they went along - no formal specification. After eighteen months they suddenly decide that they need to add a history feature going back hours, not just a few minutes. *Everything* at the core data level had to be redesigned and all the visualization tasks had to be rewritten to account for this. This was the one thing they should have implemented first.

This seems to be the big problem with Agile run projects. The idea of a "framework" or some organization of the code to make adding functionality easy isn't bothered with. Engineers just add stuff willy-nilly, working around each others imposed design constraints and working around the other workarounds.

Then management wants to "see progress" made in days not weeks. So it's a matter of doing the least number of tasks first that will get some eye candy up on the screen, then going back and actually getting it working in the first place in the next task.

Re:Betteridge's law

[Anonymous Coward]

No. What make agile work is accountability. The agile shops I've seen have what's basically a case system that tracks User Stories which describe small amounts of work. That's used to manage the teams and make sure they're move forward to some definite goal. That's the reason agile works. You can keep tabs on what your devs are doing and if they go off the rails fix it in 1 sprint.

I've not seen agile, or the various renaming of it where I work be a game changer.

The attitude of other employees who use the code seems to be mostly one of not caring about the code beyond whether or not it will allow them to do their job in an acceptable way, by some fairly low definition of acceptable. Sure they wouldn't mind it being better, but getting them to tell us how, in detail, it could be better is difficult, so at best you end up guessing and trying to improve things as best you can, which, as you can guess will get you in trouble for being disruptive or doing unassigned tasks.

So much goes back to requirements and feedback. In short you need involved customers, and while they are not impossible to find where I work, they are, nonetheless difficult to find. Agile isn't the problem or the solution, though it can help work around the problem by iterating your way to something better, though again there is no shortcut to involved users. The other thing I'd like is in cases where feedback is minimal, but the work has to be done, is more trust from management. I'll figure every missing detail out given enough time. Sure some of them are going to be unneeded, and some will even be wrong, but that is where at least token customer feedback is essential. In short don't drop a job with no requirements to speak of on my plate, say make it better, then complain when I do something you didn't say not to do in the first place.

Re:Betteridge's law

[Anonymous Coward]

No. What make agile work is accountability. The agile shops I've seen have what's basically a case system that tracks User Stories which describe small amounts of work. That's used to manage the teams and make sure they're move forward to some definite goal. That's the reason agile works. You can keep tabs on what your devs are doing and if they go off the rails fix it in 1 sprint.

Agile != accountability

You don't need agile to keep tabs on what developers are doing.

Re:Betteridge's law

[cruff]

Supposedly that is what a software architect should be doing, the high level design, outside of the pressure of the agile sprints. Ideally then you have a roadmap to where things need to go, with an initial set of stories defined for the sprints. Yeah, that doesn't seem to happen where I work either.

Re:Betteridge's law

[HornWumpus]

You've got agile confused with scrum or some other 'greased hog fuck' methodology.

Re:Betteridge's law

[phantomfive]

Agile (more specifically, scrum and derivatives) is a tool managers use to keep programmers on task, and to get them to work harder. In that way, it begins from a position of lack of trust, you use it because you don't trust the developers to take care of things.

Ultimately that is the opposite of Agile, which says, "We value individuals and interactions over processes and people." If you don't trust your developers, the focus should be on improving the skill of your developers so you can trust them. The best agile methods focus on improving the soft skills of the programmers, rather then beating them down or 'controlling' them with process.

Re:Betteridge's law

[Anonymous Coward]

As a counterpoint, and I say this as someone who is decidedly anti-agile in practice (although pro-agile in theory), I've seen far more instances where someone built a framework or a baseline or some piping that ended up an over-complicated, over-generalized pet project to the detriment of actually building the damn product than I have instances where a framework would have been preferable where one was not used. I know the opposite happens (and you have a great example), but usually it's the other way around: too much piping with generalized features that no one will ever use. Programmers, even experienced ones, want to think they're building the fucking STL.

Re:Betteridge's law

[HornWumpus]

Trustworthiness and skill are orthogonal.

If you improve the 'skill' of an untrustworthy person, all you get is a better liar.

There aren't many issues that aren't fixable in a team member. Complete loss of trust is one of them.

Re:Betteridge's law

[alvinrod]

Too often agile skips (argue that this is doing it wrong all you like, it's often reality) trying to do an extensive requirements analysis to nail things down to the point where you can do a high-level design that will be useful for more than two sprints. The real failure is probably that no one really wants to do the hard bits first, so those tend to get left until too late into the development process and invariably lead to throwing out or seriously reworking a lot of the earlier effort that failed to account for something important.

Re:Betteridge's law

[Anonymous Coward]

Probably the realist shit in this thread. He's just saying what all the programmers in this thread that have been a part of an agile team are thinking.

Re:Betteridge's law

[HornWumpus]

Again. Scrum not agile. Even your language is scrummy.

Re:Betteridge's law

[phantomfive]

Trustworthiness and skill are orthogonal.

ok, you completely misunderstood or you are trolling. Examples.

1)A person doesn't know how to write Javascript or CSS. Can you trust this person to finish the frontend featureset by next week? No, you can't.

2)A person doesn't have good estimation skills. Can you trust this person to estimate when they will finish? No, you can't. Another example:

3)A person has finished their work within the estimate every sprint for the last six months. Can you trust this person to correctly estimate when they will finish? Yes, you can.

So.... What is the difference between the second and third example? One of them has skill in estimation, and the other doesn't. That's it. So teach that person how to estimate. There are ways to do that.

Re:Betteridge's law

[murdocj]

Ideally, yes. My first 20 or so years as a dev I worked in environments where we were "self-organizing" but we weren't delivering small increments. Instead we have fairly long term goals (usually for a yearly release) and then each dev or small group of devs figured out how to get it done. And amazingly enough the work got done and the product was coherent.

Since I've started working in Agile groups for a number of years the development has been way more subject to "here's a feature that can be added in two weeks, let's go for it" w/o a coherent overall view of where we were headed. And this is at 3 separate companies.

Agile (whether Scrum, Extreme Programming, whatever) just seems to be one of those things that sounds good, that has some good ideas, but ultimately comes with its own set of problems. As Fred Brooks said, there's no silver bullet.

Re:Betteridge's law

[Anonymous Coward]

On the one hand, yes, user stories are the right way to do agile.

On the other hand....it's still hard to do right.

There is *always* a rift of understanding. You and the developer are in the same room talking through a feature set, talking about the business needs and user experience, speaking the same language.....and the two of you STILL come away from the meeting with a different understanding of what was just discussed. It always happens, the only question is the degree.

You can't fix this by putting ever more acceptance criteria into the user stories. That effort never ends and it makes the user story into an unreadable novel. Nor can you fix this with even more upfront conversation, as that immediately devolves into a low-level waterfall-style design session which only serves to create even more details that are subsequently misunderstood between the two parties.

The only way to address this, the *only* way, is to keep checking in. Daily demos, and course corrections. It costs time and effort, but it is the only way that actually works.
 

Re: Betteridge's law

[Anonymous Coward]

See if you're writing a group of stories without an epic then it's most likely to fail. You'll need grooming sessions and other long term planning methods to ensure you have a long term vision and then break them down into smaller stories not the other way round.

Of course, maybe scrum is not for your team

Re:Betteridge's law

[HornWumpus]

Trust is trust. Unqualified, it is far larger than your use...Fair enough, I misunderstood.

Your on about: 'trust your developers time estimates.' related 'trust your developers designs' 'trust your developers code quality' etc etc. Actual tech lead/architect agile project manager considerations. That all starts after you decide to basically 'trust' him.

But those things are only really available to technical people. Schedules get blown all the time, even by good devs. Sometimes it's because the design was broken or problem misunderstood, and nobody sees it until dev or test. 'Meets schedule' always has 'buts'. Takes a coder to know an excuse from a 'holy shit, we must refactor' moment. The guy that spots the bad design first is worth gold BTW. That hypothetical 'failure to meet schedule' is a huge positive, saved everybody's ass.

The PHB can't tell the difference, so he likes scrum. Puts all the things he doesn't understand into nice tidy boxes, where he can pretend. Of course he doesn't trust geeks. Thinks they're overpaid and featherbedding, senior ones too. (He's not always wrong.) Your job is to 'manage up' the PHB. It's inescapable, there are mythical places with no PHBs, but I've never seen one. You've got to keep him out of the standups, or you are doomed.

Your people may be wrong, but they shouldn't be lying, trying to bleed you for a check (until you realize how useless they are) or transparently trying to game the system. That's 'can't trust them to take care of things' IMHO. If they're good, they'll fill any technical gaps, quick enough, if you just leave a little slack in their schedule.

I can actually respect either lying (some understandable, 'wine, women and song' cases) or gaming the system, when done well, but 'expect marketing responsibilities in your future'. Showing an avocation. Might try and fix the game, might take up the gaming myself. Not above it or bad at it. It's transparent gaming that bothers me, implies they think we're stupid.

Re:Betteridge's law

[phantomfive]

ok, so you are describing a disfunctional organization. Not the kind of place I like to work.

Re:Betteridge's law

[Anonymous Coward]

Just look at how much good it has done to provide feedback to Microsoft for Windows 10 the last few years...

R O

Re:Betteridge's law

[greenwow]

> get them to work harder.

That's what it's all about. When you have one or two scrum meetings a day where you have to talk about what you accomplished since the last meeting and what you commit to before the next meeting, of course you have to work hard. We do two scrum meetings a day during the week, 9am and 8pm, and one at noon on Saturdays and Sundays. People don't think long-term or about quality. All they care about is getting their code reviews done and being able to merge before the next meeting.

Re:Betteridge's law

[Dutch Gun]

From what I've seen, my entire industry (videogames) has more or less adopted agile/scrum, and it's not really a bad thing. Frequent short stand-up meetings can be useful, although the idea that you CAN'T sit down seems childish to me. In my current job, we cluster around hallway whiteboards, so I don't mind that so much. If you're forcing everyone to stand when there are chairs in the area, it just feels silly. You should be able to gently enforce time rules without that.

The language regarding "user stories" and "sprints" is also seems a bit silly to me in its rigid adherence. But I'll admit it does help to focus on who the "customer" is, and forces the developer to deliver reasonable progress at reasonable milestones, something that should occur in any sane system. It really doesn't have to be agile/scrum, but it seems like that's what we have, so it's the framework we use.

Generally speaking, I'd say the one benefit agile tends to bring is that it officially discourages developers from hunkering down into a huge project and simply "going dark" for a year, at least if done correct. Those types of going dark periods often don't end well. I've always thought that was common sense anyhow, but it's probably better for leads and producers to be able get a bit more visibility into those sorts of projects.

Like all methodologies, it's not going to turn a dysfunctional institution into a well-performing machine, while it will probably just help an otherwise competent team to stay on top of their project a little better. You can even see it failing in one department and working well in others, even in the same organization. In a sense, it's sort of like coding standards. It's far better to have a coherent coding standard, regardless of which arbitrary stylistic decisions it may make, just to keep the code looking like it's all part of the same system.

I think the arguments that they can't help the overall vision of a problem is fundamentally correct, but it's a bit misplaced to blame that on agile. In my opinion, NO system or methodology can polish a turn. Getting your developers behind the project vision and sticking to tasks that help reinforce that singular vision is up to the team leadership. If that doesn't happen, then, simply put, it's a massive leadership failing, and no "system" will fix that.

Re:Betteridge's law

[Anonymous Coward]

That's what it's all about. When you have one or two scrum meetings a day where you have to talk about what you accomplished since the last meeting and what you commit to before the next meeting, of course you have to work hard. We do two scrum meetings a day during the week, 9am and 8pm, and one at noon on Saturdays and Sundays. People don't think long-term or about quality. All they care about is getting their code reviews done and being able to merge before the next meeting.

What the hell kind of slave galley do you work on that has a schedule like that?

Re:Betteridge's law

[Idimmu Xul]

mm not really, it has more to do with successful delivery than lack of trust.

on one end of the spectrum you can formally spec out the entire system and wait a lifetime to get something that doesnt do what you want, using the waterfall model, due to too much involvement

on the other end of the spectrum you can describe what you want to the developers over a beer in the pub and wait a lifetime to get something that doesn't do what you want because of a lack of involvement

scrum/agile should be the lesser of both evils, 'hey, this week can you create the signup and onboarding flow, and login and forgot password please' where you break the big picture down in to meaningful deliverables you can iterate on to demonstrate constant progress to the stakeholders.

if it devolves to 'working harder' that means the entire team is unable to make correct time estimates or worse, is ok with being unable to make realistic time estimates.

sure there are some trust issues, the longer you leave it between deliveries or meeting your development team the more time there is at hand for things to go wrong, specifications to be misunderstood etc

you want to hire a development team to work on your project, pay them $30kpm and show up 12 months later asking why nothing has been done, by all means go for it

Re:Betteridge's law

[Tough Love]

What is the difference between the second and third example? One of them has skill in estimation, and the other doesn't. That's it.

More likely, the 3rd one was just checking in white space. Works like a charm, seen it with my own eyes, people like you get fooled every time.

Re:Betteridge's law

[phantomfive]

on one end of the spectrum you can formally spec out the entire system and wait a lifetime to get something that doesnt do what you want, using the waterfall model, due to too much involvement on the other end of the spectrum you can describe what you want to the developers over a beer in the pub and wait a lifetime to get something that doesn't do what you want because of a lack of involvement scrum/agile should be the lesser of both evils, 'hey, this week can you create the signup and onboarding flow, and login and forgot password please' where you break the big picture down in to meaningful deliverables you can iterate on to demonstrate constant progress to the stakeholders.

This can be done merely by having shorter release cycles. No need to do all of scrum.

if it devolves to 'working harder' that means the entire team is unable to make correct time estimates or worse, is ok with being unable to make realistic time estimates.

That indeed is a symptom of the problem.

Re: Betteridge's law

[getuid()]

No, that's pretty much average as (dis)functionality goes. Every organisation beyond 3 people will have tendencies towards all kind of evil distractions and unconstructive, personal side-priorities.

The trick is to find a collective, self-correcting state of mind, process etc, to keep them from escalating and degenerating the organisation's core task.

Re: Betteridge's law

[phantomfive]

God

Re:Betteridge's law

[mvdwege]

Generally speaking, I'd say the one benefit agile tends to bring is that it officially discourages developers from hunkering down into a huge project and simply "going dark" for a year, at least if done correct. Those types of going dark periods often don't end well. I've always thought that was common sense anyhow, but it's probably better for leads and producers to be able get a bit more visibility into those sorts of projects.

That's because most programmers and most managers seem to think in terms of 'product': "We want this application, and we need it done by X". Instead, programming should be about data flow: what information flows into a process, and what information does the organisation want out of that input?

I've seen developers up close, and sometimes their singular devotion to "i want to improve my application/my code" at the expense of "what does the end customer need" really needs to be managed.

A close engagement with the end user, and incremental development can help fine tune a better vision on the data flow and necessary transformation, but if no-one from the management team on down focuses on the reason we have developers in the first place, you get a dysfunctional organisation, where management does not trust the devs and uses 'Agile' to micromanage them, and devs start treating their slices of code as their private fiefdoms instead of watching the big picture.

Re:Betteridge's law

[Anonymous Coward]

So teach that person how to estimate.

Or don't.
If the persons only shortcoming is being bad at estimates then someone else could easily do the estimate for him.
Heck, a good manager could probably make a good enough estimate by asking what the task entails and count the number of words together with pauses and "uhm.."s

Re:Betteridge's law

[Anonymous Coward]

Even better, have the project manager talk with the customer every now and then.
Regardless of development method the project manager knows where things are heading and what the end result will be.

When you run agile it is way to tempting to let the customer bring requests directly to the developer.
Don't let that happen, it screws up the entire project regardless of method used.

Re:Betteridge's law

[Anonymous Coward]

As the original anonymous coward, I know what you mean. Some programmers will go around writing that mega-API with hundreds of getter/setters, base classes, super-base classes, meta-pure-virtual classes, and hyper-containers just to implement an address book list. In the old days, we just had a requirements specification.

Re: Betteridge's law

[MadKeithV]

The parent post is a great example of the "You're Not Doing It Right" fallback of Agilists. Agile is something that works in teams that would have succeeded just as well with any other methodology that isn't downright insane, and something that is pretty damn difficult to actually get to work in most real-world situations. There's always a litany of excuses of how you're not doing it right, but no Agile proponent can ever quite exactly say how to make sure you *do* get it right either.

Re:Betteridge's law

[AmiMoJo]

Another common flaw is that the stakeholders don't understand why certain things are so much effort to implement, so get upset when they propose something and you tell them it will take six months to do. They get used to the idea that they can request changes and features but all that does is encourage quick fixes and huge amounts of technical debt.

I find it's usually better to build a really solid foundation first, and then start getting users involved with prototypes. You also have to put your foot down sometimes or push hard for the users to change their habits and workflow when there are major advantages to doing so.

Agile may be suited to some types of development... Maybe mobile apps or web apps, but not so much platforms that are expected to exist for a decade or more and grow along the way, or where high reliability is important, or where it's not just software but also hardware that is much harder to change.

Re:Betteridge's law

[Anonymous Coward]

With a schedule like that, I guarantee they're only thinking about not being at work.

Re: Betteridge's law

[Anonymous Coward]

He works in an AGILE slave gallery, of course.

Re: Betteridge's law

[Anonymous Coward]

"I've seen developers up close" - so you're an imperialist PHB who imposes "Agile" by force to deskill, demoralize, and disenfranchise the programmers under your rule.

Re: Betteridge's law

[murdocj]

Except that the Agile Manifesto specifically says that it values "Responding to change over following a plan". Which tends to lead people to simply not plan at all. At my last company, my boss tried to plan, tried to groom, etc, but it all got thrown out the window then company owner zig-zagged. So we were "responding to change" but the end result was pretty random development.

Re: Betteridge's law

[murdocj]

I wish I had mod points to mod the parent up... absolutely correct. The "you aren't doing Agile right" argument is old and tired and just plain wrong.

Re:Betteridge's law

[angel'o'sphere]

And yet, you can do lots and lots of stories, and in the end you have a big steaming pile, because the stories don't add up to anything. This is not a problem of "agile" but bad requirements engineering (business analysis) and specifications.

Re:Betteridge's law

[angel'o'sphere]

Since I've started working in Agile groups for a number of years the development has been way more subject to "here's a feature that can be added in two weeks, let's go for it" w/o a coherent overall view of where we were headed.
If you have no coherent over all view: then you are not doing software development right Regardless if you, your team or your company labels something with "agile" or "not agile"
When you can not even do software development right, why do you think going for "agile" would be an improvement?

Re: Betteridge's law

[angel'o'sphere]

"you aren't doing Agile right" argument is old and tired and just plain wrong.
No it is not wrong. You are wrong.
Ever tried to cut a soft cake with the dull side of the knife? Works surprisingly well, but is wrong. Try the same thing with a salami, but don't make the mistake to push with you other hand down on the blade of the knife.
Point is: it does not work to cut the salami with the dull side of the blade. You are doing it wrong, your holding the knife wrong.
However it is an excellent variation of holding the knife if you want to stab one to death. Much more effective if the cutting edge is on the upper side.

If your software development method is not working: you do it wrong! Regardless what kind of method you use. First: learn how to develop software. Then: pick a process/method that works for you.

If you can not do Scrum or XP: then you can not develop software, period. It is not the method but your immaturity in making software that makes you fail.

Re:Betteridge's law

[angel'o'sphere]

Maybe mobile apps or web apps, but not so much platforms that are expected to exist for a decade or more and grow along the way, or where high reliability is important,
That is nonsense. The "niche" of choice is completely irrelevant.

or where it's not just software but also hardware that is much harder to change.
The origins of Kanban come from a hardware company: Toyota!

Re:Betteridge's law

[angel'o'sphere]

I guess you got Scrum wrong.
In Scrum, there is basically no manager, the team is self managing. That is more or less true for all agile methods.

Ultimately that is the opposite of Agile, which says, "We value individuals and interactions over processes and people." If you don't trust your developers, the focus should be on improving the skill of your developers so you can trust them. The best agile methods focus on improving the soft skills of the programmers, rather then beating them down or 'controlling' them with process
That is exactly what Scrum and XP are doing.

Re:Betteridge's law

[AmiMoJo]

Kanban is for manufacturing though. I mean you can't keep refining and iterating your electronic designs. You would end up with many versions in the field, many versions to support. Your firmware would need to support it all too.

Re:Betteridge's law

[Aighearach]

No. What make agile work is accountability.

I agree. Anybody that attempts to adopt development methodologies as a mandate must be held accountable, immediately.

Re:Betteridge's law

[sfcat]

Generally speaking, I'd say the one benefit agile tends to bring is that it officially discourages developers from hunkering down into a huge project and simply "going dark" for a year, at least if done correct. Those types of going dark periods often don't end well. I've always thought that was common sense anyhow, but it's probably better for leads and producers to be able get a bit more visibility into those sorts of projects.

Your teams probably do very easy work (oh right, videogames). To do really difficult designs and very fast/efficient implementations, "going dark" is the only way I've ever seen it work. I seriously doubt anything of any real difficulty has ever been implemented by almost anybody without "going dark". Even in bad hacking movies, this is how it works. You don't fatten a hog by weighting it (old educational aphorism). And what's in your manager's head, rarely has any resemblance to reality. Code is reality when delivering software, everything else is BS.

Re: Betteridge's law

[mvdwege]

No, I'm a sysadmin who has to deploy the shit some coders deliver and deal with the unhappy users. But thank you for playing, shithead.

Re:Betteridge's law

[phantomfive]

I guess you got Scrum wrong. In Scrum, there is basically no manager

You still have a manager.

Re:Betteridge's law

[angel'o'sphere]

Not for the software development teams ... what exactly would s/he manage?

Re:Betteridge's law

[angel'o'sphere]

Kanban is actually a very strong movement in software development, too.

You would end up with many versions in the field, many versions to support. Your firmware would need to support it all too. Yes, and that is what everyone is doing, ever looked at a camera or phone vendor? Or a car manufacturer for that matter?

Re:Betteridge's law

[phantomfive]

Oh yeah? What company are you working for that doesn't have a manager? If your team decides to goof off, and not do any work for a few months, what will happen?

Re:Betteridge's law

[angel'o'sphere]

Managers are on a much higher level. They don't manage teams.

If your team decides to goof off, and not do any work for a few months, what will happen?
They get no money. The projects are stuck, the manager hires new teams if he thinks that is the right thing. Was has that to do with managing software development? Nothing.

Re:Betteridge's law

[phantomfive]

ok, so you do have a manager. Glad we clarified.

Re:Betteridge's law

[Xenocrates]

Yes. A phone or camera vendor has a finite number of variations, usually related to various regions a model might be released in. A car manufacturer, other than Tesla, will build the same trim of car to the same design for pretty much an entire year. It simplifies service, since these are durable goods that cannot just be replaced. How the parts get put together or made may change. But they may start out with different factories doing it different ways due to different floor plans, and not change for the year.

Kanban is about largely optimizing the process, not changing the product. That's something that AniMoJo got wrong. But you proved you don't understand it either with your response. You optimize stock, tools, ordering time, assembly order, packaging, machining strategies, etc. But the print you build the part to should not change.

You also seem to have a strong interest in saying that anyone criticizing Agile is wrong, while saying anyone who listens to clients or adapts to changing circumstances is essentially doing Agile. If that's Agile, then of course it will only result in success, since you've disqualified all failures, and most people don't actually need to pay any attention to Agile coaches or manifestos, since basic common sense and customer service handle the most important parts of it.

Re: Betteridge's law

[Anonymous Coward]

You're an idiot.

Re:Betteridge's law

[Anonymous Coward]

Kanban/LEAN is what I prefer to use. Assign work until I run out of available resources, let the business partners shuffle the backlog however they want and next available resource gets top of the stack. Once out of backlog, though, we work the ask until it is completed or cancelled, no shifting of something "higher priority" into the work stream (unless mandated by law changes or production defects).

I've seen too many times in Agile/Sprint teams where there were artificial decomposition of work simply to fit it in the timebox and work tasks being ordered badly simply to have a demo at the end of 2 weeks.

And now we have the wonderful SAFe version where all the people in the layers above the development teams now are trying to control the development process.

Re:Betteridge's law

[angel'o'sphere]

You also seem to have a strong interest in saying that anyone criticizing Agile is wrong
Nope. You can criticizes what ever you want. However claiming you do an agile process, then telling us, what you are doing and nothing of that has anything to do with agile and then telling us it fails and then blaming agile: that makes no sense.

and most people don't actually need to pay any attention to Agile coaches or manifestos, since basic common sense and customer service handle the most important parts of it.
Exactly!

But you proved you don't understand it either with your response.
I use Kanban only for software development. So, yes, I guess I actually understand it better in its original manufacturing context then in software :D

Re:Betteridge's law

[angel'o'sphere]

Exactly, I personally ... and my team, has no manager. (And that was mostly true the last 15 years in various projects and companies)
The company has top level executives, those are our managers, but they don't manage the software development, or the dev teams.

Re:Betteridge's law

[phantomfive]

The person who can fire you is your manager. And if you don't do well, he can get fired as a result. That dynamic is real, even if you try to ignore it. Even if he's a "hands off" kind of manager, that just means you got a good manager (or he's a bad manager and you got lucky)

Re:Betteridge's law

[angel'o'sphere]

You want to nitpick?

Well, we came to that "manager issue" when I said an agile team does not need and in my case has no manager.

Obviously we started about "manager" as in the sense of one who is organizing to a certain degree what a developer is doing when and how. Such a manager I don't have. And as agile coach I urge organizations to get rid of such manager positions.

But yes, I have a boss who can fire me. But he is not my manager.

Re:Betteridge's law

[phantomfive]

Ok, your manager is really hands-off. That is good. But he still is going to be in charge of giving you raises and performance reviews, and making sure the team is going in the right direction overall for the company. In your case, if you've only worked in small companies, then the fact that your CEOs have been hands-off means they have a lot of respect for you, which is a good reflection on you. If you want to call that guy a 'boss' instead, that is fine.

Obviously we started about "manager" as in the sense of one who is organizing to a certain degree what a developer is doing when and how.

So are you doing Scrum then? Because Scrum does have a manager called a "Scrum Master" who is organizing to a certain degree what a developer is doing when and how.

Re:Betteridge's law

[angel'o'sphere]

We do Scrum, yes.
However the Scrum Master is not managing the team, he is only responsible to implement Scrum, and when it us running, he is obsolet. As long as it is not running, he is more a Coach than a manager. The only thing he is actively managing (until he has made himself obsolet) are the so called ceremonies, or rituals: daily standup, sprint planning, sprint review, sprint retro, backlog grooming.
Ther is a second somewhat managing role, the product owner, a tailored/lean product manager.
The company is not really small, about 300 people.

My team e.g. has no Scrum Master, only a PM.

Re:Betteridge's law

[phantomfive]

Yeah, that's a manager. Unless you have some strange definition for manager that doesn't include "making sure things are running the way they should."

My team e.g. has no Scrum Master, only a PM.

This is a little off-topic, but PM could either be project manager or product manager, so it is quite ambiguous.

Re:Betteridge's law

[angel'o'sphere]

I explained that the PM is a kind of product manager.
And the SM is teaching Scrum, he is neither managing the team, nor the product, nor the people, nor the software development process (Scrum is a metaprocess).

Re: Betteridge's law

[MadKeithV]

If your software development method is not working: you do it wrong! Regardless what kind of method you use.

See, that's pretty close to what I meant in the GP post: if your team is already good at developing software, they are still good when doing it the "Agile" way. It doesn't really make them better. It certainly doesn't make a weak team better (usually quite the opposite, because management will tend to leverage parts of Agile against the team in the worst possible way). You know, I like the agile manifesto. I think there are quite a few things in there that really ring true (for good teams). But Agile/Scrum/XP as a "process" just is too vague and badly-described to be a "prescriptive" way of successfully delivering software, and too often simply devolves into a religion for the sake of the sacred text instead of actually just delivering something the customer/end user needs.

Judging from 20 years experience doing it, I think delivering software just isn't something that is easily poured into a recipe-like process. It's different every time, and there's always the fuzzy people-factor. As Joel Spolsky once said, get the people that can "just get stuff done". They'll figure their own way of doing things, and it doesn't need a "Process".

Re: Betteridge's law

[angel'o'sphere]

Scrum is a meta process.
It basically does not describe any thing relevant for software development, except that a sprint result should be a tested "installable" release. So: being able to install it and have it tested (somehow) is the only connection to software development.
In other words: it does not say, that you need a version control system, use a CI server, write automated tests etc.

OTOH, Extreme Programming (XP) is all focused around software development.

As Joel Spolsky once said, get the people that can "just get stuff done". They'll figure their own way of doing things, and it doesn't need a "Process".
And that exactly is what agile is about ...

Re:Betteridge's law

[phantomfive]

ok, so have a non-standard definition of manager, that's fine; "an argument about the world is interesting, an argument about a word is not."

Overall I see you as a reasonable chap. Somehow I see standups as horrible things to be endured, and you see them as quite great. I kind of wonder why we see them differently but don't really know.

Re:Betteridge's law

[angel'o'sphere]

Because your stand ups don't work for you but mine work for me :D

But in my current team the stand ups are a bit to long, too. It should be less than a minute per person, but alas ...

Re:Betteridge's law

[phantomfive]

They are short, so in honesty it's not a big deal, just painful for a short amount of time. What is the point though? They feel pointless more than anything.

Re:Betteridge's law

[angel'o'sphere]

Well, if yours are pointless, then ask if you can make restricted stand ups, where only 1/2 or 1/3rd of the team meets and people only join every second or third stand up.

The point of a standup is to answer the 3 questions:
1) What did you finish today/yesterday?
2) What is your plan for today/tomorrow?
3) Is anything blocking you from doing your work?

The SM (or similar role) has to address the blocks, 1) and 2) give an idea of progress of the work. And if a discussion springs up (which should be quenched quickly and addressed under 3) to make a dedicated meeting to talk about) then the SM knows there are hidden problems.

Re:Betteridge's law

[phantomfive]

That sounds a lot like a status meeting.

Re:Betteridge's law

[angel'o'sphere]

In a certain sense they are.
However if one would use the term talking to me, I would assume he means a higher level meeting of product managers (POs) and the executives, where several projects are tracked, not a single one.

Re:Agile is bullshit

[fluffernutter]

I disagree. I think it has a lot of good theory behind it. The problem is, the 'do more by doing less' concept *really* has to be embraced by the entire organization; especially those at the top. Too often it isn't. If you work in a place like this, removing Agile probably won't help much.

The Question

[Anonymous Coward]

It's time to idiot-proof your methodologies. If even the lightweight methodologies are so easy to do wrong, what change is there for the efficient application of the heavier ones? After all, the water-fall was the anti-thesis of a working approach which people adopted as the method. This has to prove that people have difficulties even in the skills like reading.

Software Development Methodologies are for muggles

[Anonymous Coward]

The failure of Agile was always there from the start. The original consulting firm pushing it was a failed software development firm that found a hustle to keep going. Good programmers (in the broad sense, including many related job descriptions) are necessary but not sufficient to deliver working software. Having reasonable goals is also a requirement. If you have both, you often succeed. If you don't have both, you fail. That's it, everything else is for the benefit of middle mismanagement.

Agile in practice

[Anonymous Coward]

It's rarely done by the book - almost ever org I've worked for tries to tweak it to "make it work better for us". It usually means longer or shorter sprints (screwing up cadence, where you run behind or only do "big" sprints) or daily meetings that last for an hour.
Either do Agile like it was designed or do something else (Agile is absolutely not the only way to run a dev shop), but don't hybridize it and try to convince yourself and others that you've made it better.

Re:Agile in practice

[Anonymous Coward]

You have to tweak it, particularly if required to "scale" it since the consultant bs is more interesting in what they haven't covered and have no solutions for.

Agile wasn't designed by a creator god, so what you're writing makes no sense. Unless you're a trainer for one of the bs companies that have trademarked their particular theft of other peoples ideas and common sense.

Buzzwords Ruin Everything

[Anonymous Coward]

Let's face it: buzzwords ruin everything. "Agile is a turn-key solution to invoking a paradigm shift within the DevOps world." Agile in itself is a buzzword, and if it wasn't initially supposed to be one you can bet it was put through the ringer until it was one. "Stories" and "Sprints" just add to the mess.

Yes

[Hognoxious]

Thanks to using tried and tested wartsandall I got a frosty pist!

Agile is like Communism

[Anonymous Coward]

It's got a manifesto.
Those who have to live with it want to escape it.
It slowly destroys organizations that use it.
Despite always failing "real Agile has never been tried right".

Re: Agile is like Communism

[getuid()]

Like communism, it was invented to ameliorate a desperate situation that existed previously, and like communism, it succeeded in that by having some of its good ideas incorporated into what was there before.

Agile is for babies

[Anonymous Coward]

Agile is for undisciplined developers and managers of those developers, not to mention the bending of rules that invariably happens when the business side gets involved.
The so-called business buy-in almost always means some form of compromise to the point where you end up with Agile Theatre.
Checking in daily for scrum is like being in kindergarten with show and tell every day, how glum.

Re:Agile is for babies

[Anonymous Coward]

Right, it feels like hand-holding. If you don't trust me to do my job then why did you hire me? Not to mention the word "scrum" sounds like some demeaning garbage pulled from the bottom of the can. So much for empowering devs.

Re:Agile is for babies

[Hognoxious]

I would say that agile is for very self-disciplined developers & customers. If I'm developing something for myself, it's agile all the way. And has been for 30 years, I might add.

Re:Agile is for babies

[Anonymous Coward]

In my experience, Agile isn't to keep track of programmers who may not be doing their job. It's cosplay for managers who can't figure out if their programmers are doing their jobs or not. The managers are going to scrums and meetings and reviewing time estimate spreadsheets in a conference room with everyone on the freakin' project.

Agile is the development methodology that prevents managers for being blamed for failure since they were visibly busy all the time, while still permitting managers to take all the credit for projects that succeed somehow. Oh, and it shoves two programmers into the space for one, so the bean counters like it too.

Re:Agile is for babies

[Anonymous Coward]

IF you're developing something for yourself, the methodology doesn't matter much. IT sounds like your methodology is better described as "feral" than "Agile". Not that there is anything wrong with that. Many of the best software projects were developed without dogmatically, formal methodologies.

Re:Agile is for babies

[HornWumpus]

GP is criticizing scrum, not agile.

That confusion is at least half the problem. They _not_ synonyms, you _can't_ be both. Agile: People over process. Scrum: process, process, process, you are just replaceable cogs.

Re: Agile is for babies

[Anonymous Coward]

I wish I had the time to attend all my teams DSUs.

Re:Agile is for babies

[Anonymous Coward]

While the GP is incorrect, you are JUST as incorrect. Agile and Scrum often go hand in hand, your project most definitely can be both. Scrum is part of Agile.

Re:Agile is for babies

[HornWumpus]

Only scrummy people consider scrum agile. Agile people do not.

Point to any reference to Scrum in the Agile manifesto. TFA is one of the manifesto's authors suggesting that the word be abandoned, as it is now covered in Scrum and other shit.

Re:Agile is for babies

[angel'o'sphere]

Scrum: process, process, process, you are just replaceable cogs.
Scrum dos not define any software development process.
It defines a meta process and rituals/ceremonies to keep the meta process on track.

No, it does not make developers cog wheels ... if that is happening for you: you are doing it wrong ;D

Re:Agile is for babies

[angel'o'sphere]

Only scrummy people consider scrum agile. Agile people do not.
Everyone considers Scrum agile. Except you obviously.

Point to any reference to Scrum in the Agile manifesto.
Why would there be any? Point to any reference of Kanban or XP in the Agile Manifesto!

The agile manifesto is a destination of many agile methods, to nail down the core principles. Why would they need to point to the "methods" they consider agile?

And I really wonder abut your hate to "agile", "Scrum", "XP" (and other people like arth1 etc.) ... what is so fucking hard in finding an employer "Who does Agile right?" Why are you complaining all the time but seem to be _frozen in place_ instead of being _agile_ and for funk sake change your job?

So TLC was wrong?

[BenJeremy]

We should go chasing Waterfall?

Re:So TLC was wrong?

[Anonymous Coward]

No, you should approach each and every software development project in a way that makes sense for its requirements. There is no magic process that will work for everything.

Agile is all about shipping incomplete half-baked junk, for the beancounters benefit alone.

Re:So TLC was wrong?

[Anonymous Coward]

That kind of thinking has no place in the business world, young man!

Re:So TLC was wrong?

[Anonymous Coward]

Whoosh...

+1 funny for parent

Re:So TLC was wrong?

[Anonymous Coward]

No. I got the joke. I just wanted to shit on agile and the words it uses (waterfall) to describe the heresy that is not "agile".

Agile is bullshit. Waterfall is bullshit. There is no such thing. It is a word used to denigrate dissent.

Dipshit management can just fuck off.

Re:So TLC was wrong?

[Krishnoid]

There is no magic process that will work for everything.

So in different words, I guess TLC was right.

where have I heard this before?

[Anonymous Coward]

a manifesto outlining a path for the people responsible for creating wealth is abused by a few powerful people.

Agile is like communism.

[Anonymous Coward]

Everyone says it will be perfect if it were just done right.

Yes!!!

[110010001000]

Yes, we should switch to whatever Ron Jeffries is selling!

Agile - no planning and we'll get great results!

[Anonymous Coward]

Let's build a complex system from the ground up using Agile!

Requirements? Bah, we'll iteratively improve our product!

Design? Not needed! That's not needed

Two years later:

"You need what? Ummm, we can't make those features work given this mass of interacting black boxes. Seems like nobody documented how they work together..."

Maybe?

[apoc.famine]

I've worked in both a small shop (under 20 developers) and a decently large organization (more than 400 employees) although outside the dev shop. I had positive agile experiences in both places.

What I've found is that agile works given a few conditions:

1) The organization actually adopts agile, and embraces it.
2) The owners of the development both understand agile and have the political power to enforce it.
3) The devs understand agile and can thrive within it.

When all that happens, and I know that's not often, Agile can shine. I've seen it, and I've really appreciated it. I get how it can go terribly wrong, but it can and does work, if the environment allows it.

Re:Maybe?

[Anonymous Coward]

When all that happen...

Forgive me, but it sounds like just about any organizational technique would have been successful under the utopian conditions you described. Agile was simply the one chosen.

My experience has been extreme micromanagement

[Anonymous Coward]

I have found agile to be a great tool for micromanagers. Because the business doesn't actually know how to abandon BDUF, they still do it (gotta have time lines and designs and schedules and all this certainty, despite being "agile"). Then they cram scrum and sprints and shame-filled standups down their developers throats with micromanaging PMs. The one I worked with was a narcissist to boot. I'm convinced Agile can only work if administered by people with software engineering experience (which is far too rare in software engineering management; so many seem to me PMPs and Industrial Engineers).

Agile is like Communism.

[Anonymous Coward]

It'll destroy your team's productivity, but only because "THAT ISN'T REAL AGILE!!!!!!!!111111111111"

Agile needs to be put up against a wall, yes.

You can always end up with a pile

[rsilvergun]

we're talking about minimizing that risk. If you're having that much trouble it's because nobody's managing the queue. But at least there _is_ a queue. There's something written down that can be post mortemed. The alternatives I've seen is to write a massive design document and have at it.

Abandon all magical methodologies

[Anonymous Coward]

Stop believing that if you could only find that one perfect methodology, your mediocre team of developers will create greatness. It has never worked in the past, and "agile" (however you define it) is no different. Project managers and business types are addicted to this fantasy, because accepting the reality would lead to extreme cognitive dissonance.

As always, there are no silver bullets. Hire smart people, give them autonomy (they will adopt their own methodologies as needed), keep teams small, and design solutions that are as simple as possible (but no simpler). Domain knowledge and close communication with the end users helps. But all that is no guarantee of success either.

Re:Software Development Methodologies are for mugg

[Anonymous Coward]

Bingo, useless managers trying to justify their existence with bullshit & buzzwords.

Bad Managers and Bad Developers are the Issue

[Anonymous Coward]

Bad managers will not use Agile as an empowerment tool and instead simply mimic the rituals but not realize the benefits. Bad developers will use Agile as an excuse to do whatever they want rather than focus on the output of value for the end user, often in service of avoiding future rework or in the name of faux quality features that doesn't actual add significant value.

I've seen both ruin many an effort. If managers would focus on building a high functioning team, empowering them, and building a continuous improvement cultures and developers would focus on understanding and delivering value to the company then Agile works better than anything else out there at least currently.

BTW, bad managers and developers also screw up waterfall and any other methodology you want to work with.

Re: Agile is bullshit

[Anonymous Coward]

It's job security. Never-ending projects keep developers employed and the fires that need to be constantly extinguished are by design. Now go mitigate Spectre variant 6 or whatever...

Two cases

[sjames]

Part of the problem is the idea that with sufficiently detailed procedures, the village idiot can do theoretical physics as well as Einstein. In fact, no amount of procedure will make that happen. Quite the contrary, all that procedure means that if you ever do hire Einstein, his output will closely resemble that of the village idiot.

Consider one of the popular union tactics, the "rulebook strike". That's where they destroy productivity and punish the employer by having their members actually follow all the workplace rules and procedures rather than doing the right thing (TM,. pat. pend.). It works.

Re:Two cases

[JaredOfEuropa]

It’s process replacing competence. But the problem isn’t that managers think average guys + procedure adds up to Einstein, its that they think that with enough procedure, average devs can get 70% of the work done (in terms of quality and productivity) that fully competent devs produce, and that 70% is enough. They are usually wrong on both counts.

They apply the same to Agile. Instead of embracing its principles and empowering competent staff to apply them, they seek to translate Agile into more rules. To the point where they actually require prospective team members to hold an “Agile practitioner’s” certification. Like writing a 500 page essay on brevity.

Re: Two cases

[Anonymous Coward]

The reality is that you either take the Einstein's out of the process OR the Einsteins learn to play the game and management turns a blind eye in order to give the Einstein's bandwidth to excel.

Re:Two cases

[Anonymous Coward]

Like filing an incident report every single time a forklift or carried load touches racking? Or every single time the forklift drives over hard debris on the ground, say a piece of wood.

Yes this week we were told at a safety review that was necessary.

Re:Two cases

[Anonymous Coward]

...oh, and the racking would have to be inspected by OH&S after the touch to ensure it wasn't structurally compromised. Couldn't be used until.

Re:Two cases

[sjames]

The thing is, if the staff are competent, they don't need to read about Agile, they'll do the right thing IF management does it's job by keeping things out of their way rather than getting in their way themselves. (that is, management needs to be competent as well).

If they're not competent, nothing can help them anyway.

Re:Two cases

[Anonymous Coward]

what your talking about is micro management. The basic idea of agile is that unless you're doing the same programs over and over, just slightly different each time, then it's next to impossible to give realistic time frame predictions. So you take long term goals, put them in sprints so you have weekly or monthly checks by management to see if things are off track. Then daily it's up to the developers to help each other. Then at the end the developers modify time expectations and then it's managements job of relaying that to the customer or telling those outside the development team that they need more time/resources/whatever. But instead what happens is management continues to micromanage and instead of defending develoeprs/ shielding them from those outside the team... they tell the team the same thing no matter the process.. Get shit done, or else!

Re:Two cases

[phantomfive]

The stuff we're programming in Silicon Valley is closer to what the village idiot does than what Einstein did. It's all a bunch of crappy workflow software.

Re: Two cases

[denis.goddard]

Amen. Iâ(TM)ve been managing software development teams for nearly three decades, and IMO the single most important job of software management is to leave developers alone. Shield them from the Drama/Hot Feature/Management question of the Day. Keep their time in meetings to the barest minimum. Make sure their support responsibilities can be planned for, so they are not jumping into one emergency after another. Make sure customers arenâ(TM)t wasting their time with emails and chats. Absolutely resist the âoejust spend an extra few minutes documenting what you did the last 4 hoursâ/clicking pointless checkboxes/justifying every 30-minute interval of their day. Software requires THINKING. Concentration, in long uninterrupted blocks. Thatâ(TM)s the secret to making the secret sauce: let them think and program.

Re:Two cases

[Anonymous Coward]

Consider one of the popular union tactics, the "rulebook strike". That's where they destroy productivity and punish the employer by having their members actually follow all the workplace rules and procedures rather than doing the right thing (TM,. pat. pend.). It works

That's funny. If the employees don't follow the procedure, they are liable for any accidents and their own health care costs. Now, who wins in that scenario? The lawyers and insurance companies. Meanwhile "The Right Thing" you're referring to places the employer under the liability should any accidents occur. Fortunately this is discussion is about programming stuff which is completely mostly harmless activity.

Re:Two cases

[140Mandak262Jamuna]

"Fortunately this is discussion is about programming stuff which is completely mostly harmless activity."

Paging Elon, Paging Elon. Mr Musk, we found the guy who is coding up the AutoPilot.

Re: Two cases

[Anonymous Coward]

But how can we be Agile(tm) if we don't write our daily TPS reports??

Re:Two cases

[swb]

The best part about the rulebook strike is that you don't need to strike or be a union member to get mileage out of it.

We had a come-to-Jesus meeting about slow time entry (our system sucked, was cumbersome, and management's general expectation was that time entry should be done on your own time).

During the meeting where we vented at some of the dumb misfeatures of time entry that required multiple steps due to bad field interactions, it was suggested that total time mattered, but start/stop fields didn't need to be accurate. Of course I raised my hand and asked why we collected them at all, and what other fields we collected data on were ultimately irrelevant.

Of course my manager was tongue-tied, trying to explain how none of it was really irrelevant but that we should consider some of it irrelevant because it got in the way of the main goal, collecting time for billing.

I love to exploit these situations from time to time, following their rules to the T until they tell me to stop following their rules because its getting in the way. You keep enough of these emails and suddenly no rules matter because it becomes apparent that they're as interested in convenience as anybody.

Re:Two cases

[Anonymous Coward]

Never underestimate the destructive power of an office heavy at close range, particularly at Musk companies. Some of them might be packing flamethrowers.

Re:Two cases

[chihowa]

Those rules aren't in place to be followed. They're in place to limit the employer's liability for workplace injuries.

If you follow all of the rules, you'll be let go as underproductive (since nobody else will follow all of the rules). If everybody follows the rules (rulebook strike), overall productivity tanks and nobody can be called out on it.

Re: Two cases

[ath1901]

A friend of mine who runs a small company once asked what I thought was the most important job of a boss. I said: "Removing obstacles for their underlings". He really didn't like that and started talking about vision, planning, goals and such. I didn't reply and mentally excused him a bit since he's running a really small company and may not have experience with the kind of problems that arise in larger networks of people.

Re:Two cases

[Anonymous Coward]

"Part of the problem is the idea that with sufficiently detailed procedures, the village idiot can do theoretical physics as well as Einstein. In fact, no amount of procedure will make that happen. Quite the contrary, all that procedure means that if you ever do hire Einstein, his output will closely resemble that of the village idiot."

That. Is perfect.

Stop conforming

[Hugh Jorgen]

And use common-fucking-sense. Enough with trying to adhere and conform to buzzword driven fads.

Absolutely!

[chromaexcursion]

Because most don't actually do agile.

I have a great deal of experience with Agile

[Anonymous Coward]

Agile doesn't help developers. It doesn't make them better programmers. It doesn't produce better code. Agile is not for the benefit of developers. Agile improves information flow to project managers. It allows for better business decisions.

Theoretically if a project is going south you can even abandon the whole project and move all the resources onto something that has a chance of success. But I've never seen Agile used in this way in the real world, perhaps the sunk cost fallacy is too strong in business culture.

If you want a hint on how little value Agile offers to developers. Look at the top open source projects, look at a 100 of them, I don't care. You won't find them using Agile, you may even hard pressed to find them using bits and pieces of Agile. And I think it's because coders don't enjoy it. Coders won't use Agile unless someone is paying them, but they'll write code for free.

Re:I have a great deal of experience with Agile

[Anonymous Coward]

Agile undermines ownership of the project. When, in the process of building a product, a programmer is expected to do their work in 2 week chunks exactly as (usually someone else) has decided with very little room for deviation (gotta maintain that velocity!), it's hard to feel invested in what he or she is building. It's hard to feel like your human judgement means anything at all. You feel like an underappreciated cog (and at many companies, you are!). You certainly don't care if the project succeeds or fails. You just want to get your sprint finished as quickly and easily as possible so you can go home. And, agile in practice reinforces that, because that is how management sees it. It should come as no surprise that taking your expensive developers and turning them into what feels like an H1-B code mill will reduce quality and long-term efficiency. Programmers often do the job of a programmer despite being able to do the job of the manager who cannot do their job because they love building shit. If you take that passion out from under them, you will drastically reduce their output in the long term if you ask me. It might look like great velocity, but that's just a comforting lie management tells themselves (because I've never worked for a manager who had any experience programming... which is sad in and of itself).

Re:I have a great deal of experience with Agile

[Anonymous Coward]

That's it, that's it exactly! I recently retired from 30+ years in IT, doing programming in all kinds of environments and all kinds of businesses, and I retired mostly because I felt I'd had all the joy finally beaten out of me. When I started, it was fun to make things that worked, that actually made the daily working grind better for the people who used the software. By the end, it seemed like the goal was to slurp down the buzzwords of the week, rather than making things that worked!

All the passion is gone from the industry, at least the parts I worked in. No methodology will make the soul-dead zombies, that are the programmers these days, able to build good things.

Re: I have a great deal of experience with Agile

[Anonymous Coward]

It's more likely that in an open source project where developers come and go it is hard for the most popular agile methodology scrum to work. If they use a prioritized task tracker you could argue that's kanban. Also since you can't dictate what the people you don't pay do, that might not even be in order of priority.

Re: I have a great deal of experience with Agile

[denis.goddard]

Thank you. Screenshotted your post and saved it. Someday when Iâ(TM)m either fired, retired, or struck it rich, Iâ(TM)m showing this to my project manager.

Re:I have a great deal of experience with Agile

[mvdwege]

Agile is not for the benefit of developers. Agile improves information flow to project managers. It allows for better business decisions.

Nailed it. But I think you miss the main implication: that is and should be the point.

Contrary to what a lot of coders think, code is not an end goal. A working application is not even an end goal. In the end, why we have coders is because we need to automate (business) processes. And without better information flow to the business, the code produced will not do that satisfactorily.

Re: I have a great deal of experience with Agile

[Anonymous Coward]

We're AGILE(tm) soul-dead zombies, you insensitive clod!

Re:I have a great deal of experience with Agile

[angel'o'sphere]

When, in the process of building a product, a programmer is expected to do their work in 2 week chunks exactly as (usually someone else) has decided with very little room for deviation (gotta maintain that velocity!), it's hard to feel invested in what he or she is building. It's hard to feel like your human judgement means anything at all.
If "someone else" has decided what "chunk" fits into a 2 week sprint, then: you are doing it wrong!

(gotta maintain that velocity!)
No, you don't have to maintain your velocity: you have to for funk sake measure it, that is all. If you think you have to maintain it: you are doing it wrong!

You certainly don't care if the project succeeds or fails. Then you are a moron and should be working in a business that does projects. You are doing everything wrong!

You just want to get your sprint finished as quickly and easily as possible so you can go home
A sprint finishs, when the time is over, not when "everything is done", if you think otherwise: you are doing it wrong!

And, agile in practice reinforces that, because that is how management sees it. Then your management has not understand what sprints and being agile is about, hence: you are doing it wrong!

(because I've never worked for a manager who had any experience programming... which is sad in and of itself).
Then stop whining, get _agile_ quit your current job and find a manager that has a clue about software development.

Re:I have a great deal of experience with Agile

[Anonymous Coward]

translation: everything in parenthesis is your strawman.

Re:Software Development Methodologies are for mugg

[Anonymous Coward]

People who use hairy pooper terms like that can immediately be dismissed for being the morons they are.

Supposedly been doing agile for years...

[srichard25]

I've supposedly been doing agile for years, but I've never once worked on a self-organizing team who could build software without working with several external groups. And all of those external groups are set up to work waterfall. You've got the UI designer who wants to design the whole experience up front. You've got the data modeler and DBA who both want to know exactly what data you will be using up front. You've got the architect who wants the full design documented so they can spend 10 minutes looking at it and give you an approval. You've got the project manager who wants to know exactly how long all the development is going to take. So you end up having to do big-design-up-front in order to work with all these external groups.

A lot of companies say they want developers to do agile, but they need to realize that agile requires changes throughout the organization. It's not something that developers can just do by themselves.

Re:Supposedly been doing agile for years...

[Anonymous Coward]

I've supposedly been doing agile for years, but I've never once worked on a self-organizing team who could build software without working with several external groups. And all of those external groups are set up to work waterfall..

This, This, Eversomuch this.

Agile needs full understanding and buy-in from your own management, and from the customers. To date, I've never seen this happen

Re:Supposedly been doing agile for years...

[Anonymous Coward]

+1 the sales/marketing/management types want to know what features and dates they can promise, and once you make THAT commitment you cannot be agile.

Agile is only possible when you have flexibility in what or when you deliver. And I think the reason most organizations can't do it is because they can't bring themselves to BE mentally agile. Ironically, the certainty they crave isn't possible to achieve when they behave as they do.

Re:Supposedly been doing agile for years...

[Antique Geekmeister]

> And all of those external groups are set up to work waterfall.

Or, in my experience, they are often set to work only through a manager. Tasks must be explained to one manager, who has the status to talk to another manager, who has the status to speak to their team, and _each_ layer must be completely convinced of the priority and feasibility before a question can even be asked about the available tools. Attempting to do "agile" in this kind of structure is disastrous, because even if a team accomplishes its designated tasks, nothing else is ready. And by the time the other teams are ready, the original work is no longer relevant.

I've no overall solution for this. I and my colleagues have, on occassion, been able to coordinate multi-department work under the guise of "external consultants", and been applauded for helping.

Re:Supposedly been doing agile for years...

[Anonymous Coward]

Heh. I was the data modeler/architect at a place where the programmers went Agile. I knew that if they changed the way they did things, I would have to change, too. After all, there were 60+ programmers, and I was the only data guy at the place (hey, it was government, it was a miracle we even had one data guy). Of course I'd have to adapt.

So I asked to go to their Agile training classes. Denied. I asked for whatever documentation they were giving the programmers about Agile, so I'd at least know what their approach was. Never got 'em. I even asked for some damn links to stuff on the net, so I'd at least get the gist of whatever flavor of Agile they were shooting for. Nope.

I finally got the hint and shut up. I also moved on. Last I heard they'd scrapped all their own plans and brought in HP (or whatever they're called this week) to do everything for them. People are retiring and getting out any way they can; decades of business and legal knowledge just walking out the door. But hey, the managers all moved up a rung, and now they can get even better salaries when they leave the wreckage.

I honestly don't know how our civilization has survived this far.

Re:Supposedly been doing agile for years...

[Anonymous Coward]

This is a challenge when the company wants everyone to stay "on task" for all of their regular work hours. A lot of real work is accomplished through informal interactions, that needs to stay out of the managers' view. Total visibility into how the sausage is made usually irritates managers, because it is apparent that the manager is really needed as an HR interface, not a workflow controller.

Re:Supposedly been doing agile for years...

[MobyDisk]

Why is your UI designer and DBA not part of the team? Agile doesn't work outside of software. But UI and DBA are part of software.

To me "external groups" is the finance group who wants to know how much it will cost and over what period of time before they even start the project. It means the marketing team who needs to know the full feature set to decide if the product is viable and how much to spend on it. But the worst is engineers: they want to lock-down the hardware specifications 3 months ahead-of-time and order the parts in quantity of 5000. That's fundamentally incompatible with the agile process that promotes constantly changing requirements.

Re:Supposedly been doing agile for years...

[angel'o'sphere]

Tasks must be explained to one manager, who has the status to talk to another manager, who has the status to speak to their team, and _each_ layer must be completely convinced
I really wonder: what actually do you et wrong with "agile"?
The point of agile is to REMOVE those layers and have ONE SINGLE DECISION POINT.

Why is it that people don't grasp the most simplest things about agile methods?

Re:Supposedly been doing agile for years...

[ath1901]

But you can't avoid that in a large organization. Organizations have APIs and abstractions just like code.

Departments are abstractions for "people doing IT/economy/cleaning etc". You can call them and ask them to do stuff without knowing how they do it.

Between the departments there are APIs. Agreed upon processes on how to transfer information. Excel sheets, meetings, databases etc.

Big multi-department projects require some specification of the APIs up front or people can't start working. You need to know your inputs and outputs. If you must change an API later on, you may throw away someone elses work. That is why some kind of up front specification is often necessary. Usually, defects in the interdepartmental interfaces aren't visible until very late when things almost work so whole-company sprints won't help.

Re:Supposedly been doing agile for years...

[srichard25]

"Why is your UI designer and DBA not part of the team?"

I work for a fairly large company. I'm not sure the exact count, but I would assume that we have > 80 development teams. We don't have anywhere near enough UI designers and DBAs to put one on each team. My point above was that organizations need to make changes throughout to support agile (ex: hire more UI designers and DBAs so that each team can have one), but we all know how that suggestion turns out don't we?

What's the cost of having extremely flexible (agile) development? The cost is that you have to staff teams with all the experience necessary to do full life cycle development without waiting on others. If you just have people with one standard role (ex: DBA), then that means some resources will be underutilized. Large companies hate to see underutilized people, so now you need to find someone who is good at development AND DBA. That's a little tougher to find. And you have to find a person like that for EACH development team. Good luck with that.

Honestly, I would be surprised if any large corporation is actually doing real agile as specified in the manifesto. My guess is that this model only really works for start up companies with a few teams filled with rock stars developers who can do multiple roles. And those are the people writing books and giving talks at tech conferences, trying to convince the rest of us to just work the way they do. If only it were so easy.

Re:Supposedly been doing agile for years...

[Antique Geekmeister]

Note that this isn't _my_ agile setupl. This is what I've encountered, repeatedly, for agile users inside various companies. The "agile" approach often has not scaled well, it's applied to individual teams without clearing away middle management. When the necessary size or tasks of a single team grow beyond those of a handful of active developers, the teams split or have to be split, and middle management can form quite quickly even for startup companies where there was none.

> Why is it that people don't grasp the most simplest things about agile methods?

They understand quite well that agile methods are often like the "true Scotsman". or "true Marxism". or "true Capitalism". There are limiting factors in the real world that have to be worked with.

Re:Supposedly been doing agile for years...

[Anonymous Coward]

External groups should be part of the team - cross functional team. Waiting on external parties is not Agile.

Re:Supposedly been doing agile for years...

[MobyDisk]

agreed.

Agile: "we don't know wtf we're building but ..."

[shm]

"... we're going screw around everyday acting all busy."

When you don't know how to swim, splashing water all around seems like a great idea.

Re: One problem: no normative definition of "Agile

[shm]

But but but my deep learning?

Re:Agile is bullshit

[Anonymous Coward]

Theory and reality are usually very different things.

Already did

[Philotomy]

I was on a team that "used agile" for while. The thing is, our development workflow "before agile" already addressed the main ideas in the agile manifesto, so in practice what happened is that our development workflow was unnecessarily modified (disrupted?) to include more "agile practices" like pair programming and other buzz words (user stories, rigid application of TDD, et cetera). We didn't see much (any?) real benefit. It eventually got abandoned. Can't say I miss it.

I've got no problems with the ideas in the agile manifesto. I'm just not convinced that the practices and culture that often gets included are always worthwhile.

I Haven't Seen Developers Actually Choose

[brian.stinar]

At every place I've worked, including the company I now own, the developers haven't been the ones that decided on the development process. The fact that they haven't decided has either been because no one actively decided, and management provided a default choice, or because management actively made a decision regarding the development process (either due to business needs, or basically arbitrarily.)

So, I believe the question of whether or not developers should abandon Agile is based on the false pretense that developers typically are able to make a decision. I don't believe that they are able to decide which development methodology they subscribe to, in general.

Can't force a square peg into a round hole

[Kjella]

Agile doesn't deliver what the business wants which is to turn coding into non-creative work where you know almost exactly how long it takes to get from A to B and exceptions have explanations like traffic accidents or construction work. Nothing ever will but it won't stop them from trying so the best Agile can do is shield the developers from impossible tasks and meaningless meetings so they can spend time on actually doing development.

The first shield is the product owner, a ton of people want things and they'll go through all sorts of channels with competing priorities and sneaking in pet features. Shut them down, make that one channel in and one non-developer resource they can talk to if they're not happy with what they're getting. And no, there's no point in re-prioritizing things daily once every two weeks is fine for everything but hair-on-fire emergencies. The second shield is the scrum master, I'm currently one and my main job the way I see it is to maximize the number of hours my team members actually get work done on the things they're supposed to be working on. Particularly all fuzzy meetings called to discuss things where I say "You figure out what you want first from a business perspective, then let's talk solutions" or that are more or less status/re-planning meetings where I say "The quickest way to get it done is to let the ones working on it work on it."

It's not particularly Agile-specific, reality it's about two simple things, what should I be working on and let me be so I can do my f*cking job. Whether it actually works better for planning than iterative waterfall, meh... I've always said you should try to think and explain as far ahead as reasonable, like is this part of the functionality/structure you'd like to have in the end. You don't build a skyscraper by building a one-story building and then building one more story on top, if you know it's going to need to support 50 stories then tell us now.

Re:Can't force a square peg into a round hole

[phantomfive]

Most of it is uncreative. We're just doing websites that are slightly different than what's been done before.

Re:Can't force a square peg into a round hole

[MobyDisk]

Agile may be a fine software development methodology. But the contemptuous attitude that business needs don't matter isn't a successful strategy for making it work in the real world.

Imagine sitting in a meeting with an executive who says "We have $5 million to spend next year. What should I spend it on?" The manager of team W says "We did a market analysis and if we created product W and it has this feature and that feature, then we estimate a revenue of $3 million over the first 2 years, with $1 million over the following 3. We think we can launch 18 months from now at a cost of $2 million per year." Then the CEO turns to the manager of team A who says "Nobody's estimates are ever right, requirements can't be locked down, and products launch when they are done. Development is a creative process that can't be quantified, and exceptions always happen. I can have a working product in 2 weeks, but I can't tell you what will be in it."

Team W will get the development budget, not team A. I've literally sat in meetings where a very expensive Agile contractor tried to explain to a C-level executive why timelines and dollars aren't meaningful, and they had to "just trust that the team was executing as efficiently as possible."

Agile is a software process, but don't deny that business really does need to know how long it takes to get from A to B. They need that estimate of traffic accidents and construction work, and they will need to track it because when that big bag of money runs out, if the product isn't there then everyone involved loses their job.

Re:Can't force a square peg into a round hole

[Anonymous Coward]

Thanks for injecting a dose of reality to the discussion.

You can tweak methodologies all day long, but in my experience, the only way to know whether your team can complete a project (i.e. ship a working product) is if they have demonstrated in the past that they can.

Re:Can't force a square peg into a round hole

[Kjella]

Well it's easy to make caricatures of both methodologies. While the W manager may get the budget I've certainly met projects that follow the 90-90 rule:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

The project progress report tend to follow the first 90% and then the shit show starts with everything that's not working the way somebody thought it would and a whole lot of wrangling about how the spec is to be understood and how supposedly done code doesn't actually work the way they wanted it. That's why it's gotten a lot more iterative and agile-like in that the customer wants proof you're actually progressing and that they're getting what they want. The caricature of manager A only cares about the highest priority for the next sprint, but you want high level estimates for the backlog items. You need good enough estimates for a go-no go decision at every level, whether it's products, features, enhancements or tiny tweaks. But if you think the feature will get done quicker by having someone report a "percent complete" all the time, well... it doesn't work that way.

Re:Agile is bullshit

[arth1]

If it's embraced by the entire organization, that just makes it worse. The more parts you split something into, the greater the overhead becomes, at all levels.

Re:Agile is bullshit

[turbidostato]

"Agile, the idea, is total bullshit. Its execu-speak at its worst. Just fucking grade-a unproductive hot air"

It is not. In fact, it's quite the opposite. It's some developers thinking the problems they saw around you came from managers that didn't see the problems they were facing so, if only someone from the trenches could show to them...

Reality is, of course, that those managers are fully aware where the problems came from (if even unconsciously) and damn and hell if they want them solved, since those very problems are what give them job security to start with. Can you imagine an organization that *really* worked on the principles of agilism? Proper communication, no silos, recognition and rewarding where it's due, openly affront problems, letting those who know to take decisions... 90% of mid management (and probably executive-level too) would find themselves out of work overnight and without any valuable aptitudes for employability. Naaaah... better I fight for my fiefdom, corporate misalignment be damned, better I isolate those that know from those that decide, better I fill my agenda with meetings with others like me talking a lot about things we don't have the ability to make happen, nor the slightest hope to gain such ability in the future, so everybody thinks we are needed and that we are doing something important...

The root problem is simple

[Anonymous Coward]

Programmers that donâ(TM)t understand the business needs, business people who at best inaccurately describe what is needed, managers who donâ(TM)t get either. And everything has to get done now, or yesterday.

Re: One problem: no normative definition of "Agile

[Anonymous Coward]

Only if you blockchain.

Predictably from mediocrity

[Anonymous Coward]

Agile is great at providing predictability out of a mediocre workforce which, however unpolitically correct it is, makes up the majority. It's horrible, demoralizing, and unproductive for top performers. Good managers will figure out how to remove the top performers from the process or work out an "understanding" with the more astute top performers that they only need to pay lip service to the process.

Re: Predictably from mediocrity

[Anonymous Coward]

Correction:. I should have said SCRUM and not agile. Most of the time when I hear gripes about agile, it's really about scrum or some derivative.

Avoid "crufty" complex designs

[PPH]

Poettering! Don't try to sneak away.

Re:Agile is bullshit

[phantomfive]

Beyond the headline, here's what he says:

1) The team itself should choose the process because imposing process company-wide by business execs is bullshit. If you have a consultant come in and impose a method, that's reverse of what should happen.

2) The agile manifesto is good. (tbh it's actually kind of funny how many people are "doing agile" without ever having heard of the manifesto itself. Kind of hard to keep the core principles of the process if you don't even know they exist.)

3) All you need are three principles and those are, "release code often" "keep your code clean," and "push back against managers imaginations" by focusing on reality: what state the code is in now.

Again he reiterates, if process is imposed from above instead of chosen by the team, things will go wrong. He's kind of echoing Fred Brooks here, who said, "The teams need a process, but they choose it on their own."

Re:Agile is bullshit

[Anonymous Coward]

A two week sprint is a fine idea if you're in stable / maintenance mode. You're just knocking off tiny fixes / features that can be done in said window.

A two week sprint on a total rewrite is a bad idea, even if you have a PM who buckets things appropriately for time. Things run over, one moving part depends on another, etc. The best thing about Agile is that you can deflect incoming bullshit by saying "I'll add that in for a future sprint". They never want to say they don't understand what you mean, so it's just a thanks and a handshake before they fuck off.

Most people donâ(TM)t know what most things r

[PlayOfConsciousness]

Most people donâ(TM)t really understand most of what they say or think. Ask a manager what Agile is. Ask a developer what REST is or browse your codebase for the ten different implementations of something called a strategy pattern or a factory pattern. Ask yourself, honestly, how much do you really understand about things you talk about or follow? How much do you really understand that diet youâ(TM)re on or how to run the country that you think is making so many mistakes? Our brains fill in all these blanks for us, all the time. We go through life imagining that we have a coherent, complete view of whatâ(TM)s going on around us but we see little and understand less. No matter which methodology we try to push, very few people will really grasp it. Most people will read about it i their lunchbreak or hear about it at some pizza and beer fuelled âdev meetupâ(TM) or maybe even do a course in it and then steamroll it into their organisation and write âimplemented [some methodology]â(TM) on their six month review, get a gold star.

Never done agile

[Snotnose]

But I've been on 3 projects in the last 40 years (I'm retired now) that had daily meetings. All 3 failed for different reasons (hardware issue, company died before project was done, what I just said except for a chip, not a printer).

What did these 3 have in common? The daily meeting absolutely killed morale. For the first, us software types had a daily meeting where the hardware guys would mumble, the second was at 7 AM daily, even on a Saturday morning (I was in my 20's and still half drunk from the night before, and got sucked into the project when it was failing because "you understand this Unix stuff"), the third was flat out an incompetent manager who could not remember anything day to day.

For the first, no reason for us software types to be there as there was no hardware.

For the second, 7 AM on Saturday morning? You'd have been better off letting me roll in at 9.

For the third? There was no fixing that. The manager was 100% incompetent and could not be fixed.

Re:Never done agile

[phantomfive]

What is the point of a daily meeting? It's not for status updates (otherwise you wouldn't need a tracker). It's to make sure programmers are working. That's why.

Re:Never done agile

[Anonymous Coward]

Yes-- make sure they're working, by making sure they can't do their jobs.

It took my current boss awhile to realize that I actually try to think things out before I rush headlong into code-- so if I'm staring at the wall with my eyes closed, it's because I'm using the lump of grey matter between my ears to make sure I do it right the first time.

Hard to put down on a time tracker "Spent 12 minutes pondering various combinations of possible approaches" though.

Re:Never done agile

[angel'o'sphere]

Of course it is not for status updates.

However daily meetings help to realize that perhaps always the same developers are not finishing their work as planned. Perhaps they overestimate their capabilities constantly and pick to hard work from the issue tracker. Or you realize since days some of the developers are "blocked" because some administrative issues don't get fixed.

In a ten man team, a daily meeting can be over after 5 minutes, and indication is: most is running fine
It can take longer, indication is: you have problems

Identify the problems, address them to upper management, get them fixed.

If you waste time in meetings, then you either organize/conduct the meetings wrong, or you are not reacting to the issues raised in the meetings properly.

Re: Agile is bullshit

[Anonymous Coward]

Pfff... "do more with less" is why communism failed. You can't do paint with a fart, you need some substance (poo aka shit).
The only agile that ever worked is NASA's space program launches, there each launch is was its own sprint, sometimes lasting years, not mere 2-3 weeks.

Inexperience and bad form sinks the project

[Anonymous Coward]

A key concept in just about any programming task is you need to be doing software engineering, not just being a code monkey pumping out "work units". Just about anything where you assign code monkeys to do it or you yourself do not have a clue about what it actually means to be a software engineer, well it is going to go badly. When you have code monkeys doing 'agile' well monkeys do fling poo and this usually means they fling poo at a faster rate, making more of a stinky mess. The key things that must be adhered to even if say your original vision is like 30 lines of code, because everything grows and evolves is:

1. Do you have a modular design?

2. Does this modular design cohere to best practices, especially if there is any chance of all of this script / program / application growing to a significant size? Especially if you are looking at more than a couple thousands lines of code, you really need to start investing in an industry standard framework. When you get into the 10k+ line applications any application without an industry standard framework is a doomed one. I have gotten into 10M+ line applications with a proprietary one of a kind in house framework and people just give up and resign because it is just not maintainable and it is super plagued with problems due to this in house one of a kind framework. I am sure when they started, the idea was for a much smaller application, but software are just ideas put into a computer and ideas grow over time.

3. Are you using version control? If you are not using Git or something better (if you can find something better, which if you say yes today you are wrong), well there are going to be problems. Even with Git there are going to be problems, especially if you are inexperienced and dork it all up and/or your coworkers dork it all up, and especially if you don't have hook scripts to prevent clueless developers from dorking it up for everyone else. However without this central ledger, your project is doomed. Even by yourself it is really best to use version control like Git. Otherwise especially in a team, you are all driving around your bulldozers with no windows to look out and you are probably working off of your Pangia copy of the code base and/or actively fudging up the source files that another developer is also actively fudging up. Have actually gone onto job sites like this and those code monkeys did not understand why nothing worked and at this I could see remnants of the original software engineers' code where they did use version control, which is why the application worked at one point in time before the company fired them and brought on cheaper code monkeys to do the job, only to later bring on people like me to try to bail them out.

4. Do you have a real project management system, especially one that ties into your version control system? And at this are you and your coworkers using it right? I find most of the time the answer is no and so of course things are going to go wrong. Don't have the proper coordination or burn all of your time trying to do it manually when there is software automation and you are not smart enough to use a project management system, then you are probably not smart enough to write code that works. Just saying. And when your company is too stupid to understand this, then your coworkers are probably also going to be too stupid to figure this out and so you are screwed and know why you are screwed while the rest of the company ignorantly implodes in around you and leans on you even harder because do you think ignorant foolers like that are going to take responsibility or just blame everything on you?

5. Do you have real coding standards for your project(s)? Like are you going to agree on how to go about naming your variables so they are something that makes the code readable and use standardized naming conventions? So instead of you use the variable X and your coworker uses the variable R and between the two pieces of code you just assign the other person's X to your R and s/he will as

Cargo cults

[The Evil Atheist]

Developers should abandon their tendency to be cargo cultists. Don't do things just because that's the way it's always been done. Don't do things just because someone labelled them Best Practice. Don't do things just because other people have done it and it worked out for them.

The only method that works is to try it out and see where it leads, be super observant about where the pitfalls start appearing, and give yourself enough leeway to try something else if it isn't working out.

Re:Cargo cults

[Anonymous Coward]

There's cargo cult and then there's standardized processes.

Those are very very different.

Standardized processes are there because they work. Changing them even slightly without thinking about it (to say nothing about switching out the entire stack or something) will cause things to go horribly horribly wrong. The systems involved are so complex that you have to find the few paths that actually don't result in catastrophic failure (this is a multi-year endeavor) and document and standardize on those.

Re: Cargo cults

[Anonymous Coward]

No developer ever freely chose Agile. It's a micromanagement technique that is *imposed* on developers by clueless managers.

Re:Cargo cults

[Aighearach]

Don't do things just because someone labelled them Best Practice.

And of course the important corollary; always analyze best practices and follow them except when you've identified a good reason not to.

Lack of analysis will lead to a cargo cult in any direction.

Re: Cargo cults

[Aighearach]

Dude, you should go check IRC logs from 2006. LMFAO!

Re:Cargo cults

[The Evil Atheist]

And of course the important corollary; always analyze best practices and follow them except when you've identified a good reason not to.

Always analyze? Yes. Always follow? It should always be about picking and choosing, and shouldn't be a corollary. The corollary should be "don't be afraid to look at solutions already out there.".

Re:Cargo cults

[Aighearach]

Your problem was, you were unable to read English words and understand them.

You spent the time to reply, but then you converted my variable into an absolute, and attacked the absolute. Hey cluestick, you're the one who inserted the second "always," it wasn't in what you were responding to. Presumably I used too many words for you to comprehend, which you could simply recognize on your own and ignore.

Your proposed "corollary" isn't even a corollary. A corollary follows from what came before. You're not following from, you're just proposing an alternative.

Words, they're what's for dinner!

Re:Agile is bullshit

[plopez]

Agile is not a proper noun, it is an adjective.

What! Already?

[Anonymous Coward]

Fickle, fickle...

Re:Agile is bullshit

[geoskd]

I disagree. I think it has a lot of good theory behind it.

Agile is no better and no worse that any other way of doing business. In then end, good devs produce good work as long as management isn't totally inept. Bad devs produce bad work no matter how good the management is. The simple reality is that 50% of the software developers out there really should not be developing software because they just plain aren't good at it. Trying to somehow magically get good work out of them by "empowering" them is just putting lipstick on the pig.

OK, one more time. Agile is an adjective.

[plopez]

https://www.youtube.com/watch?...

Re:OK, one more time. Agile is an adjective.

[afgam28]

"Agile" is a product, sold by consultants. That makes it a proper noun.

There's another word in the English language, "agile", which is an adjective. But it doesn't get used very often in the corporate world.

Re:OK, one more time. Agile is an adjective.

[Aighearach]

It is sad how many people claim to understand a bunch of highly-technical computer languages, but then they can't even understand the basics of the English language!

For example, they develop some sort of "pet peeve" about a word they perceive to be incorrect, either in spelling or in its mere existence, and then they repeatedly rant about the word. However, each time they do it they're publishing additional examples of their disfavored word, thereby further establishing that it is a known word that is part of the English language.

Worse, most people who do this can't even explain accurately what a dictionary is! They don't understand it is just a list of words known to the author, along with that author's definition.

Re:OK, one more time. Agile is an adjective.

[plopez]

That's the point. "Agile" was never intended to be such a product. See the video. "Agile" as sold is not agile at all. Rather waterfall in drag.

Re:OK, one more time. Agile is an adjective.

[plopez]

What's your point? What are you driving at. I do not see any conclusion on the topic of "Agile" in your post.

Re:OK, one more time. Agile is an adjective.

[Aighearach]

What's your point? What are you driving at. I do not see any conclusion on the topic of "Agile" in your post.

Ah, OK. I'll consent to give you the additional lesson that you requested.

Points made in discussion include other types of thing than just conclusions.

You're welcome.

Re:Agile is bullshit

[HornWumpus]

50%? Optimist.

Re: Agile is bullshit

[Anonymous Coward]

Not any more.

Cue the ...

[cascadingstylesheet]

Cue the chorus ... "you're not doing it right!"

Should developers abandon Agile?

[endoflife]

Yes, they should.

When asked in an interview

[HighPerformanceCoder]

I say I have been doing agile for decades - since the turn of the century at least. But for me, agile means getting working software in front of users as frequently as possible. By working, I mean using some version of TDD and continuous integration to ensure you're not just serving up steaming shit to your users. No mention of user stories, pair programming or daily stand up scrums, which may or may not be appropriate for various circumstances. Agile is all about incremental development, and a conversation between the stakeholder and developer.

This answer is somewhat foreshortened over my previous attempt - for some reason slashdot lost my previous draft when I logged in.

He's Looking for Eyeballs...

[Anonymous Coward]

... cos eyeballs is how he makes money. He spoke at our organization and isn't really a dynamic speaker or terrific evangelist. His best days are behind him so he's deprecating the old buzzword and sell the new buzzword.

Re:Agile is bullshit

[geoskd]

50%? Optimist.

I wasn't counting the unemployed / permanently unemployed ones where the percentage is obviously much much higher.

If you don't know what to do

[Anonymous Coward]

GIVE UP and let someone else do it

Re:Agile is bullshit

[Tough Love]

Agile, the idea, is total bullshit. Its execu-speak at its worst. Just fucking grade-a unproductive hot air

Downmodded by a PHB with modpoints?

Re:Agile is bullshit

[Tough Love]

Nobody I have met has ever seen agile actually work. I have personal experience of a depressingly large number of projects where it did nothing other than annoy the engineers and waste their time.

By definintion, Agile is doing what works...

[greenwow]

so by definition it can't fail.

But seriously despite the asinine definition that is illogical that the Agile Manifesto gives to this garbage, it's ridiculous to ruin the lives of programmers to push them to complete work before one or two daily meetings. Where I work now, we have four daily meetings, and if you don't have something done then our CEO requires you to wear a pink skirt and sing Total Eclipse of the Heart. Also,. Agile requires that you intentionally ruin any long term planning since you don't think long-term but instead think of sprints. Making software is a marathon, but according to Agile you work people to death for two weeks, abuse them, insult them, insult them, and then repeat that process every two weeks. It's all about abusing people as much as you can legally without being charged with a crime.

Re:By definintion, Agile is doing what works...

[Anonymous Coward]

> pink skirt

For us, it was a Hawaiian grass skirt. If you arrived after 9am or was caught trying to leave before 11pm, you had to wear the grass skirt. Also, if you didn't work at least 12 hours on both Saturday and Sunday, but at least those hours were more flexible, you had to do the same. At one point, my entire scrum team of eight besides myself all had to wear a grass skirt every day for a week. After one of our board members that was PMI-SCP certified found-out people were working the minimum of 94 rather than showing initiative, he demanded several things that were even more humiliating than just wearing a grass skirt, like requiring us to wear it when outside of the office. After a couple of people quit because of that, he gave-in and didn't require people to wear skirts outside of the office.

Re:By definintion, Agile is doing what works...

[Anonymous Coward]

If you guys are being literal here about wearing a skirt, isn't continuously working 90+ hours a week enough humiliation? You're already pretty much saying "my personal time has no value and the personal life I do have is merely to support my ability to get to work in a functioning manner (commute, shower, sleep)." I can't think of a bigger insult than that.

Re:By definintion, Agile is doing what works...

[angel'o'sphere]

Which part of: "You are doing it wrong" did you not get till yet?
If you do 4 daily meetings: you are not doing an agile method but some bullshit.

Can't be so hard to grasp.

Agile requires that you intentionally ruin any long term planning since you don't think long-term but instead think of sprints.
That is nonsense. If you think like that, then: You are doing it wrong!

but according to Agile you work people to death for two weeks
That is nonsense. If you think like that, then: You are doing it wrong!

abuse them, insult them, insult them, and then repeat that process every two weeks.
That is nonsense. If you think like that, then: You are doing it wrong!
And you should have the guts to QUIT!

It's all about abusing people as much as you can legally without being charged with a crime.
No it is not, you simply are a moron or a troll or both.

Re:Agile is bullshit

[ShanghaiBill]

Agile is no better and no worse that any other way of doing business.

BDUF / Waterfall is way worse than Agile.

Re:Agile is bullshit

[Dog-Cow]

English's not your native language?

What did Agile introduce to the world?

[Anonymous Coward]

Incremental Software Development was around for 30+ years before Agile came along. What changed?

Agile was a salesperson's hip excuse to change his mind on a regular basis and call it "agile". The truth is that salespeople never know what the heck they want built and the biggest bang for the buck has to do with optimizing requirements (the salespeople) not the developers. We could build software 10x as far, but it'll still be the wrong software and it'll get thrown out. Agile does not change that. If anything, it helped things move in the wrong direction.

Wait... Agile was meant to be taken seriously?

[dskoll]

I always thought the Agile Manifesto was satire. You mean people actually took it seriously?

Re:Wait... Agile was meant to be taken seriously?

[Anonymous Coward]

You win "best comment of the day". I'd laugh, but it triggered PTSD from working in too many xtreme/agile/wtf projects.

Sure

[OneHundredAndTen]

Let's move on to the next fad.

On the other hand.

[fahrbot-bot]

"When 'Agile' ideas are applied poorly, ...

When are they not?

Re:On the other hand.

[angel'o'sphere]

I work with agile methods since 1993.
I only was in one company/project where they did everything wrong and in another project where the Scrum-Mistresses thought every "meeting" is a socializing event and needs to introduce a new "meeting conducting strategy", when I pointed out that this is not the job of a ScrumMaster, I got fired the day after :D
In other words: I do more or less agile projects since 25 years, and all went FINE! The best running project (from 2004 - 2008) was supposed to be integrated into SAP (around 2016). Obviously that failed (was basically impossible, and everyone involved should have known that). That was at a energy holding company ... they sold and closed off the sub company that was using the product and wanted it integrated. A management decision ... not a failed software project but bad management of an energy company, because that energy company does not grasp that _all_ modern companies are IT companies and rely on their software to have a business advantage and not on their power plants.

So bottom line, during 25 years of mainly doing agile software development I had less than 2 years of bad examples, the rest went quite fine. And that is why I say: "If you don't get it working: you are doing it wrong!" But most likely you would do every software development (process) wrong anyway, so: who cares :P

Re: Agile is bullshit

[Anonymous Coward]

Buzzy wrong. You obviously don't work in an environment that has implemented agile development methods. It is flawed from the ground up. The solution is easy, cherry pick the east low hanging fruit and hand that to the less experienced devs.
  Take the more advanced development requests and put those through a proper planning department and skip the business analysts the second the request is approved to develop using experienced devs and implement thru a more formal process. The low hanging fruit like fix how some form on some page behaves shouldn't wait for 10 years to be fixed as you'll see in most agile environments because that easy fix is assigned a low, non critical, unimportant number in the back of the line. Most of the time it would take a high schooler 30 minutes to fix the easy low hanging fruit and make 1000s of users happy. But some business analyst who can't code themselves out of a wet paper bag won't allocate the resources for the easy shit.

Re: Agile is bullshit

[Anonymous Coward]

E.g. scrum says that you should start with 2 week sprints. But after that comes retro and team can decide that w.g. a month is better sprint. The point of scrum is that the team decides.

Re: Agile is bullshit

[Anonymous Coward]

We used agile with 20 teams. 2 of those teams were fired after a couple of weeks because they were so bad. So agile does not make teams magically better but you will spot the problems faster and fix them.

Agile to me is like communism

[NotSoHeavyD3]

IE it sounds great in theory but when it comes time to implement it they NEVER implement it correctly.(Which is pretty much what gets said of communism.) Of course I find it telling that one of the big proponents has a communist sounding moniker of "Uncle Bob".

Re: Agile is bullshit

[Anonymous Coward]

Our project has 6 developers and about 20 managers. Our project constantly receives praises and we are delivering results that are about 10-100 times better that before. All was good when we had 0 managers but now they want us to use company rules which we have explained is impossible. And we also asked them to show a reference project that works better than ours with those rules, because we know there is not.

Re: Agile is bullshit

[Anonymous Coward]

Agreed. I actually blogged about the management disconnect with agile a couple of weeks ago and it got some traction fwiw.

http://brightball.com/articles/reality-driven-development-fixing-project-management-in-software

What?

[Anonymous Coward]

First, I think that everyone should know by now that Agile was nevera meant for developers, it was meant for management making developers do their Jobs and the management's job and passing responsabilities to developers, and developers will do whatever management push.

Second: Most methodologies do not hice importance to research and learning, they always think that pushing seconds will get things done, orden that everything can be solved with tools or consulting.

Sometimes management makes me think that developers and programmers are just type monkeys or that they were born knowing everything.

Re:Agile is bullshit

[Anonymous Coward]

Agile is no better and no worse that any other way of doing business.

BDUF / Waterfall is way worse than Agile.

It depends on what your business is. There is no One True Way.

Re: One problem: no normative definition of "Agile

[Anonymous Coward]

We are doing a project where problem is that requirements are very specific mandated partly by laws and legacy interfaces but requirements are still unknown. Documents have 50% wrong info and experts of domain don't know their domain or remember wrong or there are bugs in the law itself there is also old data that is corrupted but still needs to be saved and fixed. This makes architecture hard and it takes a long time to dig out the details and those details constantly change by new disciveries.

More than few months but necessary and worth the effort to stabilize current system..

Scrums Sucks

[Anonymous Coward]

There is a huge thread about it on Michael O. Church:

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

The blog post doesn't suggest abandoning agile

[Tony Isaac]

The original blog post, https://ronjeffries.com/articl..., doesn't actually suggest abandoning agile. Yes, those words are in the post. But hen Ron Jeffries goes on the explain that developers should instead...follow agile principles. I'm confused.

Self-organizing teams are over-rated

[Tony Isaac]

Ron Jeffries thinks corporate versions of Agile miss the mark because they "impose" a process. He says that each team should be able to use whatever process they want.

That sounds nice, kind of like free love in the 60's. The problem is that both produce unwanted results. For example, Extreme Programming was, and still is, a stupid idea. Sorry, two people can't use a single keyboard efficiently. Given total process freedom, some teams might choose this approach anyway. Boundaries must be imposed.

The fact is, a good team will be successful regardless of the process. A bad team will be unsuccessful regardless of the process. IT'S NOT THE PROCESS! It's the PEOPLE!

Hire the right people, and they'll usually have no trouble convincing management to go along with their proposed process changes.

Re:Self-organizing teams are over-rated

[Junta]

Hire the right people, and they'll usually have no trouble convincing management to go along with their proposed process changes.

Part of the problem is that management is always hoping that the right methodology will mean they don't need to hire the right people. That there exists some methodology that reduces software development to have employees as interchangeable as fast food workers.

Good management will always seek out the right people, and generally trust those people to do what they need and are happy so long as the results mesh with their ambitions. These teams are less likely to fret about compliance with buzzwords, so even if they are in practice honoring Agile principles (knowingly or not), they will be less likely to bother to claim it.

Bad management will always buy into the hype and label what they want according to hype and run it into the ground. These people will be obsessed with the Agile label and so Agile looks terrible.

Agile in reality isn't really much of anything at all. You spend less than a minute reading 4 phrases, that's it. Those phrases are not miraculous insight, they are just common sense, so if you're good, you don't need to even know those phrases are written down or labelled "Agile" or anything, it's just naturally your reality.

Re:Self-organizing teams are over-rated

[Tony Isaac]

You are so right! I'd give you mod points if I could.

Re:Self-organizing teams are over-rated

[angel'o'sphere]

For example, Extreme Programming was, and still is, a stupid idea. Sorry, two people can't use a single keyboard efficiently.
People who mix up "Extreme Programming" (a software development process) with "Pair Programming" (an optional 'habit') in discussions like this (note: it is not the same thing), are like people who mix up sand with bricks or cows with milk.

You don't belong into discussions like this as you obviously have no clue about software development.
What is next? Mixing up what a file is with what a database is? Or mixing up what ASCII is with a compiler that reads ASCII files and writes object files?

The fact is, a good team will be successful regardless of the process (arguable). A bad team will be unsuccessful regardless of the process (true). IT'S NOT THE PROCESS! It's the PEOPLE!
Exactly, the first paragraph of the Agile Manifesto :D emphasizes mine.

Re:Self-organizing teams are over-rated

[Tony Isaac]

Perhaps the authors of the Wikipedia article on Extreme Programming used bad references, but they too believe it involves pair programming:

https://en.wikipedia.org/wiki/...

Of course, most features of any methodology are optional. I do my homework and cite sources when necessary. Do you have a source that says Extreme programming does not involve pair programming? And even if I'm wrong, my point was that pair programming is (for the most part) a stupid idea. Instead of responding to the concept itself, you nit-picked definitions and disparaged the person. Those are characteristics of someone who does not have an actual argument.

Re:Self-organizing teams are over-rated

[angel'o'sphere]

Of course XP uses pair programming.
But pair programming is not the same or on the same level as XP, it is a small part.

Do you have a source that says Extreme programming does not involve pair programming?
I never said that.

my point was that pair programming is (for the most part) a stupid idea.
Well, there are two kind of people: those who love it and those who hate it. Calling that "stupid" is braindead. Chose what works for you and accept that other people chose what works for them.

Instead of responding to the concept itself why should I respond to the concept when is is not aware that he is mixing concepts on different levels, and like you "simply hates it". I'm not an evangelist. I'm a teacher/trainer/consultant. If you want to learn to drive but have a hate for the steering wheel, then you are somehow stuck, aren't you? I teach you to drive, not how to overcome your hate.

Corporate faux-agile is better than waterfall

[Tony Isaac]

I've lived through the waterfall era. Now I work in a large corporation that uses what Ron Jeffries might call faux-agile. It's Scrum, "imposed" by management. It actually works, the team is happy, and gets a lot done. I'll take this faux-agile any day, rather than go back to waterfall!

Re:Corporate faux-agile is better than waterfall

[Anonymous Coward]

I agree with it, agile is much better than waterfall.

Re: Corporate faux-agile is better than waterfall

[Anonymous Coward]

Liar, liar, pants on fire!

Re:Agile is bullshit

[Z00L00K]

The result in the organization where I'm located has been "it's not my fucking problem" approach that has surfaced.

Agile is a method that works on the lower level in an organization with a locally homogeneous environment but on higher levels where it transits to a heterogeneous solution then it's applied in a way that would cause a welder to be able to code assembly and do electrical wiring as well. That turns a box of sharp tools into stone age rock bashing everywhere.

Re: Agile is bullshit

[Z00L00K]

When you have a world of mixed maintenance and development the sprint idea is totally bullshit since it collects all work regardless of size into a "one size fits all" mentality and if it's a large job that has to be done that takes time then it's often postponed until there's time to do it and then it may be too late because that job is part of the OS platform that everyone uses in the platform and nobody knows why nothing works.

Re:Agile is bullshit

[Z00L00K]

I see that on the high level in a very complex environment waterfall is probably giving the most structured way of working. I deliver a car to be tested on the road and get back the problems found.

On the low level where I work with software or hardware components then a flexible approach is better. But it requires that the whole team works in a coordinated way and that everyone knows what the reason is for what their part is developed for and what it shall interact with. A drawing of a door hinge drops down to the person making that hinge - if he can see where it's used and knows by hand the history of previous hinges made and what limits he have he can look at the drawing to see if previous problems have been addressed and then make a prototype - or even more than one prototype with suggested variations to address certain historical problems that can be tried out in test fittings. It can be subtle changes like increasing the length 10 mm to make it more stable. It will of course have to go back to the person making the drawing that the longer hinge is more stable so it won't cause other pieces to be moved that will come later.

An organization should firsthand try to avoid the situation "Jack of all trades, master of none" - everyone knows a little about everything but lacks complete specialists on any subject. Especially in large organizations. A newbie may not have much knowledge of how their part fits in, they may be fresh out of the university and have a very general and generic knowledge, so starting somewhere would give a good start, then build up competence over time and move around if they find that another part of the organization is better for them.

Re: Agile is bullshit

[Tough Love]

The only agile that ever worked is NASA's space program launches, there each launch is was its own sprint, sometimes lasting years

And they didn't have any "agile" methodology to get in the way.

Re:Agile is bullshit

[Tough Love]

Agile is no better and no worse that any other way of doing business.

No, bzzzt, wrong, it's worse than nothing, it's a net negative for any project.

Re:Agile is bullshit

[Tough Love]

Reality is, of course, that those managers are fully aware where the problems came from

In their own minds.

Re: Agile is bullshit

[Z00L00K]

Agile mind set for working is the same regardless of if you design software or hardware.

But Agile is useless when shoveling manure - there's only one way to do it and that's start shoveling.

Re:Agile is bullshit

[Tough Love]

Careful reading of your post... good one. Tech management is a self propagating delusion, they want it that way, they keep getting paycheques for basically just wanking. If projects got finished all kinds of bad things would happen, like successful engineering leads getting promoted above them. It's bad enough that the engineers get paid more. God forbid they get recognized for competence as well.

Re: Agile is bullshit

[Anonymous Coward]

Funny how so many of the comments here actually fully support the blog post by showing that agile can be done wrong.

I think agile and Scrum can be a tool with which teams can define their own process and can continuously learn and improve the way they work. If done well, it can make them realize that the people in the team themselves can change things, instead of complaining about management.

It works best when management does not impose too many rules on how people work - although basic guidelines such as âeverything should be reviewed before it is deployed or shippedâ(TM) can still be necessary. Instead, management should help people realize they can make things better for themselves and that everyone should maintain an active role in ensuring they enjoy the work they do.
This imposes challenges for everyone involved as the organization grows, because at every step the easiest solution will seem to introduce a new management layer or new rules. For example, it could mean having to say no to a CEO that wants to change things, to creatively handle certifications and audits without imposing a detailed process, but also to find new ways of working that give more power to employees and does not create small exclusive groups in the process. It means you continuously have to fight these easy looking solutions and think of ways to solve the problems in a way that gives freedom to employees to choose their own solutions.

This approach means that some teams can do scrum, but others can do something else. As long as they can choose which process they like and they have a few basic checks in place to ensure quality, and as long as they keep learning and changing the way they work based on what they learn. It works for us.

In fact you could even do this in a more traditional organization. It means that you need to decide for yourself that you want work differently as a team, and start doing so. And that will mean conflicts with management and it will take a while with many small steps and changes, but the result can really be worth it.

Diametric opposition

[Anonymous Coward]

I've spent most of my life writing code and working projects some in hindsight I probably had not business attempting myself.

Before I begin work on a new project I collect requirements and use them to determine what tools I need to steal or invent in order to facilitate requirements. I usually spend months just on tooling.. writing meta programs of all kinds to facilitate anticipated flows, improving APIs and frameworks before any real work is done at all.

On number of occasions I've spent months doing nothing but thinking about problems and then designing complex systems to solve them in a generalized manner. This was out of necessity as piecemeal route to what customers want is simply beyond my capability as one developer to implement within the time available to me. Everyone wants everything and I had no choice but to find a way to give it to them.

These systems have over time have proven useful to myself and customers and I don't regret doing it for one second.

Everything I hear about Agile is sprinting and scrumming doing little shit, release often and never thinking holistically about what the fuck it is your trying to do. It seems to be designed for code mills working small projects for one off clients.

I am diametrically opposed to everything Agile stands for and refuse to waste my time working anywhere it is practiced.

Actually, this is exactly the point

[Cesare Ferrari]

So when the request came in to add a historic visualisation to the project, was this a new, out of the blue requirement, or was this always lurking as a nice to have feature that was hard, so had kept being pushed down the stack?

If it's a new out of the blue requirement, then there are millions of things that could have come along that would have been next to impossible to implement in the current system, but also, millions that would have fitted nicely (assuming there was some degree of thought and planning). The team should be able to push back on totally impossible to add features, and if that's not the case, then the company is not following any agile practice. You can't bolt it on at a team level and expect to see all the benefits. Turning it around, what sort of approach would allow any new requirement to be implementable?

Alternatively, it's been on the list of features and has kept been pushed back. This is then a team problem, and it's your responsibility to keep raising this. This is probably the most valuable part, getting visibility of the overall direction of a project, and being able to access and vocalise your concerns. If you didn't feel empowered to bring this stuff up, again, that's not agile.

So, badly implemented agile is a problem, as is badly implemented just about any process. Whether agile was the best fit for your project or for your company, that's a very different question, and agile is clearly not the right solution for everything, I've worked in plenty of secretive companies where agile is a problem as information is intentionally withheld from the developers, and this causes a massive mismatch which makes agile painful. If you company sees and understands these limitations, it can still work once you accept the inefficiencies.

Re:Actually, this is exactly the point

[mvdwege]

So, badly implemented agile is a problem, as is badly implemented just about any process.

If a process or methodology is that sensitive to implementation errors, I'd say it is broken, at the very least in the sense that it is trying to solve the wrong problem. It is at worst a sign of the the Techie Problem: trying to find a tech (in this case process) solution to a socai problem.

Re:Actually, this is exactly the point

[Anonymous Coward]

It wasn't in the original specification. They were working on an existing system which was an established product, but now they wanted to use new hardware and add in the new features. There was no mention of this feature in the original documents. Up until that point each window was its own application that only received data. Then they realized they needed a central database, which didn't exist due to the data flow design.

Re: Actually, this is exactly the point

[Anonymous Coward]

Agile apologist apologizes for Agile.

Re:Actually, this is exactly the point

[angel'o'sphere]

I've worked in plenty of secretive companies where agile is a problem as information is intentionally withheld from the developers
That has probably nothing to do with companies where agile but with information is intentionally withheld
Regardless what software process ... if the developers know not enough they can not design or architect, or even code.
What the funk has that to do with agile? Agile methods are ALL about an open backlog where everyone involved sees the complete backlog. If you don't have such a backlog, then:
a) you are doing it wrong (regardless of process)
b) you are not agile

Re: Agile is bullshit

[Cyberax]

Why? I develop services at my dayjob so we're doing both maintenance and development at once. Sprints work perfectly fine - you reserve some time for predictable maintenance tasks and then allocate the rest based on needs. The idea of epics/stories/tasks also maps quite well onto this model.

Good management vs. the latest buzzwords

[bradley13]

Agile is a good concept - I've included the Agile Manifesto in my courses for years. The problem is: Agile is no better than the people implementing it.

I've just witnessed this (again) in a recent project. The PM had just gotten a promotion, but he had to finish this project. He used Agile as an excuse to basically abdicate (or maybe he was always a lousy PM), and he let the developers and the customer talk together directly. The customer thought this meant that all of their ideas were flowing into the project every two weeks. The developers thought the customer was changing requirements every two weeks. The result was inevitable: a project that is 3/4 finished everywhere, totally finished nowhere, and is now likely to land both companies in court.

Crappy management is not saved by Agile. Given good management and a good development team, any methodology can work - pick the one best suited to the project and the people.

Re:Good management vs. the latest buzzwords

[Anonymous Coward]

Most project managers are useless. I've met one that actually documented what they were doing, why they did it and so on. Most won't even put the requirements of the week in Jira so we can see them on the agile board. They just want to use excel or something worse.

If you can't write down in basic english what something does, it's not read for the team to work on. It's that simple.

Re:Agile is bullshit

[bsolar]

Actually how the dev cycle reacts to the workload is a very good signal for the team "agility": basically, truly agile teams will shorten their dev cycle under demanding workloads, "faux agile" teams will lenghten it.

I worked in a "true agile" company with a 1-week release cycle. Under demanding workloads like rewrites or new big products, dev cycle went from weekly to ad-hoc, which basically meant "every day".

I worked in a "faux agile" company with 2-week release cycles. Under demanding workloads the dev cycle went monthly, or worse.

"True agile" developers have to master how to implement changes in small steps: increasing throughput means implementing more small steps in the same time. "Faux agile" developers don't master that and increasing througput ends up meaning increasing the steps lenght, defeating the whole idea of agile.

Said that, very easy to say, very difficult to master, especially if you depend on choices which are counter-productive to agile, which is very often the case in large enterprises.

TL;DR: if the dev cycle under demanding workload shortens you are doing agile right, if it gets longer you are doing it wrong.

derails because of laziness and job protection

[Anonymous Coward]

Agile is like communism: in theory a good idea, but the system quickly goes off the rails if the group or individuals do not behave in a 'good' way. First problem I often see is that analysis and design is skipped and/or not documented. The customer comes up with an idea in a meeting, this is put in a story ticket in a very simple sentence "as a [rolename] I want to do [interaction] to obtain [new feature]". But the details are never written down. Developers will write some unittests, but just enough to test some new functions here and there in different components. Testers and end users will go through a couple of scenarios by hand to test a new feature or bug. Imagine you arrive as a newcomer on such a project. What happens is that you need to be brought "up to speed" by a poweruser who explains what the application does, and for every ticket you take up you have to get extra information from your team members to get some more detailed idea of what a part of the system does and how it was implemented. Second problem I often see in "agile " projects is codebases that are very messy, with questionable design patterns, several half-finished attempts to do a high level restructuring, ownership of code ("I do not now how this part works, ask X"). Last problem I see often: self-organization gone wrong: Teams that have ran into trouble can get very defensive and have bureaucratic "definition of done" procedures ("a pull request needs to be approved by three co-developers", "unit test code coverage of all new code must be at least x% " ) or block any attempt to innovation using office politics. OTOH some teams have cowboy programmers that check in exotic libraries or "refactor" code (= have their own opinion about everything, throw away other peoples code and even think they now better how the business should work )

Re: One problem: no normative definition of "Agile

[Anonymous Coward]

Put it on the blockchain.

Re: Agile is bullshit

[Anonymous Coward]

And what have they proposed as an alternative? Doing whatever the fuck they like?

Blogspam

[Anonymous Coward]

Why does the link go to a blog post that describes a blog post? Just link to the original blog instead of the worthless infoq site that does nothing but regurgitate somebody else's article.

Lenin regrets that Communism was implemented wrong

[Anonymous Coward]

In other news, Lenin regrets that so many countries implemented communism wrong,
and made life worse for everyone instead of better.
Lenin is sad but hopes that these mis-implementations will not reflect poorly of REAL communism.

Developers?

[drolli]

Agile is not for developers, but for project management/execution. If a company lets the developer decide if they want to be agile or not, something is wrong.

"Agile" is a fad. Agility is the real thing.

[Qbertino]

You have to know what you're doing and why. There is no free lunch. Management expects it to come out of development because they can do "computer magic", but it wont happen. Agile Software Development methods try to mitigate the sideeffects, but if nobody plays along agility becomes a trainwreck.
You have to know what you are doing and agility has to be a part of company culture. If it isn't, if will fail, plain and simple.

Positive example:
Sipgate is a company that does it right.

Why it really worked

[Anonymous Coward]

The real worth of XP was in the fact that adhearing to extreme programming strictly, showed where the culture and environment needed changing to allow xp to work. But all that happened was XP got changed to fit in with current state of things.

Re: Agile is bullshit

[TJHook3r]

Agile is an approach, with rules. Once you water those rules down, you no longer have Agile! That's the danger of democratically deciding an approach.

Re: Agile is bullshit

[phantomfive]

What rules are you talking about? The agile manifesto specifically says, "we value Individuals and interactions over processes and tools." It sounds like you are too focused on rules, and have lost sight of what Agile truly is.

Don't need to abandon what you never adopted.

[Anonymous Coward]

I have always advocated running far away from any place that claims to practice Agile. It's always been bad.

Re:Agile is bullshit

[Tough Love]

Smells like some rotten middle manager with mod points scuttling around here.

Re: Agile is bullshit

[Tough Love]

Don't do shit that wastes engineering time, duh.

Re:Agile is bullshit

[Tough Love]

The fact that there are agile weenies slithering around slashdot doing downmods on every crtiticism pretty much shows you what the whole charade is about. Snake oil salesmen of yore.

Re:Agile is bullshit

[phantomfive]

BDUF / Waterfall is way worse than Agile.

Have you ever done BDUF or Waterfall?

Agile only works for new products

[Anonymous Coward]

If you introduce it in an organization which has to deal with complex, poorly written legacy code, it is doomed. You can't estimate anything, every task that is enforced by the agile system to be short and simple still takes ages, the developers run away.

Re: Agile is bullshit

[Anonymous Coward]

Scrum does have a strict set of rules. Agile does not and one of the key concepts is that teams get to decide things themselves. I think you might be confusing the two.

the problem is executives

[Anonymous Coward]

who want to tell all their executives buddies at the next conference about how they use the right buzzwords and have new filler for their CVs but in reality want it to basically be government level bureaucracy

like production deploys used to be something I'd do in about an hour on my own and in going on 10 years, never had a single problem

new VP comes in talking about Agile and that person's judgement is that now deploys should involve 6 other people and take all day

Re: Agile is bullshit

[Reverend Green]

No way.

I've worked with a ton of "agile" companies. All of whom produced shitty, bug-ridden, hopelessly insecure crapware with deskilled, devalued, demoralized developers.

And two vaguely waterfall - actually closer to Spiral Method - companies. Where the software was solid and the developers comparatively happy.

Theory and pontification aside, my limited set of empirical data strongly suggests that Agile(tm) is a supremely craptastic method for producing software.

Re: Agile is bullshit

[Anonymous Coward]

Found the PHB!

Re: Agile is bullshit

[Anonymous Coward]

Authoritarian turd bucket

Re:Agile is bullshit

[Anonymous Coward]

They are dominating this post. Slashdot is for managers now, not us.

Re: Agile is bullshit

[Cytotoxic]

I agree.

I think what he might be referring to is the old problem of "urgent but unimportant" stuff getting done before "not urgent, but important" stuff.

I had an executive who was particularly "imaginative" in his development requests. He was enamored of whatever he saw elsewhere an wanted one for himself. His requests were so fast and varied that he became frustrated that he couldn't have everything... so I made him give me his "top 3" list. Give me 3 things, and we'll work on those first.

So his team gets together and after more than a month of planning, they come up with a 7 item "top 3" list. And we start work on the top 3. Every week we were going to have a progress report. So they come to the first progress report meeting all excited. They have a new project... the most important one. It needed to go to the top of the list. So I named it "project zero", since it came before project number one.

A year later the executive was under some pressure and was angry that none of his "top three" requests of a year earlier had been finished. So I showed up at a meeting with the CEO and COO with a stack of change requests... 50 of them, one from each weekly meeting, where he signed off on "don't work on those things, work on this new request". Somehow he still didn't understand that he was the one makeing the decision not to work on his "top three" items.

He was the embodiment of the "ooh, shiny" approach to decision making.

Working with that guy in an agile environment really didn't make any difference. The only thing that would have worked for him was to have unlimited resources. That way he could have a whole new CRM every month, new websites on a weekly basis, new accounting packages every other month, etc. Surely that would have worked out for his team, right?

Re:Agile is bullshit

[Cytotoxic]

This is spot on.

Breaking things into the smallest increments and getting the most productive ones out into the hands of the users quickly is really important.

When I was working for a small startup, we released changes "as soon as they were ready". Sometimes we'd have multiple releases in one day. Managers ran into issues where they needed a new feature and we built it, right away.

Later, as the company became a big, publicly traded company, this became more difficult. We implemented SDLC controls, signoffs, treining, etc. Releases became monthly.

Nobody on the development team liked it. All kinds of crap kept getting stuffed into monthly releases. Things that they knew were not going to be used - manager's pet projects.

Agile came along and rescued them. The small teams were able to push back against managers with ideas that didn't match how people work - getting features that lower level employees needed to do their jobs implemented quickly.

Those small changes add up quickly to be major changes. And they can be rolled out without much disruption, unlike big, three month long projects with lots of changes.

It requires people who can think like that ... taking a long term strategy and breaking it up into tiny, incremental steps. And especially making each step a productive change. There are a lot of people who don't think like that.

Re:Agile is bullshit

[Anonymous Coward]

Those three principles are crap and that's why Agile is bullshit. Also, the process must be set by the organization, not the team, as the people on the team change while the organization must remain.

The manifesto was correct..

[Junta]

The problem was that the manifesto was common sense and stating plainly how good teams already behaved.

The problem is they and a whole lot of people *thought* that with a plainly spoken set of words, it would be possible to go out and fix the whole industry, which was and still is beset by a whole lot of nonsense in processes and tools.

They were half right, the short document that was easy to understand did resonate with a lot of people and the idea that the way things are being broken resonated with a lot of people, thoughout these organizations.

Two major problems happened. One is that the same traits that drove those teams to create terrible processes and abuse tools are still there, and to some extent doom those teams to always landing in the same place, perhaps changing terminology to comply with the fad (big-A Agile). Call their "status meetings" "Scrum", call their "requirements" "stories", "milestones" becomes "sprints". Change the words and 'poof' they are "Agile".

The other complicating factor is the tools and consultancy business. "Individuals and interactions over processes and tools" is not something that is a profitable stance. So that goes by the wayside and consultants revel in making money reinforcing the above behavior. Consultants know these companies ultimately are spending the money to feel better about the way *they* want to work, and they are happy to oblige. Enough change to be annoying and feel like *something* has changed, but leaving that organization structurally the same, the way management clearly had made it in the first place. On tools, well that is a mess. When asked if my team was "Agile" I replied "yes" (mainly in hopes to deflect the 'transformation initiative") and they asked "Oh, so your team has been paying for Atlassian software then?". Because we didn't happen to be using Atlassian, it was deemed we *must* not be 'Agile' and we had to undergo the bs training and migrate all our stuff to Atlassian tools and in general waste a whole bunch of time. Worse than that, they assigned folks to "help" us be Agile in an ongoing capacity, and demanded we declare 6 months worth of plans for Sprint content and get mad at us when we prioritize responding to a customer request over made-up dates for 'nice to have' backlog items,. When I point out "Responding to change over following a plan" was part of the manifesto, the ostensibly Agile-focused helpers say that's not part of Agile, it wasn't in any of their training, and that they got Agile certification so they should know.

Re:The manifesto was correct..

[angel'o'sphere]

the ostensibly Agile-focused helpers say that's not part of Agile, it wasn't in any of their training, and that they got Agile certification so they should know.
A "certified scrum master" course goes over two days, and can be abbreviated into one day if the students are prepared: there are hundreds or thousands of things a student might not know afterwards.

When I point out "Responding to change over following a plan" was part of the manifesto,
If they don't know that they are morons. The core principles of the Agile manifesto, Scrum, or Extrem Programming fit on a single page of paper, even with 2 sentences of explanation.

The "Atlassian Story" indicates the guys mix up process with tools ... probably the reason why old school CSMs use paper cards to track everything instead of tools.

Re:The manifesto was correct..

[Anonymous Coward]

probably the reason why old school CSMs use paper cards to track everything instead of tools.

Funny, the first time I got a contract to work on an Agile project, I was shown the 'war room' where a bunch of prorgrammers all sat at the same table and the wall was covered with colored index cards.

I thought to myself, "This is progress..?"

Re:The manifesto was correct..

[Aighearach]

Did they really think they could "change the industry," or sell lots of books and get lots of consulting business?

Does it depend on knowing who "they" were?

Re:The manifesto was correct..

[Junta]

It takes two days, one day if they are lucky to cover 4 sentence fragments, or to at least include them?

I doubt it's being moronic, and more the CSM training telling the people what they want to hear. It's very quickly obvious that the managers here *need* to have every little thing planned out way in advance, so they tailor the message to say that maniacally adhering to a plan regardless of changing circumstances is ok, so long as they are 'agile'.

The article spawning this does point out that there's a lot of random stuff branded Agile running about. Maybe he is sincere, or maybe he is trying to stem the tide of people saying Agile is failing them by invoking 'No True Scotsman' as a means for extending the gravy train, but either way that point is at least accurate: in practice Agile means nothing in the face of a lucrative consulting industry that has mangled it into a 'feel good about what you want to do and we'll bless it as Agile whatever it is'.

Re:The manifesto was correct..

[Junta]

I assume at least some of the folks were sincere and I like to stay on the bright side.

At first with the summary, I naively thought that Ron Jeffries perhaps was showing signs of being sincere in intent (I don't track the names of 'Agile' people, just the results), but then reading the article, it seems he may be more of the sell lots of books and consulting business camp (his message was not 'abandon agile' but doubling down and wrapping any problems 'finding true Agile' in a big 'No True Scotsman' circumstance, with no credible way of knowing in advance whether it's "True Agile" or not (the criteria seemingly being "if it works, it must be Agile, if it fails, it must not be Agile").

Re:The manifesto was correct..

[DarthVain]

Kind of makes me thing in terms of a Project Management analogy. I'm sure just about everyone has heard of PMBOK. While I think just about everyone would agree that following a general set of PM guidelines is a good idea and will help success. However if you tried to make everyone follow every rule from PMBOK verbatim, you get a bureaucratic mess where you spend more time adhering to rules than you do succeeding at whatever it is you are trying to do.

Similarly, looking at the Agile method and the things it tries to promote I think most would agree that there is value there for success. However, should you try and simply blindly follow all the Agile rules because that is what it says to do, I don't think necessarily means it is going to have a positive outcome.

As I mentioned in another post, on attending Agile training for the first time, it assumes a pretty rigid ideal of what "Waterfall" is, in that much or even most of the basic concepts of Agile were something we were already doing for years before we ever heard of anything called Agile. But by all means have daily morning scrum meetings with a scrum master for your two week sprints, success is guaranteed!

Re:The manifesto was correct..

[Aighearach]

You have a strange concept of sincerity; it was never any secret or scandal that they were selling books, or that the lessons were related to their consulting business.

Perhaps it is people who are anti-business who presume that sincerity must be about changing the world, who then hear the sincerity in their words and presume they're trying to change the world, instead of just understanding that their sincerity implies that they're making more money by following those principles.

The manifesto was written by a bunch of industry programmers who were vacationing together. It didn't come out of any sort of social movement, or anything like that. That's what I was implying when I asked, rhetorically, "Does it depend on knowing who `they' were?"

Yes please: throw Agile out!

[Anonymous Coward]

Agile is way too much dogma at companies ive seen it practiced at.

Re:derails because of laziness and job protection

[Junta]

Developers will write some unittests, but just enough to test some new functions here and there in different components.

Also will say that teams have a very bad habit of saying "100% coverage" and then saying "we don't need a QA team, auto testing takes care of all of it". To the extent that my team does unit tests, I don't claim that to management for fear that management will can the QA team, which is comprised not of programmers but people from the target industry, that give functional as well as "this was a dumb idea" feedback.

As to the rest, it doesn't really matter if it's called "Agile" or not, it's the same sort of things you would see in software development before Agile came along. It's the hellish behavior that the folks originally wanted to "fix". The reality is that a bad team will be a bad team, and no matter what they are told, they will find a way to create that same horrendous dynamic using the terminology to fit the "project management fad of the day". When someone sees this and tries to fix it with another promising sounding fad, it too will degrade to what you see today.

The original Agile was simply:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Which has always been pretty obvious to anyone.
The problem with the first point is *not* was company leadership wants to be true, they want processes and tools and to be able to toss aside one person for another at will. Also, as a consultant there's more money to be had selling them "Agile tools" than just telling people to work together. So branded-Agile tosses that.

The problem with the second point is that it requires developers intimately understand the user situation and to not be so lazy as to avoid doing the work. In practice "it can be fixed in documentation" remains the "easy way" to cheaply meet schedule.

The third point is simply unrealistic, sadly. Yes from getting a quality product, this is important, but that collaboration taken to the extreme will cause the scope of needed work to grow endlessly. This is of course ok for engagements that are also effectively "limitless", but for project-driven engagements this sadly doesn't work.

Responding to change is the one point everyone would *love* to claim to be a champion of, but managers are accustomed to forecasts, and deviations from plan break forecasts, and as such management really hates this. Of course so do many developers. It's distracting to react to changes in plans and some people just aren't wired that way.

Re: Agile is bullshit

[munch117]

Agile methods like Extreme Programming and Scrum have two sides: One side is that you get to be extremely flexible about where you're going. You get to work without a comprehensive up-front specification. Which feature you're implementing next can change at the drop of a hat. The other side is that in order to get away with that, you have to be extremely disciplined about the quality of code you produce. Unit testing, refactoring etc.

It's one thing to be flexible in how you do one side or the other. That's fine. But too often people claiming to do a flexible variation of "Agile" are just ditching major parts of the coding discipline side. But then you're not doing XP or Scrum, you're just cowboy coding.

Re: Agile is bullshit

[phantomfive]

As far as I'm concerned, scrum can fall into a river. Standups suck.

Re:derails because of laziness and job protection

[d0malaga]

Overall a great slashdot discussion, with interesting comments. As a programmer, who since many years work mainly as product owner in a reasonably large project (~100 devs, and some 100 more in related SAFE trains), I think you mention many of the problems I perceive we have. We've adopted SAFE on top of mainly scrum based ideas in an attempt to get teams to cooperate better. Of course there have been/are deadlines that are hard to meet while trying to balance new features versus addressing various "debts" we have since going live with the first customer. I wouldn't say we've derailed, it's still bearable.... and the issues are not mainly due to people being lazy or caring about keeping their jobs. In the end most people try to do their best given what they are told to do and what's measurable. It's more a combination of prioritizing (end user) features with a culture of not documenting requirements or design/architecture, and the impact from how of "agile" has been interpreted. At team level there are unit tests and DoDs, but cross team refinement/design, testing, integration, delivery is a challenge. Of course it would be a challenge with waterfall, RUP, etc too... but by pushing too much onto each "self-organized agile team" the whole setup/development has become inflexible and slow.

Random walk?

[Anonymous Coward]

An agile development loop
1) Build some sort of minimal, tested functionality.
2) Get feedback to see how it worked out.
3) Choose what the next incremental step in functionality should be.
4) Add the incremental functionality cleaning up any resulting cruft, test, and release.
5) Goto 2 in a short periodic interval.

I see two fundamental problems with this plan

First no two steps take the same time. By forcing a fixed interval either you cause either idle time, not getting done, or herculean effort to pull in the schedule. None of these are a good, sustainable development environment.

Second, complex system design is neither bottom up nor top down, it's both. This program seems focused on bottom up with a peephole looking at only the next step. This is certain to paint one into a corner. Some amount of planning (architecture?) might be useful to both prevent technical do-overs and provide the customer a better idea of how this next release fits into the overall desire. Of course if there are no clues as to where the project is leading, then bottom up with the peephole providing all the feedback it can is the best way to go.

Incremental development is a great old idea, but the agile process needs to be agile in itself. Without somebody wisely choosing the what and how of the next step, it will result in a random walk.

Agile in IT?

[Burgergold]

Anyone here have experience with Agile in IT? Not software development I was in a Lean/Agile large corporation and while Agile was implemeted very well in software development, a few years after they've tried apply this in IT. While some element worked well, some other couldn't. I've left this org a few years ago and now I'm living kinda the same thing somewhere else and again, I'm not sure Agile apply that well in IT. For example, deliver something quick instead of the final product. While this make sense to fail fast or deliver in smaller blocks, it often result in supporting 2 services doing very similar thing (file server, print server, proxy, etc.) instead of one, both being incomplete and finishing the new one is often pushed back while starting another quick delivery on another service.

Re: Agile is bullshit

[Anonymous Brave Guy]

For example, it could mean having to say no to a CEO that wants to change things, to creatively handle certifications and audits without imposing a detailed process...

And this right here is why a lot of "Agile" efforts are misguided.

Yes, for sure, hire smart people and let them be the experts at how to do their thing. Let them automate, test, develop in small steps and integrate often, if those things work for your organisation. Don't micromanage or dictate policy unnecessarily.

But remember that developers are usually not operating in isolation. They are part of a wider organisation, and the software they build serves a purpose as part of the organisation's wider strategy. That strategy is senior management's responsibility, and the idea that the developers should be fully aware of that strategy or have final authority over anything affecting the organisation is no more credible as the idea that the CEO should understand every line of code.

Re:Agile is bullshit

[arth1]

"True agile" developers have to master how to implement changes in small steps: increasing throughput means implementing more small steps in the same time.

A problem is that some work is monolithic in nature and cannot be partially released. This is particularly true the closer you get to the hardware side of things.
Agile fails when it tries to jump a chasm in three small steps.

Attempting to divide it into even smaller pieces isn't going to solve the inherent denial that some things cannot be split.

Nor that when something can be split, it doesn't mean it should, even under pressure.
Getting certifications for N components one at a time, for example, takes longer, costs more, and at the end, should you reach it, you need to get a certification for the whole anyhow.
Or you should not split security into a separate task that risks not getting done until there's been a release without security. That's bad. And I've seen it happen more than once.

Why isn't Sammy Coding?

[Anonymous Coward]

That has always been management question. They seem to think programming is all about coding when in reality coding is a small part of creating a large scale system. Agile is all about coding and that is what is wrong with it.

Kanban as an alternative

[sbjornda]

Google Kanban vs Agile for some interesting reading. There's even a hybrid called Scrumban.

--
.nosig

Depends on how they 'modify' it

[steveo777]

I've been Agile exposed in so many different ways I can barely remember what the hell Agile really is supposed to be anymore. The worst thing that can happen to developers is "We're running or own take on Agile", because "our own take" means "negatively effective".

I've got colleagues who have been required to go to 10-14 hours of ceremonies each week because they don't need a scrum master and PMs murder them with meetings where they demand to be heard for hours for no reason other than the PMs have nothing better to do with their time. Hell, I have colleagues in that situation right now where I work.

I know of other teams that (and this continues to be a complete disaster) that have an open door policy on requirements. Work gets tabled all the time because the manager wants the internal customers to feel super special and any new requirement that comes along can out-prioritize something that is 99% complete. Makes the manager appear great (somehow) but the devs look like idiots because they never finish anything. Thankfully everyone I knew in this company has vacated...

My boss had been running a relatively successful Kanban but was forced to move to Agile Scrum recently due to some guy's decision up the ladder. As a team we've made the transition relatively effortlessly in the mind space. I mean, before I'd assign work to my team based on requirements that may not fit into sprints, and it worked very well, since I knew their skills very well. I could time manage the whole thing without a lot of thought and everyone was busting out good work left and right. The only difference now is I have to fit all that into sprints, which makes things harder. I'm not supposed to give out anything that would split an iteration, and therefore I either have to spent a lot of time cleverly breaking up projects so that work can continue, or give out 1-2 day assignments just to take up my developers' time.

As I'm the senior/lead/architect of the project this is definitely the wrong way to do things. All the above reduces MY time to develop from about 36 hours a week to 25-28 because I have to play scrumbag, as well as all the other rolls, and we've been saddled by a tools that doesn't' work so well. But I do a damned good job insulating my team from PMs and other managers (ours is really good at wasting time, too, but at least understands Agile).

Re:Depends on how they 'modify' it

[Aighearach]

If you read the Agile Manifesto it is obvious that there are only two ways to use it; your own take on it, or as a cargo cult.

The truisms stop being true as soon as you take them out of the general context and try to force them into some sort of absolute definitions or processes.

If you start from the manifesto, it would only ever be predicted to be useful if your team was already successful and able to do the things it talks about without turning them into rigid policies or rules. And in that case, it is very useful ideas to think about.

It also might be uniquely suitable for consultants who bill hourly and mostly work on things like websites where the technical work is very very light, the client has a fuzzy idea of what they want, and the deliverable is mostly aesthetics. Other types of work the client might need to know when it will be done and how much it will cost, and they potentially might even already have a well-thought-out set of requirements that are highly technical in nature. In that case, planning before starting work can be highly beneficial; measure twice, cut once.

Re:Agile is bullshit

[HornWumpus]

Also wasn't counting: government employed, Javascript 'programmers', HTML 'programmers', web devs...them maybe 50%, maybe.

The whole problem with Agile...

[Assmasher]

Isn't its methodologies - it's the fundamental premise that it's a solution for everyone and every thing.

If you're building custom solutions for anyone (consumer, SMB, Enterprise) - Agile is likely your friend. Go with Agile.

If you're building a consumer facing web application - Agile is possibly your friend, it depends on how clear a vision you have. If you're not sure - go with Agile.

If you're building a PRODUCT (something you expect to use unchanged - excepting, of course, new additions and features) for the Enterprise - Agile is NOT your friend - but it is most certainly the friend of the integration team who will be deploying your PRODUCT into that enterprise.

Agile is hugely beneficial in the right scenarios - usually a scenario where the people who want something don't know what it is they actually want - they just know they need something fixed.

Agile is hugely detrimental in the wrong scenarios - for example when you have a company that hires 'Agile Product Managers' who are NOT domain experts; ergo, they have no idea what is or is not good for the target market verticals.

The other problem with Agile is that they created (somewhat accidentally) a strawman argument to establish themselves - that if it's not agile it's some kind of horrifying version of 'waterfall.' In other words, a black and white situation that's simply bullshit.

I've run teams where Agile was the only reasonable approach - and it worked well for us. I've run teams where Agile would have been a disaster for us and a waterfall/spiral type of approach worked well for us.

Tools in a toolbox people - just like operating systems, languages, patterns, testing methodologies - et cetera. Right tool, in the right place, at the right time.

Know them all (or as many as you can) - know their strengths and (sometimes more importantly) their weaknesses.

The really interesting time is when you build a startup and as the company matures, so does everything inside of it (technology, operations, organizations, processes, et cetera.) You may spend 90 days head down and very NOT agile, and then at seed round embrace Agile because it's right for you. You may be agile for a year or two until you close an enterprise deal - and then perhaps you re-evaluate using Agile - or modify it.

The point is (that I am very poorly making) - You need to know when Agile, and/or some particular aspect of Agile, is or is not appropriate for you and either embrace it or distance it. Don't fall for marketing hype, or the legions of people who cover their incompetencies (primarily in the world of Product Management) by hiding behind it.

I work for VA

[Anonymous Coward]

It is the most corrupt and abusive work environment I have ever experienced.

Our management is really big on "statements of corporate values" and "principles for moving forward." Translation: buzzwords and BS.

A couple of years ago "agile" one of their buzzwords became one of their buzzwords. Every year we are forced to watch a short video about our values (mainly because our bosses keep having to plead the Fifth Amendment to avoid prosecution). The video includes a short section on what "agile" means to us. That section makes it clear no one involved in the process has the slightest idea what agile methodologies are. They just like how the words sound.

Management has made it clear what agile means to them: Employees have to jump over many hurdles put up by management to accomplish anything for the veterans; employees will have to run around many roadblocks erected by managers to provide the most basic benefits to vets.

"Extreme Programming" suffered because it was a terrible name which conjured up visions of being thrown out of an airplane at 40,000 feet and trying to program a parachute on a laptop on the way down. "Agile Programming" suffers from being too good a name not to be co-opted by by every management drone who ever mouthed a buzzword.

At Veterans Affairs "agile" is nothing but a way to justify more abuse of the employees and use that abuse to cover management's corruption and incompetence.

Re:Agile is bullshit

[Gr8Apes]

First, this is the first headline I've seen where the answer is an unmitigated "YES!!!!"

2) The agile manifesto is good. (tbh it's actually kind of funny how many people are "doing agile" without ever having heard of the manifesto itself. Kind of hard to keep the core principles of the process if you don't even know they exist.)

What's funny is how Agile took notes of people that were successful in releasing software projects and got the message so entirely absolutely wrong. It never was "Waterfall" or "Agile". Strict waterfall works, but it is expensive. You may have heard some of the success stories, anything done for NASA for one. Working on such a contract can be excruciating and boring, and truly leads to the misconception that all programmers are merely cogs, because in such a project merely being a medium level syntax proficient programmer is all that's required.

But back to the point - truly successful projects in the internet time-based world required faster turn-arounds than waterfall allows. It requires active management leadership, and quicker feedback loops to make up for the removal of the heavy front-end design and specifications phase. The guys that wrote Agile seem to have glommed onto a few of the traits from successful projects without paying attention to the context within they were used. Just IMNSHO. (while I respect Dave Thomas, he was so so so wrong on Agile and from what I gather he seems to concur more with the underlying basis of what I stated above) So now we're going back to a more sane project leadership based system, or at least those that are successful have done so.

Re:Agile is bullshit

[Aighearach]

Agile is no better and no worse that any other way of doing business.

BDUF / Waterfall is way worse than Agile.

BDUF is guaranteed to be cheaper and faster if the designer is good enough and has the right environment, and its a bottomless moneypit on the other side because you can build something that doesn't work and the suits won't know they were had until the very end when it doesn't work.

Is your organization trying to do its best, or just trying to keep from landing on its face?

Re: Agile is bullshit

[Aighearach]

And what have they proposed as an alternative?

Work.

See also: http://programming-motherfucke...

Lack of decision making

[MoarSauce123]

Agile is perfect for those who cannot decide and won't commit. They can push decisions to the next iteration, call it agile and iterative, and never have to decide anything...and never get anything done. Other bad aspect of Agile is that many misread the manifesto and determined that it means "no documentation". I work in a supposedly agile dev team and I haven't seen a written requirement or any acceptance criteria in years. Devs just start building a ton of disjointed stuff that they have to rework later with great effort. It is baffling that we are still successful with this utter chaos.

Re:Agile is bullshit

[Aighearach]

Quit whining about mods, you posted some lame shit there are lots of reasons people downvote you.

Re: Agile is bullshit

[Anonymous Coward]

We try to organize ways to have literally everyone collaborate on creating strategic plans. It worked very well with a global development roadmap last year. Weâ(TM)re going to try it with budget and strategy next year. This is an organization with about 150 people within a larger company.

I would say it is very possible that everyone knows the strategy and can make decisions to support that strategy. I have no idea how well it scales beyond a certain size of organization.

Re:Agile is bullshit

[Anonymous Coward]

The only people who think agile development is a good thing are people who don't know how to code. I'm tired of companies dumping out patch after patch after patch, to cover up their own development mistakes. Just hire a real QA team and make a fucking stable v1.0 already. Stop with this trial-and-error kindergarten level development and pretending that your end users are beta testers.

Agile works for everyone but management.

[Anonymous Coward]

I will tell you about my company's dalliance with Agile:

Just shy of 2 years ago we went fully Agile with our (circa) 50 developers.
Our software improved significantly in that time with release after release having less bugs (I work in App support) Our Dev teams were much happier, we had barely any people leave (IIRC it was less than 5%)
The stakeholders were happier, as they were seeing less bugs (and more existing bugs squashed)
The Support team was happier as less bugs were creeping in and our platform was much more stable.

About a 9 months in and our first scrum master got fired - he stood up to management and pushed back whenever they tried to pressure the dev teams into taking on more work.
12 months in and the second scrum master leaves through frustration and management's "constant meddling"
(e.g. Dev showcase to product owner and senior manager.. At the showcase this manager tells the team to rework their code as the had "used the wrong names for the database columns, at another meeting he forced the dev teams to hard code some functionality to "get it delivered" on time - costing us much more work later on to remove it)
After the last scrum master left it was announced that we were no longer doing Agile and going back to something akin to what we had before.
Nowadays management promise the "moon on a stick" to customer in obviously unrealistic timescales that our dev teams now regularly fail to meet. Our code is far poorer than it was, many more show-stopping bugs, we have lost many of our "old guard" devs and the dev teams are now full of contractors who stay for 6 months and then leave for more Agile working environments.

For my company Agile worked really well for everyone except management who felt they had lost control over the development teams.

Agile is Dead -- Dave Thomas -- GOTO 2015

[Paul Fernhout]

For his current thinking: https://www.youtube.com/watch?...

After outlining the history of the creation of the Agile Manifesto, Dave Thomas outlines some basic problems with the Agile industry (including selling fear and also pushing complex IT systems to organize work that they can charge lots of money for). He says "the values have been totally lost behind the implementation". He says we need to distinguish between the implementation (Agile/Scrum/Lean/Kanban/etc) and the specification (Agility). He says "No rules are universal (except for this one)" and that "all rules are contextual". He espouses holding close to the value of "Agility" involving figuring out where you are, taking a small step towards your goal, re-evaluating and adjusting your understanding based on what you learned, and then iterating. He suggests choosing between alternatives delivering similar short-term value based on which keeps more options open to make future change easier -- outlining Dave's Rule of Design: "A good design is easier to change than a bad design." He calls for courage at the individual, team, and company levels to know you are going to make mistakes in order to find out what needs to be done -- and to work hard to make sure those mistakes small and correctable.

A shorter summary text version:
"Agile Is Dead (Long Live Agility)"
https://web.archive.org/web/20...
"The word "agile" has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products. So I think it is time to retire the word "Agile."

I've collected more related ideas on this High Performance Organizations Reading List:
https://github.com/pdfernhout/...

Re:Agile is Dead -- Dave Thomas -- GOTO 2015

[Gr8Apes]

Honestly, I my opinion of Agile when the manifesto was released was that someone had outlined the core of what I was doing followed by the realization that they had only taken the highlights and then totally missed the details. In fact, the things Agile promoted were exactly the things I struggled against project after project: kindergartners let loose without supervision. It's not that everything Agile states is bad, it's that Agile as a package totally and completely fails anywhere and everywhere it might be applied with one possible exception - the initial release of a POC. FWIW, I'm currently unwrapping yet another originally Agile project, this one truly makes me sad. It resulted in a DB that is inherently broken in its current state and various pieces of data will be lost because it's meaningless and useless in the current concept. Only with Agile could you get this screwed up.

Re:Agile is bullshit

[angel'o'sphere]

Agile is no better and no worse that any other way of doing business.
Waterfall: I analyze 3 month, I design 3 month, I implement 3 month, I test 3 month. After 12 month I deliver a product that is no longer adequate for a market that has changed over the course of said 12 months.
Agile: I deliver after ~6 weeks a working, tested, approved, subset of the project. Every ~6 weeks I can change course, change the scope of the project, change priorities of features. Heck, I can cancel the project after 3 sprints because I realize: the team is to slow, it will take them 18month, which takes to long, or is to expensive.

First approach has the risk of sinking a HUGHE amount of money. the second approach has the risk to sink a considerably smaller amount of money. That is the reason why most modern SD is done agile (or abuses agile by 'doing it wrong').

The simple reality is that 50% of the software developers out there really should not be developing software because they just plain aren't good at it.
That is unfortunately true for every job.

Re: Agile is bullshit

[angel'o'sphere]

my limited set of empirical data strongly suggests that Agile(tm) is a supremely craptastic method for producing software.
Then you neither understand Spiral Model nor Agile Methods ... perhaps you want to read up again what their core principles are, moron.

Re:Agile is bullshit

[angel'o'sphere]

If your "faux-agile" team managed to release working software successfully every two weeks, and had reasons to increase sprint time under pressure: then it was superbly agile and no faux at all.

And then again: if you release weekly it does not indicate at all that you are agile. It only indicates: you are releasing weekly.

"True agile" developers have to master how to implement changes in small steps: increasing throughput means implementing more small steps in the same time. "Faux agile" developers don't master that and increasing througput ends up meaning increasing the steps lenght, defeating the whole idea of agile.
You are an idiot. You do not value people at all. You treat them like machines. Worse is: you apply your own metric when a person is successful and when he is a true versus faux agile developer, actually you are an asshole.
You are exactly that where every guy here in the thread is talking about: you treat developers like slaves, press them to work harder instead of letting them work smarter. You failed to grasp what agile is about.

TL;DR: if the dev cycle under demanding workload shortens you are doing agile right, if it gets longer you are doing it wrong.
If your workload gets more demanding, your organization/company is doing something wrong: e.g. they forgot to hire more developers.
Shortening the cycles increases the "residual load", like wasted time in sprint planing, sprint reviews and sprint retros, integration testing, acceptance testing etc. The shorter the sprint the more relative time you spent in meetings and the less relative time you actually do work. You got all this completely backward. If your team struggles to deliver features every sprint, then you have to lengthen the sprint period, not shorten it. You are simply an complete idiot.

No magic bullets

[Anonymous Coward]

Software engineering is littered with failed magic bullets. Fact is, devising good algorithms and implementing them correctly is beyond most programmers.

Confidence is not Competence

[Anonymous Coward]

my limited set of empirical data strongly suggests

Has there ever been a more insightful and simultaneously less self-aware sentence uttered in all of history?

That's the story of your entire goddamn life. Profoundly ignorant and still absolutely sure of your conclusions.
Confidence is not competence pastor peen.

Re: Agile is bullshit

[Nocturna81]

And you yourself fall for the faux agile: that you value one thing over the other doesn't mean the other thing isn't important anymore. But if you have to choose you choose interaction over processes and tools. In practice this means you stick with a process, unless it means it stands in the way of progress and / or interaction between people. Then you dump it. A process isn't inherently evil, see also: the scrum process

First, define Agile.

[Anonymous Coward]

Agile is a buzzword for foolish managers to believe will save their companies. But in reality the definition for Agile should be "just do it and we'll make it up as we go". Great planning it isn't. Great management is never there. Simply put. It's a rodeo for the cowboy programmer.

Re:Agile is bullshit

[molarmass192]

There are an awful lot of lower tier ex-programmers and ex-program managers who shifted to selling Agile panacea and Scrum Master certificates. It's a guaranteed they'll fight like hell when the charade is exposed and their jobs / billings are under threat. It's all a scam as soon as someone who's not a core developer gets brought into the mix. It's an even bigger scam if points get corrupted into something billable. Estimation is an art, not a science, Agile gives it an air of science with nice round numbers that can be multiplied by dollar amounts and plugged into Excel. We may be able to fix a lot of what is wrong with Agile by replacing the numbers with emoji, otherwise it's just a repackaging of the same old project management accounting that has existed forever.

Re: Agile is bullshit

[Reverend Green]

Theoretical principals over observed data! Yeehaw! If Agile(tm) doesn't work for you, You Aren't Doing Agile Right(tm)!

Yes....because

[Stubbyfingers]

Customers are tired of being beta testers for your broken code

Re:Agile is bullshit

[Hognoxious]

You are simply an complete idiot.

Pure gold.

Pure comedy gold, that is.

Re: Agile is bullshit

[Hognoxious]

Theoretical principals

As opposed to practical headteachers?

Re: Agile is bullshit

[Anonymous Coward]

The double edged sword of one name for all and this great simple name for a skill that means so many different things as the crowd using it grows. If an organization is successfully productive with a sw dev process leave it alone. You wonâ(TM)t live long with biz guys shoving thinly descriptive requirements over to dev groups and getting the details right to meet market needs.

But agile or die is also a quick way to die and can restrict organizations bringing talented recruits who shouldâ(TM)ve studied the Agile bible and quote chapter and verse just to be considered. All processes will morph into something less than acceptable and assured over time.

Just keep trying to work with something that works for your companies or projects success..

Re:Agile is bullshit

[Tough Love]

My comment was anti-agile, which according to you makes it "shit". Just fuck off.

Re:Agile is bullshit

[Tough Love]

What you said.

Re:Agile is bullshit

[Tough Love]

Managers obviously have more time on their hands than engineers for lurking and reading Slashdot, just building up mod point probability and waiting to pounce on agile articles, or anything that might expose them.

Q: Abandon Agile? A: Yes

[Anonymous Coward]

Agile software development is rarely practiced correctly. In my experience it's another buzzword for companies to put on their marketing materials:

• We don't have a proper scrum master.
• Our "daily" stand ups happen maybe three days a week.
• We almost never do retrospectives, and
• We never, ever correct or implement any of the issues identified in retrospectives.

IMO Agile is the excuse our company uses for not having proper documentation, development and (especially) testing practices. It seems to be the same with every other company I've heard "practicing Agile."

Yes, but only after 6 months

[whopis]

of committing lots of resources to it and wasting a bunch of time.

At least that is what seems to be popular nowadays.

Re: Agile is bullshit

[Hognoxious]

They nouned it?

Re:Agile is bullshit

[bsolar]

You are an idiot. You do not value people at all. You treat them like machines. Worse is: you apply your own metric when a person is successful and when he is a true versus faux agile developer, actually you are an asshole.

First of all, learn to disagree without insulting others.

Second, learn to read and disagree on what the other person actually claims. I never claimed anything about personal success or whether a developer is good or bad, be it agile or not. I actually never claimed agile itself is a good thing.

What I claimed is that if you want to be agile and what to figure out if you are doing it right, checking how the dev cycle reacts to changes to the workload is a good metric.

If your workload gets more demanding, your organization/company is doing something wrong: e.g. they forgot to hire more developers.

Organisations cannot predict the future, even assuming they are good at planning. Furthermore, everyone makes mistakes, including those who plan. This can and will happen to most developers. It's definitely not their fault, but I never claimed it's a good thing or something I want, I claim it's reality.

Shortening the cycles increases the "residual load", like wasted time in sprint planing, sprint reviews and sprint retros, integration testing, acceptance testing etc. The shorter the sprint the more relative time you spent in meetings and the less relative time you actually do work. You got all this completely backward. If your team struggles to deliver features every sprint, then you have to lengthen the sprint period, not shorten it. You are simply an complete idiot.

Stop thinking that agile means only Scrum, especially Scrum as implemented in the typical large organisation. Of course if you implement a methodology with high overhead per dev cycle and with a high integration/deployment/release cost, increasing the cycle is going to hurt. Maybe it means you are not as agile as you think, which is exactly my point.

TL;DR: stop insulting others, stop assuming I place blame or judgement where I do not, stop thinking Scrum is the only agile methodology and that Scrum as usually implemented in large organisations is actually a good example of agile (it can be, but usually it's not).

Re:Agile is bullshit

[Jack9]

> The more parts you split something into, the greater the overhead becomes, at all levels.

Organizations are already split at all levels. Formalizing the overhead is a net good.
I don't understand how this is misconstrued. There's still chaos, but it's in smaller groupings.

Re: Agile is bullshit

[phantomfive]

And you yourself fall for the faux agile

No True Scottsman, eh? Let me explain to you how you got it exactly backwards:

In practice this means you stick with a process, unless it means it stands in the way of progress and / or interaction between people.

First you have to focus on individuals and people. Then if needed, you build processes to support them. The entire focus is on the people, not on the process. If a process doesn't do that, you dump it.

A process isn't inherently evil, see also: the scrum process

Don't think of it in terms of evil. A process inherently has a cost, and so does Scrum. If for some reason you insist on using Scrum, there is one way to do it right: and that is to use it as a tool to increase the skill and independence of the developers. If you're not doing that, you're doing it wrong.

Re: Agile is bullshit

[phantomfive]

All processes will morph into something less than acceptable and assured over time.

That's an interesting point.

Agile = Short Term Thinking

[Anonymous Coward]

Agile is all about small steps and short term goals.

What can you do in 1 day or 1 week:
You cannot write a Compiler in 1 week.
You cannot write a Database System in 1 week,
You cannot write a Game in 1 week.

In fact there is practically NOTHING that you CAN write in 1 week that will make a profit for the company that is paying you to attend all of these Agile Scrum meetings.

The only thing you can do in 1 week is small enhancements for existing products.

What happens when some other [smarter] company spends the year or more needed to write the next social media site or killer app.

Answer: YOUR company goes out of business.

Blame it all on Agile and short term thinking.

Re:Agile = Short Term Thinking

[Anonymous Coward]

I'm not a big fan of Agile, but you're totally misunderstanding the "sprint" principle here.

Nobody expects the team to finish the project in a week; the goal of a sprint is to get to the next milestone - and even in waterfall, you have short-term milestones you have to meet before you get anywhere near finishing.

Some of the actual goals of Agile principles from the manifesto are:
1. not get bogged down in processes
2. not let concerns of the team go unaddressed
3. not let "feature creep" get out of control
4. don't let changes in the spec catch you by surprise
5. listen to the customer and meet their needs
6. deliver a working product at any stage in the process (even if not feature complete)

These are all admirable goals, since these are the most common issues that slow product development or even kill a project.

Whether Agile is the best approach to solving those issues is still up for debate (see TFA).

Re:Agile is bullshit

[angel'o'sphere]

Pointing out that one is an asshole, is not an insult.
It is an important realization. The sooner you realize the other one is an asshole the more easy you can treat him or avoid him.

The way he talked about "true agile" and "faux agile" teams, clearly shows he does not value other human beings, hence he is an asshole.

Re:Agile is bullshit

[Anonymous Coward]

> Pointing out that one is an asshole, is not an insult.

Yes it is, asshole.

Agile is worthless

[Anonymous Coward]

Maybe small projects can be managed with AGILE, but anything with more than 10 developers, the wheels come off real quick. And its based on management wanting to slave drive the developers into a time box that in most cases is impossible or unreasonable. Next the process is always bastardized into some other form that is usually reflective of an out of control scrum-master, also playing (poorly) architect. Not one single project I have worked with AGILE has been a success, it is usually abandoned and waterfall takes over.

Re:Agile is bullshit

[bsolar]

There are a lot of instances where a team can actually split a “monolithic” task into smaller pieces successfully. In my opinion being able to do so is a key requisite for being agile. Note that there is no shame in “not being agile” IMHO.

In the cases you actually cannot (or should not for whatever reason), maybe an agile methodology is not the best tool for the job in the first place. Again, no shame in not using an agile methodology if it’s deemed unsuitable for the task.

Re:Agile is bullshit

[bsolar]

Let’s not be ridiculous. Insulting others is still insulting others even if the insult would happen to be the truth.

Abouth the merit of your arguments: nope. A team being “true agile” or “faux agile” bears no prejudice on the quality or value of the team. A very good team can very well fail to implement an agile methodology well for a lot of perfectly valid reasons and there is no shame in that.

“Faux agile” doesn’t mean the team is bad or not valuable: that’s entirely your own misrepresentation of what I’ve written.

Re: Agile is bullshit

[Nocturna81]

I don't quite see the no true Scottsman fallacy I made but it doesn't really matter. Just replying to say i agree with your reply, and have in fact made the point more eloquent than I was able to make. So thank you

Can't even get a job without agile

[zwarte piet]

I see you have no experiences with scrum on you resume. Why is that? Well my previous employers had no use for eleborate systems like that and it didn't exist before I got there. Writes down: *Knows no modern development techniques. Thanks for your time. Don't call us, we'll call you.

Re:Can't even get a job without agile

[Actually, I do RTFA]

I see you have no experiences with scrum on you resume.

Why would scrum or agile be on your resume? It's like listing all the languages you've programmed in.

Nietzsche says

[Hognoxious]

Nietzsche says that if they do, agile should abandon them.

Re:Nietzsche says

[Anonymous Coward]

Oh, blow it out your ass, Howard!

Re: Agile is bullshit

[phantomfive]

Great! If you have any other disputes with what I've written, let me know. Next time I won't accuse you of a no true Scottsman fallacy.

Lightweight Agile

[JCaptainP]

I've always referred to the poor implementation of agile as "lightweight agile." Typically, I see teams start the agile process with good intentions, yet just implement a hackie scrum implementation. This inevitable leads to the "get shit done" method of software development. Managers, chickens, chiming in with ad-hoc requests or screaming faster. Plus, lightweight agile, lead to people getting away w/ not doing work - typically poor performers. If you're not metric driving with your agile implementation your not doing real agile.

Re: Agile is bullshit

[nasch]

There's a good chance your organization is doing them wrong then.

Re: Agile is bullshit

[phantomfive]

Heh, the standard answer of Agile advocates everywhere.

Re:Agile is bullshit

[nasch]

There are a lot of instances where a team can actually split a "monolithic" task into smaller pieces successfully.

If by monolithic with quotes around it you mean not actually monolithic, sure.

Re:Agile is bullshit

[bsolar]

To be more precise with "monolithic" I mean a task which a team considers monolithic, but actually it's not and another team might break down. That's kinda the point I was making: the more "agile" teams usually employ a lot of strategies to break down these kind of tasks. Less agile teams tend to do the break down only in the simpler cases.

Yes

[CoolDiscoRex]

Agile in the hands of managers is a disaster, and its managers who obsess over it the most. Agile is belng used by managers to focus on the box. Everything has become about the box. Meeting Sprints with mediocre code > slipping to produce quality code. Don't track down the bug if it will mean you miss a sprint, try to work around it instead. Success is measured by hitting these points. Even if the task hasn't been done before.Estimate how long it willl take and be accurate wi4th your estimates! Yeah, Agile has been co-opted by managers and TPMs. At this point, everything regresses to this paradigm. It's the corporate way, and the beancounters ultimatey control everything. No matter what the supposed intent is.

Re: One problem: no normative definition of "Agile

[CoolDiscoRex]

To a manager, the solution to all problems is more management, Otherwise, what their purpose be? To an engineer, the solution is general more time/resoruces. Corporations manifest decision-making with managers. Therefore, the solution to problems will continue to be more management. Management says you cna't miss the scrum. Oh no, cna't miss the scrum. Heaven forbid. Are head-down in a critical section of code and uou've finslly formed a mental picture of the problem? Sucks to be you because it's time for the scrum, snd if you miss the scrum, pretty soon others will miss the scrum, it'll be chais, it'll. be anarchy!

And so we serve the process first and foremost.

Re: One problem: no normative definition of "Agil

[CoolDiscoRex]

sorry for the typos, i had to complete that post before standup this morning

Re: One problem: no normative definition of "Agile

[CoolDiscoRex]

Asking people to estimate how long a task will take, when that task has never been done before (at least in the org), is concentrating on the box rather than the task, and it leads to sub-optimal outcomes. IMHO.

Re:Agile is bullshit

[angel'o'sphere]

A very good team can very well fail to implement an agile methodology well for a lot of perfectly valid reasons and there is no shame in that.
And what would that mean for a "faux-agile" team?

Sorry, if a team can not implement an agile method over the course of half a year: it is not a good team, and/or its members are not good software developers.

Re: Agile is bullshit

[Anonymous Coward]

Theoretical principals over observed data!

You misspelled anecdote. Funny how you lurve yourself anecdotes that confirm your biases, but stand ready to police any that hurt your feefees.

Management sees Agile as the latest craze

[Anonymous Coward]

Agile doesn't work because most management teams embrace it as the latest management buzz word. Not only do they not understand it, they make no effort to do so. In fact, they drive their people to embrace Agile, and then they continue to demand status quo in management processes, organization structure, and reporting mechanisms. And when the do commit to Agile they often demand it be "modified" to support various sacred cows, dooming it to failure.

In my experience, no sizeable legacy enterprise has successfully implemented Agile, and that is a shame.

Re: Agile is bullshit

[nasch]

Very true!

Re:Agile - no planning and we'll get great results

[Frobnicator]

Partly true. That's the fourth agile pillar of responsiveness is more important than strict adherence.

I try an analogy of travel plans for a large group event. Building a big travel plan for everybody to get to the party won't work: people are coming from all places, some from home, some from work, some from distant cities. Instead, clearly communicate the destination and let each traveler be responsible for getting there.

Agile software DOES need planning. Everybody needs to understand what the destination is going to be. However, the plan needs to be flexible, responding to changes versus following the plan.

When you're driving and you encounter construction you don't follow your GPS's directions to drive through the construction barrier or off the cliff. You reroute because you value responding to change over following the plan and you understand that sometimes you need to deviate from the plan. But that doesn't mean you ignore your final destination. You may not follow your planned route but your destination remains the same.

Going through the manifesto... (1) We want everyone to be at the destination, and we care more about the fact that the people are treated as people than that they be there; if someone needs accommodations we make the accommodations because people are more important than process. (2) We want to make sure we have the destination. If the event were a big party it would suck if everyone got there and we discovered a a bunch of todo items like "rent the venue" and "hire the caterers". The plans are nice, but we need to actually make progress toward the destination rather than just making progress towards plans. (3) Helping people get to the destination is more important than details of how they get there. If individuals have different needs in order to get to the event, try to accommodate those needs. (4) We should help people reach the destination following whatever route works for them. If they need to change their route to reach the destination we should help them.

All of this is predicated on having a clear destination that everyone understands. When I've seen Agile fail that's been the biggest failing, there was no shared understanding of what was expected. When I've seen Agile succeed it was when everyone (or at least the key people) had a clear shared vision of the destination.

Kill it

[cshark]

Every "agile" house I've ever worked in has been complete chaos. The process is never implemented fully, the pieces of agile that are the most important are never there, and all it ever ends up doing it leading to more open panel free form meetings that run for hours, which means less development time on any given project. It's a joke. Needs to go.

Re:Agile is bullshit

[Areyoukiddingme]

After 12 month I deliver a product that is no longer adequate for a market that has changed over the course of said 12 months.

If the "market" you were chasing is gone in 12 months, it wasn't really a market to begin with. It was a stupid me-too fad you should never have wasted a second of time on after you got off the toilet.

How would this not work?

[cshark]

I think the problem with Agile, is that there's a language barrier with it.

People just don't speak it. So, I've taken the liberty of translating the Agile core principles into plain english so that common developer folk can understand what's being said when people talk about this stuff. I think using these principles, we'll all find ourselves being more productive, and building cogent end to end solutions and rich synergies in the enterprise.

1. Tell the customer what they want to hear.
2. Be disorganized and chaotic.
3. Pretend you’re working.
4. All tasks will either be written by or for idiots.
5. Let the loudest most incompetent people run the show.
6. Determine how many meetings your developers are capable of sitting through without losing their sanity. Require them to sit through twice that number of meetings.
7. Make sure the software works well enough for superficial demos at the end of the sprint is the primary objective.
8. Tell everyone about how hard you’re working.
9. Feign a commitment to excellence.
10. Maximize the amount of things that never get done — super important.
11. Have you ever seen Lord of the Flies? Yeah, like that, only in business casual.
12. Have meetings where you discuss your feelings.

Re:Agile is bullshit

[angel'o'sphere]

Oh the nitpickers again ....

Might be true might be not true.
At least that is what you learn in university, the cycle of "idea" to "put on market" is in Waterfall based processes so long that you have a high risk not to meet market demands.
And the way how long running development projects go is: they have usually no interim releases at milestones, but a big bang at the end.
If you had read any books about it, then you knew roughly 50% of all traditional projects fail with "out of budget", "out of time" or "not delivered at all", because of long feed back cycles from "idea" to "delivery".
Agile methods propose to have short feed back cycles and releases every iteration/sprint and have iterations/sprints much shorter than traditional milestones.

Can't be so hard to grasp.

Re:Agile is bullshit

[Anonymous Coward]

You can distill the issue down to this. Agile is a development process, not architecture or design. Architecture and design can benefit from agile by correcting mistakes early on, but there should be very few fundamental mistakes.

In other words, Agile is about deferring and making choices about where to place extra walls and what color to paint them, not changing one's mind about where to place a load bearing wall and what materials you made the frame with.

Re:Agile is bullshit

[Anonymous Coward]

The whole point of programming is breaking problems down into their orthogonal parts, which is required to do single point of responsibility. If one team can break down a "monolithic" part that different team could not, then the one team is incompetent. It's not a lack of skill, but a lack of reasoning. Or in the words of my brother when I describe the same situation, "how do those people still have a job?".

Re:Agile is bullshit

[Anonymous Coward]

In other words, Agile is about deferring and making choices about where to place extra walls and what color to paint them, not changing one's mind about where to place a load bearing wall and what materials you made the frame with.

So essentially it is merely decorative GUI bullshit? Thanks for the clarification!

Re:Agile is bullshit

[Anonymous Coward]

That's not my experience.

Agile is a development tool. If you skip architecture and design, you or some other poor soul be stuck supporting the project. We call the later "throwing it over the wall". My team dog foods our projects and we do not hand it off until we feel it's intuitive to use and diagnose. If ops can't figure out a problem in more than 10 minutes, they can contact us and we'll fix it to be obvious next time. Our team is on very good terms with Ops and Admins. No other team can claim the same.

I find focusing on quality is the fastest way to finish a project. But if you don't know what you're doing, then throwing crap at the wall is the best way to at least get something done. There are valid reasons for not knowing what to do. If you're working with a customer that has as a very abstract concept of what they want, getting something for them to review early and regularly is very important(agile). If you're making a library and setting up infrastructure for UX programmers to use, you don't need feedback, there is only one correct way to do the job and it should be obvious. Do it once, do it right.

What I've seen is most "agile" teams create balls of mud. They start off "fast" but with in 6 month to a year they've slowed to a crawl trying to constantly fix issues. I can't fathom the concept of throw away projects like you're talking about. UX projects cannot change too quickly because customer's complain to even the slightest of changes. Infrastructure projects should be flexible enough to be extended and abstract enough to have the implementations changed without affecting higher code. Could you give an example of a class of projects where the market changes so fast that there is zero reusable code?

You don't build fighter jet systems in Agile

[kriston]

You don't build fighter jet systems or railway control systems in Agile.

Software quality is not a crime.

Agile Shmagile

[Anonymous Coward]

Agile, Spiral, Waterfall, blah, blah, blah, blah. Whatever. Yaaaaaaaawn.

Here we all are with the same unsolved problems (since the 1970s):
1. Businesses can't express requirements, and engineers can't elicit them.
2. No-one knows how to formally validate or verify.

Mind you, that mess generates enough dollars to go around for everybody so why try harder?

Re:Agile is bullshit

[Aighearach]

Nope, that just shows you're an idiot who substitutes attempting to identify teams for thinking.

Your comment was fucking stupid, I don't give a rat's ass which "side" you're on. I said it was shit because it was uninteresting and uninsightful, not because you were wearing the wrong color shirt.

Whinging about mods guarantees you were in the wrong, so you have nowhere to argue from. Welcome to slashdot. As a new kid, please fucking learn that you don't whine about mods.