Why “Agile” and especially Scrum are terrible
michaelochurch.wordpress.com
michaelochurch.wordpress.com
Agile is a process for managing software implementation. Period. You have to bring your own software design process, and if your company's is terrible (or nonexistent), don't blame Agile. You also have to manage your own software R&D, though you could certainly use the process to manage projects within R&D. But the idea that Agile somehow precludes R&D itself is ludicrous, no more sensible than saying it precluded your company from spending enough on marketing. Even sillier is the idea that it should provide some kind of career advancement plan. Agile is a software development process, not a personal development process. It doesn't (and shouldn't) offer a career roadmap any more than your build system does.
I've been doing scrum for about a year, and while I think agile is excellent because of the feedback look, I also think scrum is the worst agile method. Mainly because non-technical management will turn it from managing software implementation, into managing employees. But it's worse because you have to tell everyone your progress, and god forbid you actually have a problem and fuck up that sprints velocity. I was almost fired once because my velocity was half of what it normally was one sprint, due to basically dropping development work and doing devops for a week.
I've been on a project where we had marketers join our sprints, and we're even assigned stories. Timeboxing genuinely difficult problems into two weeks is extremely stressful, and most product owners don't care about complexity, only results. I've had to make some super nasty hacks just to help get a "win" to make a client happy. True scrum is just too rigid for applications with complex problems, which is why you'll have a hard time finding two places that do scrum the same way, or keep processes consistent sprint after sprint. In my opinion, I find kanban to be a much more effective way in managing development, as it allows your engineers to actually solve problems. So I agree that agile is effective, but I don't think scrum is always the answer.
Sorry about the word vomit.
Agile was introduced so that failure could be amortized and tracked. It makes the development process more transparent so that mid-course management corrections can be made and the corporate ship can be steered around the icebergs instead of running blindly dead into them. But in order for it to work, management must be tolerant of small failures. If it's not, then scrum will become theater with failure swept under the rug, and you'll be right back where we were, with failure becoming apparent only near product launch, when the iceberg suddenly appears out of the fog too late to avoid it.
Now, it may be a valid criticism that agile expects too much from management, that most software company managers aren't competent enough to use it. But that pretty much says we're all doomed anyway, regardless of what system (if any) is employed.
I'd be interested in your thoughts on why you feel kanban is better, since my impression is that it is essentially the same process but without sprint intervals.
I view this as an advantage for two reasons:
- 1. Most non-technical clients view point estimates as absolute expectations. They can't comprehend an estimation in any other way. So if I can do 5 points a day, and I give a story 13 points, it's expected to be accomplished in ~2.5 days. If I exceed that amount of time, I've missed their expectations, and now I have a client who considers that work behind schedule.
- 2. Large complex problems can be solved without the pressure of accomplishing it within a finite deadline. I think this leads to more robust implementations, and helps prevent large amounts of technical debt. To compare, I have never seen a scrum project that didn't have a runaway amount of technical debt that lead to some insane scope creep in stories later on.
It has a downside of potentially hiding some problems, but I think it helps with individual responsibility when it comes to tasks. Every time I've used kanban, it's usually been for pretty short periods, but those periods were extremely productive and way less stressful.
I mean, this is just all my opinion, so take it with a grain of salt, but this is what my agile experience has been so far.
I have never heard of individual velocity measurements, they are wrong and should not be measured. I also think that burndown charts and velocity are for the team, not the stakeholders. This is because story point estimation is volatile and turning it into a feedback loop would turn this estimation into a meaningless thing.
Thus, there is room for transparency with the stakeholders in the sprint review and the setup, all else should be in the team's responsibility.
Scrum guides are usually very specific about the fact that the daily scrum is not for reporting.
Devops work should be priced in as a story in the sprint. If the Product Owner does not want to give such a story the proper priority, you should transparently explain how lack of such work will decrease sprint velocity in future sprints.
The reason we had individual velocity measured, is because our management wanted to use it as a metric to determine our performance (Which I think is an awful method for measuring performance). I work in a digital agency, and our management tries to be very hands off, but then they do something like look at individual velocity and our amount of git commits to make sure we're working.
Taking commit counts as a measure (and line counts for the same reasons) is like evaluating a writer by the number of words they write without looking at the content. A writer could copy a phone book to get good reviews.
Individual velocities are bad for several reasons. (1) they discourage team work (2) they are inexact (story point estimates only work because we look at the sum of them for sprint planning, they work on average, not for individual stories). (3) there are better metrics available.
If your management wants you to do agile develoment, they should be there in the sprint review and look at last sprint's work.
External facing APIs changed regularly, affecting other teams and leading to slow and painful integration. By regularly, I mean just about every sprint. How about thinking more than 2 weeks ahead?
It didn't help that there were lots of inexperienced guys just out of college (who probably thought this was normal.) Along with a "manager" with extremely poor communication skills (not uncommon in development) this was basically a disaster.
We did, however, have lots and lots of unit tests. We spent about half of each "iteration" rewriting them due to the API problems.
I gotta laugh.
That said, I think this post falls short at acknowledging the difference between the general Agile concept and Scrum as a particular implementation (of which there are many), and I have a few further disagreements:
Instead of working on actual, long-term projects that a person could get excited about, they’re relegated to working on atomized, feature-level “user stories”
Translation: instead of working the way I enjoy working, programmers have to work in a way I dislike, therefore Agile is terrible.
As a programmer, I like working on small features and projects, and the variety that comes from taking on different types of work.
Long-term stuff is nice too, but despite what you might think, not everyone gets excited about the same things you do.
often disallowed to work on improvements that can’t be related to short-term, immediate business needs (often delivered from on-high).
People being disallowed to work on core improvements happens in any kind of organization system.
Around here, we use "processes [that] promote sustainable development" and which allow us to "maintain a constant pace indefinitely." That means occasionally allocating people to refactor and improve the codebase, when the programmers feel that need and point it out.
Atomized user stories aren’t good for engineers’ careers.
Well, then it shouldn't be hard to show that engineers with Agile-based work experience have more difficulty getting hired. Is there evidence on that?
5. Its purpose is to identify low performers, but it has an unacceptably false positive rate.
Absolutely no argument here. The constant tracking is demeaning and often counter-productive.
That said, I don't think Agile requires it, just specific implementations of it (like the aforementioned Scrum).
It's more about breaking down development into small chunks at a time, so that if there are performance (or specification, or other) issues, they can be dealt with quickly.
I think also the OP doesn't give agile/XP enough credit for the good things it has mainstreamed. For example:
- Sustainable pace (don't work > 40 hours week). Agile companies, in my experience, tend to have good work/life balance.
- Continuous integration. Release and integrate often.
This article was strangely heartwarming.
Agile didn't "grow up in web consulting", and it wasn't about dealing with finicky clients who couldn't be "managed". It came from enterprise both large and small, mostly not involved in web or consulting. In fact, it arguably started before software development did - see Kanban at Toyota.
Agile software development methodologies came from a real need to reduce the failure rate of software projects that was, even 10 years ago, closer to 50% than 0%. It attempted to provide ways to stop the average software project from running nearly 50% over budget. It waged war on the "big design up front" methodology handed to us by other engineering fields and acknowledged that in the real world, software development is often a wicked problem (http://en.wikipedia.org/wiki/Wicked_problem) that cannot be solved until it is solved. It acknowledged that requirements change, and software takes such a long time to build, often by the time a large design is built it already doesn't do what it needs to.
Almost all the statements the author makes are misleading, or misguided.
Violent transparency? It's a good thing that helps software projects succeed.
Atomic little user stories? They embody the divide and conquer philosophy to break down the author's ambiguous "long-term projects" into small chunks that can be understood, tested, and estimated. And delivered quickly.
Shared ownership? Promotes respect of the team, organisation, and customer. Helps get rid of bat-cave developers who can't acknowledge genius other than their own. Helps diffuse any blame for failure.
Social organisation? Has little to do with agile methodologies and a lot to do with the enterprises that implement them. Some do it well, some don't. Scrum doesn't dictate that a product owner or Scrum Master is more important than the engineer. Contoso Shiny Widgets Inc. does that. Just like they dictate whether experience and skill are valuable in their teams, and whether they listen to their engineers about technical issues that cause the kind of technical debt that is hard to solve with "good design".
Exit strategy? Short term? What? Use an agile process when it makes sense. Stop using it when it makes sense. Of course the process is designed to be there forever - they're tools to be used by people trying to solve real problems. The nature of those problems changes over time.
Lack of R&D? Software development is prima facie the D. The R? It's entirely possible to do that in iterations. Agile processes certainly don't remove R&D - spikes are there almost exclusively for R, and they're a first class citizen in the process unlike pre-agile. Perhaps the author refers to those 'long-term' projects that more often than not end up nowhere?
Technical debt? The author doesn't understand agile at all. Agile has two main tools to help manage technical debt - fast feedback loops, and encouraging development in small vertical slices. The best agile has even more - XP promotes TDD, not prematurely optimising, refactor mercilessly among other things. Basically universally accepted ways to improve the quality of software.
Crunch time? No! Agile promotes sustainable pace. To help avoid death marches. Heard of those? They've derailed careers for good.
I'm no big supporter of Scrum - it lacks the software design guidelines of e.g. XP, and it's been abused by some companies for their own purposes (probably those the author has worked for). But it has some fundamentally good ideas, and since Agile methods have been around enterprises small and large have improved on many measurable metrics. It's the best we currently have - come up with something better.