Why Agile and Scrum Are Terrible
michaelochurch.wordpress.com
michaelochurch.wordpress.com
The great thing about Agile is that it's not business driven. I mean, of course you the work for business reasons, and the business people who have determined what they need, need to be available to the Agile team (for example in the form of a Product Owner in the case of Scrum), but in the end, it's the team of developers that makes the decisions about how they do it.
Of all the claims that this article makes about Agile, I haven't spotted even a single one that's correct. All of them are quite obviously false. The article is a piece of junk.
I'm sure there are organizations out there where Agile/Scrum is working fantastic for them in practice, and developers are happy with their work and career prospects. I just have yet to encounter one in the wild personally.
I worked in an agile (and, in fact, XP) environment for a while. The rule there was that the product manager owned the decision of what stories went into the project, but the technical team owned the estimates. That's kind of agile-y (we're doing stories and estimates, yay for us!), but it's also just good engineering management.
If you're in a situation where "Feature X has to be done this sprint because it's already been sold to (Board|Client|Investors|Other Dept)", you're in trouble whether or not you call your process "agile". The trouble you're in doesn't have much to do with whether you're agile or not, either - it has to do with management that doesn't listen to engineering reality. (However, it is a violation of at least one of the principles from the agile manifesto - sustainable pace.)
So, now we recognize that "agile" doesn't describe the elements of a software-development process, it describes a set of priorities which are used for determining what process is adopted, and how the processes adopted are applied, in a particular organization (a set of priorities which specifically calls for consideration of the particular people involved and how they particularly interact.)
Well, yeah, that's usually the problems with complaints about agile -- they aren't about agile, they are about a specific set of processes (usually ones developed, adopted, and applied by an organization not applying the principles in the Agile Manifesto) which that particular organization, or the consultant selling them, called "agile" as a way to hook on to the popularity of the buzzword.
> Scrum is more concrete, though, and can be more validly criticized or defended without as much confusion over the definition.
In principal, sure, Scrum is subject to process-based criticism, although lots of criticism of Scrum are about "what I've seen organization X, that claims to be using Scrum, do" rather than "the framework defined in the Scrum Guide".
Scrum is the most process-oriented process that's still pretty agile. But one of the most essential aspects of it is that you refine your process based on how it works. In an organization with multiple Scrum teams, eventually every team will have a slightly different way of doing things, because that's what works for them.
I totally agree that there are a lot of companies that claim to be doing Agile or Scrum, and often it just means they picked one element, pulled it out of its context, and applied it in a situation that has nothing to do with Agile or Scrum.
Years ago I worked for a company that claimed to be doing Scrum because they started each day with a stand-up meeting. The meeting was fine, but what they did really wasn't Scrum by any stretch of the imagination. No sprints, no backlog, no retrospective, no well-defined stories, and no clue what our pace of development was. And even if you do have all the trappings of Scrum, it's still not Scrum if you ignore the underlying principles.
Scrum is not a variety of Agile. Agile is, per the Agile Manifesto, an approach to software development which prioritizes (among other things) individuals and interactions over processes and tools.
Scrum is a tool (a process, arguably, though it describes itself as a "framework" as opposed to a "process", since any complete process will need to add to what is presented in the Scrum Guide) laid out in a "definitive guide" providing the "rules of the game". An organization might be applying Agile principles and use Scrum, but those are largely orthogonal concerns.
> So what are Scrum and “Agile”? I could get into the different kinds of meetings (“retrospective” and “backlog grooming” and “planning”) or the theory, but the fundamental unifying trait is violent transparency, often one-sided. Programmers are, in many cases, expected to provide humiliating visibility into their time and work, meaning that they must play a side game of appearing productive in addition to their actual job duties.
This does describe the actual process in many places, but it has nothing to do with "Agile" or "Scrum". It is a fairly common management failure that was common among the canned one-size-fits-all processes many things that the Agile Manifesto was a reaction against; Scrum -- as defined in the Scrum Guide -- insofar as it incorporates what might be described as "violent transparency", does not do so in a one-sided manner.
"Lots of things that are called 'Agile' have problems because continue to do things -- which are also common without the 'Agile' label -- that the Agile Manifesto was a direct response against" isn't a substantive criticism of Agile, though its a good warning -- as is, after all, the Agile Manifesto itself -- against buying a canned process or tool and applying it just because the person selling it says the word "Agile".
Agile works for some development groups. But it definitely does NOT work for many others.
In what way does the engineering team end up subject to the whim of the PO? The PO needs to provide the details of what the business needs (someone needs to do that, after all), and what the priorities are, but he's in no way in charge of the team.
If the team has no PO for a significant amount of time, that does mean that a vital part of the team is missing, but I'd like to see any dev team build something without any idea of the business needs. It's the PO's job to communicate those needs, and the great thing about Scrum is that he does so as part of the team, rather from some distant ivory tower.
I also don't see in what way Senior engineers get marginalized. If anything, everybody gets treated as senior, because everybody gets ownership, responsibility and decision making power about the project (though in reality, it's of course the seniors with the clearest ideas and tend to end up with most of the control over the team).
And there's generally plenty of room to include stories (even very large ones if they can't be cut up, though they usually can) about internals, infrastructure and R&D on the backlog.
It's absolutely true that it's not for everybody, but your criticism and that of the article don't hold much water.
I've been in an agile process. It worked, mostly, but it broke down when the PO didn't have the time to do the work. (It was huge for an agile team - 30 people - which put a huge amount of pressure on the PO position).
For the next project, the PO "didn't have time" to give us actual requirements - just "improved reporting". In the most amazing display of agile that I've ever seen, the development team lined up a series of customer conference calls to expose their requirements for reporting, and proceeded to run the entire development process without a PO. And that worked amazingly well...
... right up until three weeks before the scheduled end of the project. (We were probably going to miss by a week, on a six-month project.) Then product management showed up and said "We like what you're doing. But we need these additional things as well. Oh, and we can't change the end date." Predictably, that was the end of agile, as well as the end of any management reality for that project. (You think you can add three months of work without changing the end date? The real world will demonstrate to you that you cannot in fact do that.)
Still, good job making it work despite utterly dysfunctional management there. Agile does require that management understands what you're doing and what their role in that is. But again, that's true in any other situation too.
I also think a senior should be able to understand how a development process works without resorting to silly strawmen.
Strawmen are different from examples; its lazy to call any explanation a strawman.
I'd like to see a process that handles this better while clearly being not Agile.
The OP makes some real points about failings of management that predate Agile, and are common even where the word "Agile" isn't used, and occur (among other places) in places that use "Agile" as an empty buzzword the same as the same type of organizations would use the name of any other approach that was popular if Agile wasn't around.
But none of it really has anything to do with Agile. Very little of it even has to do with Scrum (which, as an actual defined process rather than an approach to selecting/using processes, is at least subject to process-oriented criticism.) And, perhaps most importantly, no solutions/alternatives are offered.
And I am unconvinced by your claim that Agile isn't working, that is, I am unconvinced that the problems Agile exists to mitigate are not reduced in organizations that actually apply the Agile principles in hour they approach work.
OTOH, I do think the "Agile" brand had failed because a while lot of applications of canned process in rote ways -- the thing Agile directly opposed -- is being sold as being Agile methods.
Agile isn't an engineering process, its the the idea of applying problem- and resource- (including the staff on the team) specific engineering to the development process.