I wouldn't be surprised if that author saw or even experienced most or all of what he wrote about. But I have experienced nearly none of it. It seems plausible that Agile/Scrum could be used that horribly.

I'm not an Agile fanboy. Fighting Agile fandom or just making fun of it is not uncommon for me at work. This is an annoying part of Agile in a lot of places, but I tolerate it because I can also use the "fan" aspect to ease adoption of process improvements (and because this and other negative aspects of Agile don't outweigh the positive aspects, IME).

Much of what he wrote is nearly opposite of what I've experienced with Agile. For example, I've never seen the tracking of individual contributor progress used in a way even close to what he describes as the purpose of that. One of the more dramatic benefits I've seen from Agile is the ability to greatly reduce non-direct management's focus on the productivity of individual contributors. The regular, short delivery cycles and several planning elements contribute to Business/Product being able to better predict schedules, which reduces their motivation to micro-manage into within-team concerns.

Most teams I've been on did not even track individual progress nor productivity within Agile most of the time. When it was done, the purpose was simply to counter-act the common problem where a software developer gets "stuck" on a task and repeatedly thinks that they are 90% done while the time spent grows to many times the original estimate. And those times, the point was not even for the team lead to track individual productivity, but to get the developer to realize much more quickly how "stuck" they were so that they would stop trying to "push through" to finish their current approach but instead take a step back and realize a change was needed (I found that swapping tasks with another developer often just solved such problems).

The criticisms that Agile does not cater well to senior developers and long-term projects with significant design requirements and also encourages the build-up of technical debt are more realistic. These are areas where you have to push back against Agile, but even more so, against Agile zealotry. I often laugh when I see again how several of my co-workers who aren't Agile zealots but are Agile fans are just unable to admit that aspects of Agile actually contribute to such problems (insisting that only the mis-application of Agile can be blamed).

But it is certainly not true that Agile makes such problems inevitable. We have Agile zealots here and lots of Agile fans and we have many teams. Most teams have somebody very senior that is very highly appreciated. Many teams have quite successfully taken on projects that took years to develop very complex systems.

My experience is that the really big projects are actually more likely to be successful with Agile than without it. The problems with Agile and large, complex projects are not trivial. But they are less likely to balloon into project killers, IME, than the classic problems that lead to such a high failure rate for large, complex computer projects.

I did leave a previous job, in part, because I was not being successful in pushing for fairly minor process changes to prevent the build-up of technical debt. That was in the context of Agile. But the real problem there was that the person at the top of that company was notably bad at empowering those under him and this attitude rolled down hill. Empowering at the bottom is the single most important principle for success, in my opinion. The people closest to the problem are the ones best able to make good decisions about dealing with the problem. Agile had actually made the tech debt problem less bad than it used to be there. But the tech debt problem in the end was indeed the classic form that can happen with Agile.

One part of the write-up you linked to may reveal a major source of the perspective presented:

Scrum and Agile represent acknowledgement of the idea that emergency powers must sometimes be given to “take-charge” leaders who’ll do whatever they consider necessary to get a job done, leaving debate to happen later.

That is the opposite of empowering at the bottom. In that environment, no set of principles will be able to lead to a good system. I've never seen Agile run in something even close to that manner. And the principles of Agile actually contradict such an approach. Straight from the founding Agile principles we have "Projects are built around motivated individuals, who should be trusted". (I suppose you could misread that as "around motivated leaders, who should not be questioned", but that is not how it was meant and is not how I've ever seen it interpreted.)

So somebody worked in a tyrannical environment where they used many Agile principles and practices. And that was horrible. They also completely rejected one key Agile principle. So such horribleness is certainly not inevitable with Agile. I believe that things being horrible is pretty much assured (eventually) by the tyranny. I see no reason to deny that, in that environment, some Agile principles and/or practices contributed to the horror. But I don't think that actually says much about Agile.

There is a lot in this subthread about "it's not like that"; but nothing about what it is really like.

Not that anyone will care, but all I originally asked was "On the ground, in practice, what is achieved by the Agile process -- stand ups, sticky notes et, al -- that isn't (not can't be) achieved without it?".

I was interested in hearing what people who actually used it, but aren't necessarily Kool Aid drinkers, felt about it in real world use.

Same way that I asked my neighbour who had solar panels fitted to his roof, how he was getting on after a year.

I am a skeptic about them -- in this country, with our weather at fixed angles that weren't designed to capture sunlight and that can't track the Sun -- I consider the sales pitch that I've listened through a couple of times and been forced to cut short about once a week for the last five years, as close to a bare faced lie as I ever had pitched to me.

I don't believe the hype; but I'm always interested to listen to real experience from the trenches.

In my neighbours words: "it isn't saving me a huge amount; but it hasn't cost me anything; and I'm doing my bit for the environment.".

The first Solar Panel salesman that opens with: "You won't save a lot; but it won't cost you anything", just might catch my attention.

Somewhere between the sales pitch and the anecdotal bad experience; is what most people actually experience; and it was that I was interested in. Logic is rarely polemic.

Update:It's also worth noting the fifth word of the title of this series of threads; hence why I thought I might get a straight response from eyepopslikeamosquito; but gave clear indication of my stance and leave to ignore. Which he has. Which I respect.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

I originally asked was "On the ground, in practice, what is achieved by the Agile process -- stand ups, sticky notes et, al -- that isn't (not can't be) achieved without it?" ... I might get a straight response from eyepopslikeamosquito

OK, the straight response. In summary, I mostly like small-A agile ideas, usually strongly agreeing with anything written by Alistair Cockburn and Martin Fowler, for example. Schwaber and Sutherland, not so much. :) I also like lean ideas, and it should go without saying that I do not endorse "waterfall". I'm astonished at how many agilistas trot out the tired old "waterfall" strawman, given that even the original 1970 paper "Managing the Development of Large Software Systems" by Winston Royce cautioned:

"the design iterations are never confined to the successive step" and model without iteration is "risky and invites failure"

I do not like Scrum. To me, there is little substance, and too much unnecessary and arbitrary ritual and dogma. To answer your question directly, there is nothing that can be achieved with Scrum that you couldn't similarly achieve with any other agile or lean or iterative framework, home-grown or otherwise. I like the look of Crystal Clear by Alistair Cockburn, for example. Unfortunately, mainly due to clever marketing, Scrum has become the dominant branded Agile framework. BTW, when I suggested we try Crystal Clear at work, this was rejected. I also had some ideas for a team-specific home-grown agile process but this was similarly rejected. Given that Agile exhorts you to "empower and support" rather than "command and control", I felt the command-and-control "you must use Scrum" commandment ironic ... which also explains the use of the word "imposition" in the title of these articles (see also Agile Imposition by Martin Fowler).

As for my personal experiences, to spare you having to read all eight parts of this series, I've extracted a few relevant anecdotes in this reply. From part I:

When I suggested team-specific adjustments to their process, it was implied that I "didn't get it" and that I'd benefit from attending another Scrum training course, maybe one day even attaining the coveted "Certified Scrum Grand Panjandrum" title. I felt sad and alone, a lowly novice in this new religious order.

During that early "evangelistic era", most of the folks around me seemed to be behaving like the guy in the photo at Going Agile Can Hurt Your Company by Ovid. I felt sad and alone, ostracized by this new religious order. I felt I had lost power and my opinions were not respected any more. In the old order, my technical skills helped to win respect from my workmates. With the agile revolution, Scrum knowledge suddenly was more highly valued than being able to actually write code.

I noticed that the mediocre programmers jumped on this bandwagon with great relish because now, instead of being powerless due to their poor technical skills, they become powerful due to their Scrum passion and knowledge. They tenaciously pestered their bosses to pay for them to attain the prized "certified Scrum Master" (for connecting butt to chair for two days). I was, and remain, an avowed certification skeptic (see, for example, Re^2: Selling swimsuits to a drowning man) and have always refused to attend any certification course on principle. BTW, I feel that clever marketing, such as certified Scrum Master courses and all the rituals and new words for old things, is the primary reason why Scrum became the most popular of the branded Agile frameworks.

From part II:

My new desk in the agile commons was situated next door to our internal systems team. And boy was it drafty! All day long, I listened to them responding to support calls and joking around while doing so. And they often built new PCs, so there was a constant whirring from new PCs under construction. Within a week I wound up with a nasty dose of tinnitis. While the improved (osmotic) communication within our team was certainly welcome, the elevated noise level, drafts, and constant visual distractions were not. I felt like I was living in a fish bowl, which reduced my general level of psychological comfort and well-being.

When I complained I was finding it hard to concentrate it was implied there was something wrong with me, that I should instead embrace all the extra noise and visual distractions because "it is more agile". It seemed saying something "was more agile" automatically won you the argument! That is, "agile" had become a synonym for "good". Madness!

Each project's ecosystem is unique. In principle, it should be impossible to say anything concrete and substantive about all teams' ecosystems. It is. Only the people on the team can deduce and decide what will work in that particular environment and tune the environment to support them.

-- Communicating, cooperating teams by Alistair Cockburn

Following Cockburn's advice, I lobbied hard for allowing teams to tailor the process to suit the way they liked to work, but this was rejected in favour of a "one size fits all" approach.

From part V:

As you might expect, the early meeting time slot was causing some unwelcome stress within my team. Sometimes a train was late or cancelled. On other occasions, family duties, such as taking a child to school, caused team members to be late or even to miss the daily meeting. And this stress was not reduced when agile coaches proposed the imposition of humiliating punishments or fines for being late to the daily meeting.

I could go on, but you get the picture. At a personal level, I struggled with Micromanagement-like aspects of Scrum and felt that it harmed my psychological well-being and may have contributed to a worsening of my anxiety disorders. Though it hadn't been written back then, I can therefore relate to this quote from Michael O Church:

Scrum induces needless anxiety about microfluctuations in one’s own productivity. The violent transparency means that, in theory, each person’s hour-by-hour fluctuations are globally visible– and for no good reason, because there’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. For people with anxiety or mood disorders, who generally perform well when measured on average long-term productivity, but who tend to be most sensitive to invasions of privacy, this is outright discriminatory.

-- Why agile and especially Scrum are terrible by Michael O Church

That is pure opinion editorial. No facts, no actual examples, and not one of the hypothetical anecdotes matched my experiences; I read the follow up post too and much of his would be insight was exactly the opposite of what I experienced at Amazon, for example. It’s not a computer science writing. It‘s personal philosophy blog posts.

His logorrhea is only matched by his lack of meaningful, helpful, coherent conclusions, for example: Conclusion : Middle management is … both the solution and the problem. … rather than declaring the whole concept obsolete [we must\ figure out how to get good at it.

You know what that kind of fluff and that ouroborian logic sounds like to me…? “The problem is the solution! We don’t know what to do but we need to figure it out!”

Boo. Hiss. Fie.

It’s not a computer science writing. It‘s personal philosophy blog posts.

Of course yes. The blog is about Rants, essays, and diatribes. The article in question could have been enriched with anecdotes; but even so, it would also be personal opinion, perhaps worth to ponder. I personally believe (to quote blazar) that the "Agile Imposition" is akin to "Perl Best Practices": something useful for some, in some situations, but sought to be imposed as standard, once and for all, by those driving the scheme. No science there, either.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

++ :P

But now I miss blazar…

Instead of writing up stuff myself - a link: Why “Agile” and especially Scrum are terrible which is a nice read.

He he. I posted the exact same link in Re^3: Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship 37 minutes before you.

There's an applicable aphorism I'd quote, but then that yapping toy would pop up to point out my megalomania :)