51–60 of 118 posts
It's always struck me how the attitude of agile advocates has always been so rigid to the point of being dogmatic, thereby being the exact opposite of agile.
I'm ready for what comes next after Agile. I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone. What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over. I don't really want fu…
The Agile experiences I've had that were more satisfying were actually the ones that were closer to "by the book" Scrum or Kanban.
The specific things that I've noticed get left out that make Agile miserable are: - Story pointing goes away - Velocity never gets calculated - Retrospectives get removed
I think Agile shifts responsibility off of management and onto the engineers in even the best run team. PMs and management don't have to commit to hard decisions early in the development cycle because the methodology says that overcommitting early will lead to failure.
Velocity and Retrospectives are two of the best features for me.. Velocity is a check on managers over scheduling developers, and Retrospectives force everyone to look failures right in the eye and adapt. When you remove those two things Management can over schedule the team without even realizing it and no one has any data to show it. When you remove retrospectives no one gets to discuss bad parts of the process or bad parts of the planning.
That's just one part of being satisfied though.. if you're doing perfect agile and killing it but you're building a poor product that's not going to be terribly great either.
Most of the reality for me has actually been good products that were right for the market but ended up implemented pretty poorly due to failings that could somewhat be blamed on Agile.. it seems to be getting worse and worse over time in my experience. More technical debt, poorer scalability, more bugs, less QA (you could write a book on QA and Agile).
I did quite a bit of UI early in my career and moved towards back end over time. I was mostly all back end by the time Agile really took off. I am generally pretty depressed with the quality of the back end code under Agile. You get horrible MVP database schemas and awful quickie framework dependent code that is horribly inefficient and really hard to remove later.. but that path is super quick for that MVP "gotta demo" mentality. I think this stuff really kills the morale of back end developers and leads tons of people to move on.
Earlier quoted context omitted.
One thing I learned a long time was this: A "bad" process that has complete buy-in and everyone participates in will always outperform a "good" process that has lip service buy-in and disagreements about who does what.
While I wouldn't be so absolute ("will always") I think you have a great point. I'll add it to my quote file, file under quotes by snarf21 :-)
I'm ready for what comes next after Agile. I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone. What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over. I don't really want fu…
I'd also add: much of the culture and thinking surrounding Agile grew out of software consultancies: organizations that have the privilege of green-fielding new projects and then "abandoning" them; either because their contract was over, or there's no desire (or capital) from stakeholders to improve the software. So it doesn’t surprise me that their model breaks down for software that undergoes continuous modification for years, as that’s an atypical case for consultancies.
I'm ready for what comes next after Agile. I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone. What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over. I don't really want fu…
None of those things are disclaimed by Agile. Agile never meant "don't do any design, requirements gathering, or specification." If the people you're working with think that "being Agile" means you can't do those things, then quit and go work somewhere else.
Remember, "there is no such thing as Agile." That is, there is no specific process or methodology named "Agile" which is prescriptive and says "don't do design". Agile is an umbrella term that encompasses a wide spectrum of different methodologies, including Scrum, XP, AUP, Crystal, DAD, SAFe, etc. Those different methodologies may argue for more or less emphasis on up-front design, but I'm not aware of any of them that disclaim it completely. If your people are saying "Agile doesn't let us do design" then they're full of shit.
I'm ready for what comes next after Agile. I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone. What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over. I don't really want fu…
I'm ready for what comes next after Agile. I've been through about 5 Agile shops now. I would say one of the 5 ran Agile well, the rest were a mess that just makes it frustrating for everyone. What we mostly have now is watered down agile.. the worst bits of agile like never actually "designing" anything, but we don't really have any of the good bits of the older management processes left over. I don't really want fu…
One thing I learned a long time was this: A "bad" process that has complete buy-in and everyone participates in will always outperform a "good" process that has lip service buy-in and disagreements about who does what.
Positive criticism always falls on deaf ears - "why not just give it a chance" blah blah.
Dave Thomas, one of the original authors of the Agile Manifesto [1] wrote an article called "Time to Kill Agile" [2] a few years ago (which he subsequently re-titled "Agile is Dead"). He has some good insight on how Agile (the methodology) got to be something very different from what they intended. Originally they were trying to break away from a rigid methodology, not introduce a whole new one. Unfortunately, if you…
This is spot on.
And the fact is, this has been known since at least 1980's (!)[0]. I am quite fond of using the version "culture trumps process", because it so well encapsulates the reality. (Also: hits directly against "The Process" ideology.)
It often feels like everyone and their dog within the industry are hell-bent on establishing a Good Development Process. But that's a false premise. You can't just introduce a designed process and expect it to magically fix things. Workflow is everything: motivated and talented people will go to lengths to get their actual work done, process be damned. The best thing you can do is to invest in good tooling and actively encourage sane development practices.
Get the workflow right, and process will follow. Crucially, as you said above, every company will need to find their own flavour.
Dave Thomas, one of the original authors of the Agile Manifesto [1] wrote an article called "Time to Kill Agile" [2] a few years ago (which he subsequently re-titled "Agile is Dead"). He has some good insight on how Agile (the methodology) got to be something very different from what they intended. Originally they were trying to break away from a rigid methodology, not introduce a whole new one. Unfortunately, if you…
What gets presented by these "experts" is rarely anything like the original indent if not the anthesis.