When others ran the stand-ups, they tended to let people ramble more, and they were more painful. I did my best not to step in and corral the situation, but I still often ended up asking the appropriate question.
My meetings went the same way, with a focus on getting things done so we could all go back to our desks. We socialized plenty from our desks and other times, and there was no need to drag out meetings.
I was thanked for my efforts numerous times, and I tried to be aware of any discord that was created, so I'm fairly sure I wasn't making enemies by doing it.
My point is that standups don't have to suck, but someone has to keep them on track. That's what the standup leader is supposed to be doing anyhow.
The essential purpose of a standup is to make sure everyone knows what everyone else is working on, to identify any potential blockers early, and to get the right people collaborating offline to work out details. It really doesn't take very long to say this: "ComponentX, componentY; Blocked on componentZ; need to talk to Bob and Sue afterwards" is fine.
I know I personally can't get started on things right away in the morning because of the psychic weight standups carry. I can't get focused because in the back of my mind I know I'm going to get interrupted soon for a meeting that mostly has little relevance to me.
Also, there's nothing that says that standups have to be in the morning. Most of the teams I've worked on actually had theirs either right after lunch or mid-afternoon. That accommodated those of us who were late-risers, it let the early-risers get some work in in the morning, and it meant that it'd often fall during food coma or when energy levels hit a mid-afternoon nadir.
I'd love to hear some examples here, maybe a snippet of one of your stand-ups.
Open floor plans are not a requirement of "agile". That people think this, is evidence of the real problem here: hucksters have been selling something else, but using the word "agile" to promote it. If one wants to argue that the term "agile" is dead, then maybe one has a point. But I'll argue that the essence of agile is just as sound as it ever was, it's just that we let the term get misappropriated. How to proceed from here is an open question...
Right and this why I say that so many people are (intentionally or not) misunderstanding what "agile" means, and selling something else using that label. Look at what the Agile Manifesto actually says about plans / planning and what not:
Through this work we have come to value:
...
Responding to change over following a plan
...
That is, while there is value in the items on
the right, we value the items on the left more
If "agile has failed" is really true, then here's the one place where it probably failed: It was never prescriptive enough. Which might seem paradoxical, but the problem is, the AM is subjective enough that people could find justification for whatever bullshit ideas they came up with, in the Manifesto. :-(
It may be that agile is just not appropriate for such projects, in which case I wish companies and customers would stop trying to force-fit them.
The thing is, a certain measure of "change control" was always a good idea, even in an "agile" environment. My (admittedly subjective) take is that getting away from change control contributed to everyone's mindset shifting to where "changes are free".
I don't see it quite that way. Services business work in our economy, but if you're doing something on a services basis, you have to understand the implications of that and how to manage them. There are all sorts of services in our economy that work (mostly) fine today.
To illustrate what I mean, let me use an example.. if you take your car in to a shop for repairs, you expect an estimate, and you aren't necessarily pissed if the final tally is off the estimate by a bit. But you will be royally pissed if it's off by an order of magnitude or more.
So, do software projects sometimes cost (in time, money, both, etc.) an order of magnitude more than estimated? Yeah, I'd say so. But here's the rub... are car mechanics better at estimating than software developers? Not necessarily, but their customer doesn't typically come along when the project is half done, and yank the rug out from under them and ask for something that negates half the work they've already done.
"Yeah, about replacing that spun bearing...I don't really want that, just replace the fuel injectors instead".
Nope. Doesn't happen. But I'll argue that the equivalent does happen in our world.
Of course the Agile Manifesto is all about the idea of embracing change, and accepting change even late in the process. So we have to accept that and deal with it. But the rub here is that we have do so in a way that doesn't come across to the customer as an order of magnitude failure.
This is one place where I think we, as an industry, kinda fell on our swords. WE understand agile, but we didn't always educate the customer on what agile meant. And we didn't do a very good job of communicating to the customer what the impact of their change in requirements is. We accept changing requirements, yes... but we haven't always made it absolutely clear to the business customer that "making this change is the equivalent of asking the auto mechanic to replace the fuel injectors instead of fixing the bearing. This is throwing out all the work we've already done, and we need to re-estimate everything now."
Is it because IT people lack the nerve to push back when business users make huge demands? Or something else? I don't know, but over the years I've become convinced this is a big part of the problem. We let the users change things (which they have the right to do), but we don't make damn sure they understand the implications of what they're asking for, and update the estimate/plan/etc. to reflect the new reality.
Keep doing the parts of it that work for you. If parts of it don't work for you, change them or drop them. (Part of the agile philosophy is that you can hack your process.)
We may need to drop the word "agile". But if the mindset leads to you practices that are helpful, use them.
I felt the same way. And now after a few years of open floor plans, I actually love them. Sure there are some drawbacks: noise can increase, and certainly there are more distractions, but there are many benefits. Communication is easier. That feeling of isolation is gone. The group feels more cohesive. I think the only modification that could be made would be to create more isolated areas off to the side either for individual work or team meetings. And companies are doing that, although the private areas are moreso for meetings. But I hear that some are even making smaller areas just for individuals who need a few hours to focus on one task.
> Code quality suffered because of the constant pressure to get things done now
It takes some wisdom for managers to be able to properly apply Agile principles. Pressuring devs to spit something out without properly designing it is poor management practice. Its common, yes, but its still wrong. That's why Agile suggests a fairly wide range of time to deliver software (from two weeks to two months). Every piece of software is different, and it takes good people to determine the correct balance between release frequency and development time. You should prefer to release frequently, but if you're releasing garbage then what's the point?