This article cements in my mind the issue: devs tend to take away from agile what they expect to find, rather than taking the time to understand the motivations and whole scope of activities.
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.
The free e-meter at every desk is a valuable job perk! The Kool-Aid tasted a bit funny, though.
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.
Every methodology fails from pretty much the same reasoning.
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).
The term has been hijacked. It is useless. There is merit in the idea that it once encapsulated, but it has long since been co-opted to mean something almost completely the opposite of its original intention.
IF teams are using Agile like that there doing it wrong. It's meant to be recipe for collaborative, relaxed, friendly environment. Not a pressured hot house. If your goal is to use Agile to push developers to their limits, you've already failed the Agile Test.
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.
One thing about Agile that I don't see mentioned much is that it provides a way for bad managers to marginalize the effects of low performers among their groups, though at the expense of high performers.
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.
The micromanagement - if management doesn't trust you to get on with work without having to justify what you've done every single day, why did they bother hiring you in the first place?
Agile is like CrossFit: the techniques are sound, but the techniques really aren't the point. The point is to create a revolution by wrapping sound techniques in an us-vs.-the-world ideology that has strong emotional appeal. This makes it easier to sell trainership certifications, which are where the money is.
Agile done wrong destroys more than Agile done right can fix.
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.
If you get stuck in an agile environment, here's a survival guide:
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.
Reading over his points make me think the OP is a PM who doesn't understand Agile nor his role in it. The number of misconceptions he presents reads like someone who has never bothered to research agile, but only knows what consultants have taught him.
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.
Agile development is another tick in the long series of desperate attempts by management to avoid The One Thing That Actually Usually Worksâ„¢: Hire great developers, pay them a ton of money and give them a lot of freedom and time.
An eager beaver at one of my client's is introducing Agile as a "Waterfall silver bullet."
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?
"Agile and Scrum, however, single out and humiliate anyone who works for 2 weeks and doesn't have something to show for it."
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.
I always try to differentiate between Agile and agile. Agile (proper noun) is the overly defined practice of scrums and points and backlog grooming etc. agile is the practice of continuous iteration at all levels. Agile is a great starting point, but if you aren't challenging the prescribed format and iterating on your process itself then you are missing the point of agile.
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.
I don't know how the author is doing Agile, but it doesn't match my experience. I've implemented "Agile" processes on four different teams, and while certain aspects were more successful than others in different contexts, nothing was at all like what is described in the article.
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".
Pretty spot on, I think.
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...
The title is completely mangled.
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.
The thing that I don't understand about the way Agile development is treated is that it is often treated like a silver bullet. As the article points out agile has use cases where it is effective but many treat it as a "Waterfall Killer".
So instead of Agile we should use, what?
Fully understand that process is a technology.
If Agile is so bad, what's better?
Dave Thomas (one of the original agile signer peoples), gave this amazing talk criticizing modern, commercialized agile instead of the developer-focused way of "developing with agility".
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/
I've seen many criticism of agile/scrum as they (don't) apply to long-term or systems-software environments, but another disconnect I think people need to know about is with open source. Here's the "upstream first" development model typically used by Red Hat (my employer) and others.
(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.
Any methodology in the wrong hands will be a terrible experience.
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.
Experienced engineers have seen a lot of "magic bullets" both on the process side and the product side. Generally they turn out to not be a substitute for hiring good people and getting good leaders to define a quality product and focus the team on what is important both short and long term.
If scrum metrics are used to identify low performers then that's so bad it's not even wrong. The whole point of agile estimates is to teach the team to estimate and pay attention to it. It's a learning tool for the team.
First off, Agile isn't a software development methodology, its a set of principles for an organization to apply in selecting/developing in its own software development methodology (you could call it a software development metamethodology.) Scrum is more of a methodology (and, while it may have emerged from the people involved applying Agile principles in the context in which Scrum was developed, and has features designed to support use in an organization applying Agile principles, there is nothing fundamentally Agile about Scrum -- or any other development methodology; if some decisionmaker is sold on Scrum by some consultants and adopts it as a top down practice, that organization may be doing Scrum, but they aren't doing Agile -- in fact, they are doing exactly the thing that Agile is a reaction against.) Almost any time someone uses the phrase "Agile/Scrum" they either mean Scrum or something that is neither Agile nor Scrum. In this case, the criticism seems to be of something that is neither Agile nor Scrum, though it may be related to the latter (but not at all the former.)
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...
To go through some of the points I fundamentally disagree with: "There is no place for an actual senior engineer on a Scrum team" - There absolutely is, who is peer reviewing the code, working with the BAs to design the architecture, identifying the technical dependencies in the backlog? Scrum is not a methodology for writing code, it is for getting a series of tasks done. All the things a senior dev needs to do on top of code can be broken into tasks, Scrum adds a weekly "is this still the most important set of things to be doing?" meeting into the mix.
"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?".
How do you know someone is an agile believer? They tell you! (every single day at the stand up)
Agile as dogmatically crapped out by the so-called agile consultant-tards, is what kills agile in the hearts and minds of developers.
This matches my experience.
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.