Yeah. The secret to agile, imo, is to embrace the spirit and basic concepts and ignore all of the marketing and rituals that people try to sell.

1 week sprints are great for the rare times you really need to focus and get **** done for a tight deadline. But it's not sustainable, imo.

Hundreds of thousands of years of evolution of humans interacting face to face is why.

Honestly, most of the examples here why agile is bad are just examples of agile done wrong. Standups should never exceed 20 minutes, 10-15 being preferable. That's why they're done standing up, to encourage people to be brief.

We had a PO that liked to use standups to cover extra stuff that was on his mind and really should have been covered in a followup meeting. Our solution was to come up with a yellow card/red card system. As soon as someone is taking too long or talking out of scope, any team member can throw up a card. That did the trick for us.

The same has been said about communism. That's why I made the reference earlier.

My argument is this: If only very few groups are able to do it right, the process may not be as great as it is made out to be in theory.

It's a bit like arguing it works 5% of the time, but then it works a 100%.

Edit: And, yes, we had our drawn out sessions also while standing up. Didn't stop people from doing it wrong.

Difference between agile and communisim is that agile has been shown to work in practice. Or do you maintain that all attempts at agile have been failures?

Of course there is a question how often companies are able to successfully adapt an agile process. I don't have any data for that, do you? I think the failure is often that companies are just paying lip-service to the idea and not committing to a real change. But I might be wrong.

My agile experience has been positive but that's purely anecdotal. But the great thing about Agile is that you don't need to be perfect to get value out of it.

We adopted the methodology of trying to drink all of the coolaid for a while and then seeing what worked for us and drop whatever didn't. I think that's very common (often called "Scrum-but"). Then we review and iterate on the process. What we've found is that over time we've adopted more and more rigour cause we feel like its giving us value.

I don't have a huge problem with the communism analogy. I think the people making up the team are much more important than the process. Same is probably true of communism (as in, there are small communities that make communist concepts work).

Fair point. It certainly can work very well unless everyone claiming that it works for their team is lying. And I'm not cynical enough to believe that.

I've worked on 5 different supposedly agile projects/teams.
On a scientific scale from 0 - 10 (10 being optimal), where the primary instrument of measurement is my wet finger held into the air, all of those ranged between 1 and 3.
So, my anecdotal "evidence" is running at 0 out of 5.

The other, more waterfallish projects were on average significantly better to work on. Of course those companies have spent a lot more time practicing that approach and, therefore, got it more or less right.

I suspect that Agile sounds so desirable and easy to implement, that the actual effort in doing it right may be vastly underestimated.
It's supposed to be agile, right? So let's make up responsibilities on the go.

To give some concrete examples...
In two out of those 5 aforementioned projects, we didn't even have separate scrum masters and product owners. "Ah well, the project manager can double as scrum master and product owner. It's too much overhead to get a real product owner attend regularly."
In all but one of the projects, the product owner wasn't a real one. And only in two of the five did we have something resembling a real scrum master as discussed in agile methodologies.

Good points. I'm thanking my lucky stars right now for finding my current job. Before that I had only worked in one waterfall job which was a constant cluster**** cause there was no rigour and then a couple of startups where we just ****ed about until a deadline loomed and then we were in crunch mode 24/7.

I want to become a scrum master!

It was great for my resume.

I've been referred to as a scum master, is that close enough?

There is no process of a certain complexity that can't be done wrong. Your team is doing it wrong it's your teams fault not the processes fault.

That is absolutely right.

However, how useful is it to apply a process widely when it is very hard to do it right?

What makes Agile so special is that it seems to work a charm if a team applies it plain vanilla with no variations and only then start tweaking it if need be whereas a vast amount of companies (or their management) approach it the other way around. Ie. Introducing little bits to "see if it works" and then it ends up being a massive, ineffective time drain.
Ironically, in those settings they are hesitant to both, letting go if it obviously does not work or finally just taking the plunge. Instead, they try to tweak things around it and have longer meetings to, yet again, reiterate what needs to be done.

And to clarify, I don't have any gripes with Agile. I'd love to see it in action the right way. All variations that I have seen have been a massive drain on both productivity and clarity.

Even poorly applied agile is generally better than the alternative.

I'm pretty skeptical that for a given development team poorly applied agile is a 'massive drain on productivity and clarity' compared to any other typical process for that team.

Using development team to include management.

Maybe I have almost exclusively been on teams really good at waterfall, but from my impressions in the past 15-ish years, productivity compared between those two philosophies has seen waterfall well ahead.

Could be that it is a perception thing, though.
Impossible to compare if you don't do the exact same project with the same people in both variations starting from the same point.

To get back to this point: The waterfall projects I've been on had dedicated people to pump out really good specs and having great feedback channels during the time they were creating those specs.
Once you've got a good set of specs, it is easy to create the code to match them.

The only thing that frequently caused massive issues was scope creep. And Agile is sold around the idea that scope creep will be ok. So you get even more of that. And in the poor adaptations of Agile I've been struck with, it was anything but ok.

What kind of products sre you building?

Edit: I mean a lot of software these days is released frequently and is rarely 'done'. The benefits of fast iterations in building things are pretty well documented and basically impossible in a waterfall model of development.

It's also hard to get user feedback (the most valuable feedback!) before you've built something.

Mostly risk management systems for financial institutions and, prior to that, extensive content management systems (for media houses and publishers, so not the wordpress/drupal type of CMS). Apart from that, some work with embedded systems.

Agile isn't sold around the idea that scope creep is ok, it's sold around the idea that the farther out you plan the more full of **** your plans are so don't do them.

This seems like a pretty solid setup

Really? You think that before the Agile gurus decided it was the only way to write software there weren't any productive and successful development teams?

Please go back and read that post again sport.

http://clearcode.cc/2014/12/agile-vs-waterfall-method/

Of course some people are successful with waterfall, but most aren't, that's what drove the development of other processes, including Agile.

First off I'm not sure if people mean literal face-to-face, a webcam or a voice chat.

I think this is rarely useful. How often do you need to consult 5-8 people to exchange ideas or issues about the task you're attempting to accomplish that day?

I'll touch more about the speed of exchange and the consequences of it below.


1) Distraction is an issue that affects small children and the stupid. If you can't focus for 10-15 minutes, you shouldn't be employed.
2) Thinking about a response before someone completes a thought is a pretty massive negative. This isn't normal for anyone, nor is it productive.
3) I'm not sure why taking the time to summarize a chat is a good idea, when you could literally just keep the entire chat as a log.

Furthermore, the speed issue is spurious as there are many software programs that enable people to speak to their computer and have words appear on the screen.

There are real costs to literally (or even virtually) getting every person together in a room that carries a real productivity drain. I agree that it is necessary for your lowest performers, but I disagree that you need it for a competent team.

Lol. You lost me at distractions are for the stupid and children.