Agile with the backend/infrastructure actively encourages taking on technical debt just to get something, anything up and running as quickly as possible. Which is great for PMs' careers but terrible for the developers who have to maintain those systems, and ultimately the organization as a whole. Maybe it's even great for job security or to get an IPO/acquisition as quickly as possible, but it really does result in much more work in the long term.
The issue is that the people who push for these terribly designed backends that suck up unnecessary human-years worth of work to maintain, patch, and fix are never held accountable. And if you're stucking as a developer working on these systems, you're screwed (and it can even be bad for your career since you're not shipping anything new). I can't tell you how much of a relief it is to just walk away from that kind of mess... which really, makes the situation even worse, since everytime that happens organizational knowledge gets lost and some poor soul gets to start working on something terrible with much less context
The last part is more of a problem with hard maintenance work being unappreciated compared to launching new shiny shit which is entirely different can of worms.
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.
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.
In a sense, it sounds like there is nothing to correct! Would moving more slowly and deliberately have improved the exit, or worsened it? Perhaps code quality has only a tenuous link to business outcomes.
"I believe it is time to explicitly state the long held secret of software, we do not need to do design; design is ineffective and costly." --Wayne Mack
It's really hard to argue with a money printing machine. That theoretically it might print faster or at least longer for a bigger integral, after doing things that seem to slow down printing now, is also hard to believe if the person you're arguing with has never experienced such a non-linear outcome.
And I would say than in most areas, design is effective and required.
NT works. 9x is long-dead (and even 9x had tons of design, but there was just a gap too immense on some fundamentals to get anywhere)
I would even make the hypothesis that good design is always eventually effective and required, but the period of time after which lack of proper design hits you badly varies, and in some fields it is actually longer than the lifetime of the product...
As much as Netscape vs Microsoft hurt Netscape, the time it took to do NS7 and the quality it shipped with, pushed them back 5-6 years.
I'll add it to my quote file, file under quotes by snarf21 :-)
Positive criticism always falls on deaf ears - "why not just give it a chance" blah blah.
Yet the product is markedly inferior to the same product we created with fewer developers in a shorter period of time, while also creating the backend services, right before we created this product, when we were not following ‘agile’.
Because the current management approved Agile is just a bunch of rules that are enforced upon us. The previous process was basically an ad god process we had built up using best practices, adapted based on our own experiences with the unique needs of our team. In a sense, we were far more agile when we were not doing Agile.
Basically the way any larger company works.
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.
Also there's nothing in agile that would prevent you from designing things upfront, I believe the exact phrasing is "Responding to Change Over Following a Plan". I.e., build extendable / adaptable designs (that can change), do the amount of specification upfront that provides value, but don't ticket-plan 2 years of development upfront.
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.
Sprints are about enforcing feedback from the customer into the loop. If you have a half decent customer they should be happy with any length sprint and releases that make sense.
Well, there's supposed to be -- Technical Quality - Refactoring.
Common to all flavours of Agile (I lecture agile techniques) sounds like you guys are missing out important parts of agile... but I totally agree with what you are saying. I'm old Skool and grew up with waterfall. I find it really weird teaching students who don't have a spec or UML diagrams or any idea what a software pattern is. Hell, some of them don't bother with a Model layer - not enough time to implement it in a sprint, so why bother? Lol. They get code out the door, but quality code? A-hem, it is possible, but do people do it?
What made them stand out? What did the do to make it run well?
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 full waterfall again but I would really love to see some sort of lite versions of Functional specifications & design specifications come back.
Agile works best IMO in the Pre-1.0 phase of a product and gets progressively worse the further you get towards maintenance of a product. I also think Agile works better and better the closer you are to the UI, and worse and worse the further you get from the UI. Solid back end design and infrastructure rarely fits well into "Sprints" and solid back end infrastructure is not sexy at all in a demo, so Agile can demote back end design to the point everything gets done in a way that is too MVP. Then later on when scalability, performance, bugginess, and maintainability come into play you're into that "established product" phase where Agile doesn't do as well. So you've got problems in an area of the product Agile has trouble with happening in a phase of development Agile has trouble with.
Agile also seems to really require absolutely top notch product management folks, and they are seriously rare.
The thing is of the 5 shops:
* 3 Were acquired
* 1 Went IPO
* I work at the 5th currently
So the companies always had a successful exit even if the codebase passed onto the acquiring company or to the public investors had major issues.. so at least in my experience there's no feedback loop to correct the issues.