We recently brought on a couple of PM consultants who are deep into Agile as a methodology, and decided to give it a go -- it's been about six months now and productivity has basically ground to a halt as we spend more and more meeting time endlessly sorting tasks into different little arbitrary piles instead of actually making forward progress. It's made communication with the non-software part of the company much more difficult, because they keep getting hung up on the jargon; we have to slice up tasks arbitrarily to get them to fit into "sprints," which go out of date minutes after the morning standup when the first non-planned bug report lands. Sizing is frequently an exercise in post-facto book-cooking: 'How long will that bug take to fix?' is like asking 'How long is it going to take to answer 23 across in next Sunday's crossword puzzle?' It might be fifteen seconds, it might take all day; until I have a chance to look at the puzzle I'm just pulling numbers out of my ass. The short timeframes encourage everyone to twiddle around the edges of things instead of doing real feature development; the arbitrary milestones serve mostly to make everyone feel like they're constantly falling behind.
I've discussed this with a bunch of people. Everyone seems to agree that we're doing Agile wrong, but even the strongest proponents of the methodology seem to be in complete disagreement on what the "right" way to do it is, or how that would be an improvement over the way we were doing things before.
So yeah. Not a fan.
The fact that we've all heard this line (yet never heard a solution) should make it pretty clear that it's more of a management religion than an engineering practice. "You're doing it wrong" is the perfect built-in, pre-packaged defense to the Agile system that agile managers/consultants/etc can rattle off with zero effort and an air of superiority. Had a bad experience? Well, you were doing it wrong. It's not an issue with the system.
I recently worked at a place that was the text book example of agile/scrum development methodologies -- Which I don't mean figuratively, I mean in the literal sense, their big claim to fame was that they were the subject of a case study on the success of Agile methodologies. So, having worked in a place that was studied for "getting it right," it's extremely annoying to see all critiques of agile had waved away under the flag of "you did it wrong"
Just about every complaint in the article existed at this place as well. For me, at the tip top of the list was meetings. Planning would take hours. Sometimes it would be split up over two days. That is two days out of the 10 you have available for development eaten up by talking about what you're going to develop. Then there's a meeting to show what we did in those 10 days. Then another meeting to talk about what we think we did in those 10 days and how it could be better (which was of course done through stupid time wasting games ("I wish I could have ___" "I was happy when ___", "I should start doing ___"))
Then layer on top of all that a whole hierarchy of people whose whole job description is to be "agile" -- which not a single developer was able to explain to me the meaning since the day I started.
I'm ranting too much, but the whole agile thing just gets under my skin. It's such a massive waste of time. Leaving that company was a happy happy day. I now work at a place where 'planning' takes 15 minutes in front of a white board. Engineering discussions take as long as they need with the relevant parties whenever needed. Other than that, you're left alone to fucking do your job.
Back when I was a wee lad, with nary a keyboard callus upon my digits, I learned about a little thing called Murphy's Law. In brief, it says that if anything can be done incorrectly, someone will eventually do it that way. It was a warning to those designing things, to make doing the wrong thing impossible, or at least much more difficult to do accidentally.
As a result, among those taught about Murphy's Law, "doing it wrong" was a design flaw. If, for instance, you could destroy radio reception in a handheld device by holding it in a particular way--a way that did not cause pain or discomfort in an ordinary human hand--it was the fault of the device manufacturer, not the user.
If you can do Agile "wrong", then it is a problem with Agile.
As for myself, I just think to myself that someone, somewhere, has weaponized an idiot, and has launched it against me. It is equal parts Inspector Clouseau, Mister Gumby, Ali G, Drunken Master, and a particularly evil djinn. He will do exactly what you ask, in the most malicious manner possible. He will follow a process with absolute rigor, and produce the worst possible outcome.
I firmly believe that such people actually exist--individuals so brutally incompetent that they are indistinguishable from malicious trolls. So you might as well plan around a person intentionally trying to break your design while still maintaining the plausible deniability of not breaking any of your rules.
Agile cannot hold up under the assault of a weaponized idiot. There are simply too many possible attack vectors.
Most of my experience with agile is in the XP flavors, where the mantra is no bugs. I know it's hard to believe, but I promise it's an achievable goal if the whole team single-mindedly works towards that goal.
You're right, estimating is hard. The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do.
That sounds great on paper. However, every implementation of Agile that I've ever seen or heard of eventually translates points to time intervals ("How many points should this be?" "Well, a one day task is three points, so...").
It's good to realize the known unknowns, but it's the other kind that will get you.
I like Scrum for the power of the retrospective, if people actually talk about issues, the the team really is empowered you can change those problems: a) Talk through how to handle bugs. There is no prescriptive answer, if you have a problem with defects then fix it, or develop a system to deal with them. You don't have to bring a bug into sprint after all, and if you do then get your Project Owner to drop an equivalent bit of work out. b) Refinement is a crucial part of the process, if you can't break up the task into 1/2 weeks worth of work for a team odds are you don't fully understand the task, which means you can't provide forward estimation, which means management can't trust you're numbers. c) "Project Managers" don't exist in Scrum, so a PM consultant guiding you on agile feels very, very wrong.
If your organisation can't commit to you working full (pretty much) time on a project working on a set of things that have been committed to without pulling you in another direction then odds are Scrum isn't going to work for you.
Scrum is very clear that there are certain things you need to do in order to say you're doing Scrum. Doing "Agile" screams following no particular sub methodology but cobbling something together. There's nothing wrong with that evolving, but it helps to be able to describe why you've gone in that direction. In your case it seems like you've had something foisted on you by external people talking out of their rear.
See, this is the thing: on the one hand it's supposed to be all about committing to a specific direction ahead of time and not letting yourself be pulled somewhere else -- on the other hand it's supposed to be all about developers being empowered to work on what's most important at the moment (I mean it's right there built into the name!) Those seem in direct conflict.
We don't have organizational pressure pulling us in different directions -- we have reality pulling us in different directions. I'm not going to tell a customer "no, you can't have that bug fix or that new feature yet, we have a Methodology to follow."
> "Project Managers" don't exist in Scrum.
Right. Just project owners, product owners, scrum masters....
> In your case it seems like you've had something foisted on you by external people talking out of their rear.
I think you're onto something there. (They keep changing their minds, too: one week it's fibonacci sizing, next week it's T-shirt sizes. One week it's scrums, next week it's kanban. The actual working process seems to stay the same, only the jargon shifts around.)
My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.
So they had lots of experience.
If you ask an assembly-line worker "How long is it going to take you to install this transmission?" they'll be able to tell you within a few seconds. But that's not engineering.
If you ask someone who's written essentially the same app five or six times before "How long will it take you to finish feature X?" they'll be able to tell you with pretty high confidence.
If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea. Ask them again, when they've re-implemented it a few times, and they'll have an idea then. Until then you can decompose the problem and do analysis on the pieces and make assumptions, but you still won't know how long it'll take until it's done because the industry has been doing this for like 70 years and the one thing we know is that scheduling unknowns and unknown unknowns is still very, very hard.
Scrum works if you've done it before. Apply it to green fields or systems with known wicked behavior, and you're likely to fail in quite a few ways, including pissing off your developers and boiling off the good ones for better work environments.
If none of those fit into sprints, what is the point of having them? What is the benefit of describing a feature as an epic sliced into stories spanning sprints, instead of just, y'know, getting it done?
I find this attitude to be a little disingenuous. Obviously every bug cannot be estimated perfectly, but the majority of the time there is some initial data to make a reasonable estimate with a margin of error.
For instance to name a few:
- Past experience with the module associated.
- Whether or not it has been reproduced locally.
- Similarity to other bugs that have come up in the past.
It's my job [or used to be :-)] to give estimates of bug fix times to management.
It usually broke down to:
- trivial (about an hour)
- nearly trivial (maybe half a day or a day)
- "I have no earthly idea". The last one of these that I fixed involved about twenty people, deep dives into our hypervisor and interprocessor communication mechanisms, research into some hardware details and three 100+ hour weeks about four weeks before we shipped. And we started out not having any idea where in the system the problem was (that took two of those weeks).
But the answer is, it will take me anywhere from 30 minutes to a month to tell you how long it will take me to solve this problem (over 1 month, I give up). Then, my answer will be: 5 minutes.
(Agile proponents have told me "Oh, that's exactly the wrong sort of group for Agile, it works best with larger teams of lower-level devs." Other Agile proponents have told me "oh that's the perfect sort of team for Agile, it doesn't work with big teams of juniors.")
The way it used to work was: Feature request comes from sales or upper mgt or customer or product designer. Designer does mockups or codes up a simple working prototype. Various team members look at it, we talk about how to implement it, everyone works on it as needed, we deploy it when it's done. If something else comes up in the meantime that's more important or more urgent, we set it aside in a different code branch until there's time to focus on it again.
The way it works now is basically exactly the same, except with lots more meetings and jargon and taxonomizing of tasks and arbitrary milestones.
(Agile proponents have told me "Oh, you were doing Agile already, you just didn't know it! Other Agile proponents have told me "oh, you're not even doing Agile now." Even its proponents can't seem to agree on what Agile is, which makes it really easy to tell its detractors that it's not Agile's fault, you're just doing it wrong...)
If you really need agile it will not help and if your team already rocks agile won't improve it, likely you'll already be doing something like it but customized to your needs.
I've seen a couple of fairly efficient teams utterly ruined by switching to 'agile' and I've yet to see an inefficient team become more efficient by deploying it.
If you need to fix a bug, it means that you are correcting an error from a past (implicit or otherwise) user story that shouldn't have been accepted as complete anyway.
Historically, most software development methodologies are excessively top-down, so people somehow still expect that from agile. Most devs are the sort that couldn't stand doing group projects in school, so the idea of organizing with teammates to produce something bigger and better than I could on my own is totally foreign.
If you don't explicitly name your development methodology, you still have one: you're practicing something called ad-hoc development. Unless you and your entire team are superheroes, there's an awful lot of knowledge being leaked away.
Here's the secret: software development isn't really about making computers work, it's about organizing knowledge. If your process focuses more on making the computers work than your institutional knowledge you're making a critical mistake.
Don't confuse some company's crappy engineering practices for agile just because they call them that. Stand ups are short. Period. If it feels like a "permanent PIP" your team could use some improvement. If it feels like a surveillance state it's probably not a very good implementation of agile.
Agile development is about making connections to your team members: individuals and interactions over process and tools. It sounds like the author's experience (as well as many other devs') is unfortunately in an organization that doesn't pay heed to that very first, most important agile principle.
See, this kind of vague, fuzzy feel-good description is exactly why it seems to me that the one thing everyone seems to agree on about Agile is that everyone else is doing it incorrectly.
A lot of things work well in theory. That doesn't really make them good ideas if they can almost-never be implemented properly.
That's a fantastic quote, thanks.
"0th Order Ignorance: Lack of Ignorance. I have 0OI when I (probably) know something.
1st Order Ignorance: Lack of Knowledge. I have 1OI when I don't know something. With 1OI we have the question in a well-factored form.
2nd Order Ignorance: Lack of Awareness. I have 2OI when I don't know that I don't know something.
3rd Order Ignorance: Lack of Process. I have 3OI when I don't know a suitably efficient way to find out I don't know that I don't know something.
4th Order Ignorance: Meta-ignorance. I have 4OI when I don't know about the Five Orders of Ignorance.
"
that couldn't stand doing group projects in school
But big-A Agile is a management school with its own dysfunctions. It diverges from small-a agile, which is basically a set of principles to help critique yourself with.
When you hire a manager (or "Scrum Master" whatever), they must convince top management to give them a job. Which is why Scrum Masters brag about their bosses "believing in" Agile, like a bishop happy that the king loves god. Then they impose some system which requires their highly visible involvement.
(That said, the Agile described in this article diverges from my personal experience.)
Scrum-English Dictionary:
* "sprint": artificial crisis
* "end of sprint": abandonware
* "Scrum master": resume credit for my planned escape to a new company
* "stakeholder": someone you can't get away with externalising your costs onto
* "simplified": doesn't implement any of the actual business requirements
* "lightweight": doesn't implement any of the actual business requirements, but does so much more elegantly than the version that works
* "easy": project was born circling the drain (and doesn't implement any of the actual business requirements)
* "legacy": the version that works and implements the actual business requirements, even if no sane human wants to touch it
* "velocity": a speed with a direction, so skittering about following marketing's random hairpin turns counts
* "retrospective": blamestorm incoming!
* "stand-up": getting the blamestorming in early
* "We'll put that on the backlog": hahaha fuck you
I do enjoy some of the jargon. "empowered": do your own fucking job. "Could you just copy down these log files from these fifteen servers for me and put them on the shared drive? Thanks." "I'm sorry, I'm afraid you're empowered to do that yourself."
Seriously: every good idea is turned into a bad one by the relentless management quest to Taylorise clue.
"Project Manager:" a job that no longer needs to exist in the astounding new world of Scrum. (Pay no attention to the project owners, product owners, story-writing users above you in the org chart or Scrum Masters behind the curtain.)
Blog version: http://reddragdiva.dreamwidth.org/594955.html
I saw meetings with middle managers (people who hadn't shipped anything significant in a decade) in daily meetings, going over burn-down rates of individual engineers and "expressing concern" through channels that someone was off their schedule by a couple of days. The daily scrums were just half-hour status-in-a-ring and some public shaming if you couldn't say that you did anything, so a lot of people made stuff up, or at least hedged by saying they'd completed 50% of the work or that tests were "nearly passing" (code for: my stuff is broked).
Oh, and in the mean time the build system we devs were using had been on fire and broken for three weeks and it was nearly impossible to get a working build. WTF?
I said, "We don't need Agile. We need an earthquake to collapse that wing of the building" (where the managers were; they liked to cluster).
We had Ken. Ken was there at the beginning for maybe a week, and for the next few weeks after that it was great. But we forgot that middle managers are still gonna manage, and that you have to fire them or they're still going to be there, you know, managing stuff, because that's all they know how to do.
And with the right tools, Scrum can be turned into the perfect surveillance state. (I stole that from another response in this thread, thanks).
Again Scrum relies on empowerment, with the Product Owner being the "single wringable neck" whose career is tied to the project and who has the buyin from management to get stuff done. The point being that it is in their interest to have a happy and productive development team doing what they say.
Finally there's also a really good point about internal and external metrics. I've always been a fan of management getting the stats they ask for, not being provided with access to the team's internal metrics which should really be short term to address perceived issues. If we count defects for a few sprints to reduce our defect count that is good, providing them for evermore to management is bad. Separating the two out lets your Scrum Master / line managers have a good conversation about what management are concerned about and how to effectively measure it.
As you said - bad managers won't do any of this, but then flagging up that you have bad managers is A Good Thing (TM) overall.
Which isn't to say that it's not a problem for agile -- it definitely is. I'd say that it's analogous to Gresham's law: when people can't tell the difference (until it's too late) bad "agile" drives out the good.
You can twist Agile, based on your vision of good team is. So you have to get the right people to implement it. You have to approach it from the idea of it being a collaborative, friendly, no blame etc for it to work.
I've only ever used estimates in story points to prioritize things(That's why its so abstract), not to monitor and push developers. If I wanted that, i'd use actual time.
The idea of everyone is junior is also bad implementation. It means even the most junior person is capable of contributing using their solution over a senior persons solution. The right idea wins, not the right person. I can understand why this pisses of senior people though.
IF teams are using Agile like that there doing it
wrong. It's meant to be recipe for collaborative,
relaxed, friendly environment.
For example, "sprint" evokes runners running 100m at a pace they can't sustain for minutes, let alone weeks or months. And "committing to stories for this sprint" implies it's some sort of failure or emergency if the target is missed - when in truth nobody should be skimping on testing or staying late to get things done.
I agree with what you said about "sprint," as that is the second worst word in the canon.
And user stories is trying to change the term "feature" so that developers will be more user oriented in their thinking, but the term "story" is disturbing.
The vast majority of work environments cannot be described as relaxed and friendly (hell, most of them probably aren't all that collaborative). Far more could be described as pressured hot houses.
Doesn't work if you're on knowledge work.
A lot of people approach agile as its an extension of those approaches. When in fact it was a reaction to it, by trying the opposite approach.
Spending 15 minutes per day making sure that everyone knows how the team is doing strikes me as a very easy way to avoid that.
Heck, it can be significantly less than that, if you use a tool to keep your tasks up to date and can just say "I got the frobulator finished, and moved on to the doohickey. Dave's giving me a hand with a small holdup there, and it should be finished on time." at the standup then the whole thing should take less than five minutes total, except when there _are_ issues that need to be dealt with.
I see right away one Agile defect: It prefers near-term "user story success" over long-term investments like creating debuggable architecture.
Why spend time now making things easier for the rest of the cycle if it's not a priority in this iteration?
Why write "gdb" when "gcc with printfs" will work fine, even if it simply requires more sprints?
Neither the Agile Manifesto nor even the far more specific Scrum Guide even refers to user stories.
A particular organization using Scrum may decide that architecture-related concerns are not important in the definition of "done" for items in their product backlog, and focus only on "user story success", but, to the extent that that's a problem, that's not a Scrum (and much less, Agile) problem, its an organization problem.
Agile is about what concerns you favor in figuring out how to get work done, Scrum is about how a team gets work done and defines the work it is to do within the framework provided by the wider organization, but the specific definition of quality standards for work is not directly addresses by either.
> Why spend time now making things easier for the rest of the cycle if it's not a priority in this iteration?
Why wouldn't an organization have maintaining (or improving) the overall architectural standards of the work a priority for every iteration -- in Scrum terms, part of the Sprint Goal -- unless there is a conscious decision to take on technical debt to meet some other goal? Agile, or even Scrum, doesn't tell you what goals to set, and you shouldn't blame them for you choosing to set the wrong goals.
With that slack, then, when things go right, you have time for dev priority tasks. You hit your sprint commitments two days before the sprint ends? Great! Time to work on some of those long term investments.
You can also scope stories based on dev priorities. You want to add a feature to part of the code that is in need of refactoring? Scope the story to include that refactoring.
Etc.
If using Kanban or something, it's a bit harder; you can easily take time for dev tasks (since you're not making commitments), but finding the right balance of taking them on but still getting feature work done is harder.
The most problematic part of SCRUM (and the first thing to start killing productivity) are the interminable meetings it facilitates. The SCRUM master is constantly trying to gauge scope on this or that feature, and everyone feels like they need to bring up what they've been working on during the standup in order to feel like they're not appearing to be slacking off.
I've abandoned SCRUM in favor for a Kanban approach that puts the onus on the Product Owner to manage and estimate scope and deadlines, thereby leaving us developers alone to focus on our work.
I've written more about my approach here: https://medium.com/@glenelkins/agile-is-good-for-managers-bu...
To each his/her own I say.
Fully understand that process is a technology.
If Agile is so bad, what's better?
Best teams I've been on have been self-organizing, with a few senior engineers who did heavy-lifting and some less experienced engineers learning new stuff. Management was minimal (the more we had, the more things sucked).
- Minimize management. Minimize management. Minimize management. Management exists to set very high level directions and to remove obstacles.
- Make sure that different teams talk. A lot.
- Get real. Don't blow smoke up people's asses. Making a schedule with a granularity of a day on a six month project is fucking bullshit. Just stop it, okay? You might be able to do this a week out, but not much more than that. If that deadline is important, be clear on why. (I've been on projects that have been absolutely killed because someone felt they had to ship on magic date X, when shipping a few months later would have saved the product).
- If you are working steady 60+ hour weeks, you are doing it wrong. If you are doing regular 80+ hour weeks then you will burn out and leave.
- It's done when it's done. Ship it, and iterate.
"It's aggressively short-term, by design" - The whole post talks about 6 week projects. Scrum is terrible for that as it imposes far too many meetings. Scrum works for the complex space where you say "12-36 months" as your gut feel estimate. It is a reaction to the waterfall world where you'd discover 2 years in you weren't building what the business wanted.
"It has no regard for the programmers' career needs or desires" - Stories make for excellent opportunities for juniors to "own" bits of work from initiation to completion. Old school projects provided very little opportunity for juniors to work on requirements gathering and thus a big chicken and egg problem for promotion. It also offers plenty of opportunity to interact with your customers, which is almost always a good way to get promoted.
"The story points are there to track productivity" - Oh noes the people paying you want to know how long the project is going to take to be done. The talk of many status meetings seems decidedly anti-Scrum and is an excellent example of the sort of thing that people should be screaming about in retrospectives.
"It punishes R&D" - Ironically it can be a really useful opportunity to conduct R&D. Scrum makes you have something measurable and a time frame in which to conduct it, which makes for an easier sell than an open ended request. I think what annoys some is when they get shut down too quickly, or are forced into taking a less technically interesting approach that delivers enough business value. Scrum isn't there for pure research into the theoretical, but then no-one is claiming it is.
Killing businesses - Much like every tabloid headline everything can kill you. Value destroying mergers exist in abundance, and poor leadership/management is a real killer. Plenty of companies do very well out of Scrum, especially when they are in a cost centre environment.
I might sound rather "no true Scotsman" when it comes to Scrum but there are only a few things you need to do to be "doing Scrum". What it does give you is a powerful question to ask, and a regularly mechanism to raise it via the retrospective - "why are we doing X when it isn't in Scrum?".
0_0 Y...you didn't just write that, right? I'll be unusually charitable and give you a chance to think again about that sentence up there.
> "The story points are there to track productivity" - Oh noes the people paying you want to know how long the project is going to take to be done.
And yet, points aren't supposed to be translated to time intervals..... (Spoilers: in practice, they are.)
Points don't have to track time intervals to give you a sense of progress. Averages are a powerful thing, hopefully management is focused on long term graphs not getting het up about the number of hours difference between your tasks for two similarly pointed stories.
Oh and Scrum makes no requirement re using story points - it only requires that backlog items be estimated. We estimate tasks in hours and stories in points for instance, Scrum doesn't care. All our Product Owner shows to the stakeholders is a burnup with just numbers on the x axis.
The original (rather long) title is "Why do some developers at strong companies like Google consider Agile development to be nonsense?", and it seems it was shortened. There's a spurious "at" left in there now which breaks it.
(1) Company decides to devote resources to a feature.
(2) Developer writes code and submits patches upstream (e.g. to the Linux kernel).
(3) Upstream takes some indeterminate amount of time to get patches into a release.
(4) Company defines a downstream (i.e. commercial) release based on a particular upstream release.
(5) The possibly-pristine but also possibly-unrecognizable code from (2) is pulled from the upstream release into the downstream tree.
(6) More testing, debugging, tweaking, etc. on the downstream tree yields an actual release.
Just in (3) we see one part of the problem: upstream quite likely isn't agile/scrum themselves. Often they don't care about a particular vendors' release schedules; if they do, then someone would argue they're "dump and run" fake open source, and not a true independent upstream. They're almost certainly not going to give a crap about sprints or story points or anything else about the local agile/scrum process. These methodologies pretty much don't work unless everyone is completely committed, and with separate upstream/downstream that's just not the case.
Even with everyone on board, the disconnect between (2) and (4) is a problem. Pushing code upstream and pulling it downstream are two separate tasks, even if they're done by the same person, and there's this big gap between them. At best, this makes scheduling more complicated. More often, it makes agile/scrum style fine-grain scheduling and tight coordination impossible. Measuring "velocity" and all that isn't possible when there's so much externally imposed variability.
For something that's long term and systems-oriented and open source, these methodologies are practically useless. Actually they're worse than useless, as they misdirect effort and interrupt useful work. YMMV.
The saving point of Agile is breaking tasks into reasonable sizes, long enough to actually get something done and short enough to rearrange as needed sooner rather than later, and to delay interruptions until they can be evaluated and other tasks completed. I can't get to what I need to do if the relentless onslaught of self-important "do this _now_!" interruptions are handled as they occur; Agile provides a sane way to say "get in line" such that important issues are addressed in a timely manner relative to other issues and without compromising other stuff that also needs doing (those that never reach the top of the interrupt stack, but without which long-term progress won't happen).
Every company has "cowboy" programmers who break shit and ruin their coworkers' lives with massive 1am check-ins, and a lot Agile seems designed specifically to put up road blocks to prevent this from happening. Managers love it because it provides an escape from dealing with problem employees directly. Most of the vehemently anti-Agile people I've worked with were grossly overconfident in their abilities and difficult to work with, which I think supports this idea.
Unfortunately, the only way for this non-management technique to be effective is to do it dogmatically with no deviations (otherwise the cowboys will always have some excuse for why it shouldn't apply to them), and this is where things start pissing off the actual talent.
If you feel too good, or too senior for a programming methodology like Agile, then you are bound to not like it. Is that a fault with Agile, or a fault with your attitude?
A cowboy coder is not micro-managed, does not seem to need atomized tasks, does not need a direct line with the customer and decides on the complexity of the problem and the solution all on his own. They are also terrible to manage and hit-and-miss when it comes to actually shipping something with business value.
Bluntly spoken, Agile is there for the project managers, not the project developers. Agile should be implemented for as long as productivity increases, customer feedback loops create desirable features, and iteration cycles become tighter and shorter. If you know a way to increase those stats without Agile, then write your own methodology (http://programming-motherfucker.com/ is taken) and join management. If you don't care about those stats, and feel too good/senior for Agile, then start your own company and proof it to yourself. You don't start to measure a project's success by first counting the number of developer complaints. You could probably keep the complaints at zero, and never ship anything of impact.
1) Attack the lowest-priority and easiest stories to shoot for quantity, not for quality. This way you'll be closing stories in no time, pleasing the scrum master and product owner during the daily standup. Leave the largest and most complex problem for last - if nothing else, you can kick the can down the road by claiming it's tougher than it seemed, requires more points and should be moved into the next scrum.
2) Do not worry about the quality of your work. In fact, the lower it is, the more stories you'll have to fill in the next scrum - "widget for feature X" with some effort can become "fix bug Y with feature X", "improve widget performance when more than 1 user uses the product", "improve logging and monitoring of widget X" and tons of other, lower-priority, but higher-quantity stories (see point 1 of this). You'll likely be closing a story a day, earning points way ahead of the other suckers who choose to focus on long-term critical design/architecture issues.
I think the number 1 misconception is the sprints. He seems focused on 2 weeks as being the requirement, when it's on the recommendation. Some team have gone as long as 4 weeks. The whole point to a sprint is that dedicated time to a delivery with fast feedback from the customers. It's mainly so you can fail early, ail often. It's much better to spend 2-4 weeks building the wrong product than 6 months.
Second, his claims that product development, research and design, and architecture don't belong in a sprint are also misinformed. The focus on user stories to remind people that they need to focus on users, not gold plating. In any technical project, there are a plethora to improve on the design. People can (and have) sat down and refactored and "rearchitected" for days and days. At the end, they build beautiful systems that don't offer any advantage to the customers, or have implemented a number of features the customer didn't want, or have fixed a series of concerns the customer wasn't concerned with. There is give and take of course, as the engineers needs to give feedback to help the customer understand the benefits of the feature or risks of not fixing the issue, but those need to happen first before people go off and construct digital masterpieces.
Third, micromanagement. If you have endless meetings in agile, you're definitely not doing it right. The 3 big meetings, planning, retrospective, and demo, are ones that take the most time. Standups take no more than 15 minutes. The other tasks, meaning, backlog grooming and prioritization should not involved your sprint team. Those need to be done offline by the product owner. Agile may be about teams, but you still need strong leadership.
The only point of his that has any relevance is the last one, where consultant firms have made big bucks spinning out variations of agile because people just can't understand how simple it is.
Holy crap, how wrong can some orgs go? The team should own the process. If there is R&D that does not match with scrum then the team should have a) a r&d framework or agreement in place b) the authority to say this is r&d.
The process does not own the team. The team owns the process.
We have found, for instance, that the 3 questions of standup are pretty useless. They make each person feel like they are justifying their existence at the company. By dropping those questions and framing it in terms of a deliverable we found the meetings to be far more productive and better for morale.
We've decided to give ourselves 1 day into the sprint to better guage progress so we can define achievable sprint deliverables, as we don't often know enough information during sprint planning.
Each of these is set up as an experiment, designed to solve an identified problem with our workflow. And the results are great.
For starters, a very significant part of the article relates to performance anxiety over story points. Over 6 years of doing this, I've had two instances where people were called out for not putting points on the board, both of which came from outside managers not familiar with Agile.
Besides that, one of the core tenets of Agile is that you adjust the processes to work for the people involved. Trying to enforce some arbitrary subset of Agile processes on a team is a recipe for failure and frustration.
This reads to me like "bad managers are bad at managing Agile processes".
Give it a watch: http://www.thoughtworks.com/talks/the-death-of-agile
Blog post version: http://pragdave.me/blog/2014/03/04/time-to-kill-agile/
Let's face it. There is no methodology that will make all software development projects around the world go smoothly and fun to work on. If you work with, or for, a bunch of dicks, you won't enjoy what you will be doing all day. No methodology is going to change that.
I would like to go as far to say that "any" methodology used by great people will automatically result in great things.
As to the specific points:
1. Here, the claim is: There is no place for an actual senior engineer on a Scrum team. The only way to move up is to become a "Scrum Master", a bullshit management role that involves responsibility without power.
There are several errors in this description: First, "Scrum Master" isn't management role, its a facilitation role focusing on expertise with making Scrum work in the particular organization. The only quasi-management role on (or related to) a Scrum team defined in the Scrum Guide [0] is the Product Owner (which does have authority to go with that responsibility.) Either of those is a role a team member could develop into; the idea that the SM role is the only "way up" on a Scrum team is incorrect even within the narrow bounds that are defined by Scrum.
OTOH, Scrum itself intentionally -- to support its use in organizations using Agile practices -- defines only a narrow slice of practice, particularly, a basic model for operation of individual development teams. It does not prevent having different roles outside of the defined interactions within the Scrum guide for members of different seniorities or specialties, it only requires that for the purposes of the interactions it defines, only a narrow set of roles ("Team Member", "Product Owner", "Scrum Master") matter. So, consistent with Scrum, there can be room for moving up on a team. And real organizations using Scrum on projects greater than a single 3-9 member team use complementary practices like the Scrum of Scrums [1]; being a Scrum team's representative on the Scrum of Scrums and thus playing a larger role in the coordination of the overall work of the project is one way for a technical contributor on a Scrum team to move into a role with broader scope and exposure.
2. Here, the claim is "It's aggressively short-term, by design" and "if you carry this way of working on for months or years, you get a lot of technical debt and you get low morale."
It is certainly the case that Scrum, specifically, largely addresses tactical-level, short-term processes. This is because Scrum isn't a full-stack methodology, its a narrow set of practices designed to adopted as part of a larger set in an organization working in an Agile manner, and to be relatively neutral to the other practices. Certainly, if you apply Scrum alone with no higher-level strategic processes that set standards that constrain the definitions of "done" for work done in sprints to avoid technical debt, there is a lot of potential for an organization applying only what is in the Scrum guide to lack long-term focus and development technical debt.
3. The claim here is "It has no regard for the programmers' career needs or desires."
Agile, as a set of principles, certainly does; Scrum, as a particular set of practices, does not, for much the same reason addressed in the previous point. Largely, though, this seems to be a restatement or alleged further consequence of the first complaint about lack of a way to move up (it essentially seems to be, "because of #1, Scrum leaves me nothing interesting to put on my resume"), and so the response to the first complaint above largely addresses it.
4. There's a lot here that deserves separate responses, so I'm going to break this one up.
> "It's micromanagement."
No, Scrum is the opposite of micromanagement, since the "management" is done almost entirely by the team.
> "User stories and backlog grooming are there to control what the engineer works on."
Sure, those things exist to define work, but they are done by the team, so can hardly be viewed as micromanagement of the team.
> "The absurdly frequent meetings (and so many different kinds of status meetings!) are to intimidate him into not slacking."
Scrum defines four kinds of meetings: the Sprint Planning meeting, the Daily Scrum, the Sprint Retrospective, and the Sprint Review. Of them, the Sprint Review is the closest thing to a "status meeting", though even their the focus is demonstrating the concrete deliverables for the Sprint rather than status reporting. All of the rest are primarily action/planning meetings. "Status" of a sort plays a role in those meetings as an input to the planning aspect, but if they become status-focused meetings rather than planning-focused, you've definitely lost the defined purpose of the meetings in the Scrum guide.
> "The story points are there to track productivity (in some superficial, inaccurate way)."
Story points (in methodologies where they are used; they aren't part of Scrum) exist as a planning tool for the team, not a productivity measure.
5. The claim here is "At identifying low performers, it has an unacceptably high false-positive rate."
Scrum (and, a fortiori, Agile) is not a process for identifying low performers, or for performance evaluation at all -- its completely out of scope. Its not that it is good or bad at it, it doesn't even address the issue.
6. The claim here is "It punishes R&D, and it hurts the best engineers the most" because "Agile and Scrum [...] single out and humiliate anyone who works for 2 weeks and doesn't have something to show for it."
Research is a separate domain than product development, and there is no reason that the use of Scrum as a product development methodology should have any impact on how research is done. Of course, Scrum is a generic enough process that you could use it to manage research efforts as well, but the backlog items, associated definition of "done" for those items, sprint length, etc., would all likely be very different for a research effort than a product development effort. You could mix research items into the backlog of a team also doing product development, but then you probably have a problem defining work items that are appropriate for the product development sprint length. (This is less of a problem for non-Scrum methods that use a flow method for backlog management rather than a timeboxed Sprint cycle, because then its easier to mix items that have a longer-than-usual time involvement into the same backlog; the sprints used in Scrum place an effective upper bound on the size of work items.)
7. The complaint here is "I have actually seen it kill companies" backed by a single non-specific anecdote and the assertion that it generalizes. From the description, this appears to be a top-down all-at-once conversion to a new defined methodology. If one has processes in place, for the same reason one adopts incremental change to a software system where you've got an existing, functional system unless there is some reason you can't do incremenetal change, the same thing should be done to a software development organization. Failure of an organization (or many organizations) to manage a big-bang change rather than incremental change doesn't invalidate the methodology they sought to change to any more than failure of an organization to manage a big-bang software system replacement invalidates the technology they sought to change to.
[0] http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US...
[1] https://www.scrum.org/Blog/ArtMID/1765/ArticleID/12/Resurrec...