Agile has to work with actual human beings. Holding up the dogma and saying 'well perfect people would succeed' is more One True Scotsman. If nobody is a True Scotsman, what is the point of Agile?
I mean there is clearly some kind of genuine problem here, agreed, but the problem I see is "why do these people think they're doing Agile when they're doing literally the opposite of everything in the definition". I'm genuinely baffled. Is it a cynical lie from managers, or the consultants they hired? Do they genuinely believe they're doing it, and if so, how did they come to think that? Did this happen with other methodologies - did you get companies that claimed to do e.g. RUP or Six Sigma but were actually doing the opposite of everything those methodologies prescribed?
In my experience barely anyone who claims to work Agile ever looks at the values or principles, or reflects about their own work in a systematic way. Scheduling Scrum meetings is easy. Applying Agile principles to your actual work is difficult, especially if you are already overwhelmed by Scrum.
People like Scrum because it distracts from Agile and doesn't interfere with your work much. You can serve time in Scrum meetings, then return to your actual work. Scrum fills a void, but doesn't ask any hard questions. Don't think about what you are doing, just show up to the meeting and go through the motions.
People like to follow pre-made structures like Scrum. They don't like to define or change them. You could potentially insult someone. "The Scrum Guide says so" is less personal than "it makes more sense to do X". Clinging to a fixed process like Scrum inhibits being actually Agile because Agile is all about changes. Change requires courage. Most employees don't feel like courage will be rewarded. In our culture, courage is reserved for big companies or top-level management.
In short, that's why "Agile doesn't work".
There's no mystery here. Lots of stories the illustrate how they went wrong. People being people.
Maybe they need more work on the front end, to condition participants to not bring their conditioned responses into it because it requires a new attitude or something.
Then it's not a standup. Maybe you can find another way to achieve the same aim, or maybe Scrum isn't suited to remote workplaces (I don't have enough experience either way) - if someone had tried to follow agile practice in a remote environment and found it doesn't work there, that could be criticism I'd be interested in hearing. But I just never get the sense that someone has actually engaged with Agile and found it wanting[1]; it always seems to come down to something like them: "Agile sucks" me: "What's wrong with it?" them: "We have this mandatory Agile meeting that everyone involved in agrees is pointless", just some criticism of something that has nothing in common with Agile except for both being a process.
> What about managers that fall into injecting themselves into every standup? Hard to fix that, hard to eject your manager from a meeting, and its a likely state that becomes the inevitable end point (see Markov Chain).
I haven't experienced managers in standups being a problem, but taking it as given that it is for you: if you're saying that you can't fix that then aren't you essentially saying that any process that your organization adopts will inevitably fail (unless you adopt a process with no meetings at all, which has other problems)? Agile gives you every possible explicit opportunity to fix the broken things in your process, including a regular dedicated meeting that's devoted solely to doing that; if your organization is incapable of doing that then I'm not sure what could ever work.
[1] Not actually true; there is a group of people who prefer more up-front planning and tend to give a quite different genre of critique. But they also tend to be more measured and don't frame it as a problem with agile as such.
Why not? Who cares if they're actually standing? They can lay on the floor if you ask me, as long as they can share the status with team members.
I see a different problem with standup. Plenty of people applying the same rule over and over without understanding what's the real goal of standup. Plenty of people just take the virtual stick of the speaker (or sometimes not virtual) and say the same mantra every morning "I've done this, I'm doing that, no problems," and pass the stick to another.
But the real goal is not to check up on people to make sure they are doing something. In fact I couldn't care less if you are doing something or not. You could sit there watching cats videos all day as long as, in the end, all TASKS are completed. If you can sit doing nothing your team have a different problem, obviously, but that's another story.
The team have made a commitment on Monday that they deliver some features till Friday (assuming weekly iteration.) So what they do? They create tasks. The team is tracking the tasks on the board and the team should check all tasks every morning. Start with task #123. Who's doing it? John. So, John tell us about it - what's status, when can you complete, is everything smooth? Then you take next task - #124. Who is doing it? No one. But then John says he can complete current task today, so he's going to take it. And another task... Your standup should be about tasks, not about people. The difference is subtle, because it the end everyone should share the same info - progress, blockers, etc. But by checking on tasks the team members automatically build mental model of current iteration. How far are they? Is the tempo OK? Or maybe there's some delay and, finally, can they deliver on time? People will understand better where they are somewhere in the middle of the week and this is the key point. To share and understand. Not to report, forget and just go doing your job.
The output of the iteration is the work done. Check the work, not the people.
Standing up was a specific solution to a specific problem. There may be other ways to achieve the same thing, but you should be aware of what you're doing.
> Your standup should be about tasks, not about people. The difference is subtle, because it the end everyone should share the same info - progress, blockers, etc. But by checking on tasks the team members automatically build mental model of current iteration. How far are they? Is the tempo OK? Or maybe there's some delay and, finally, can they deliver on time?
This really doesn't seem such an important distinction. You assign tasks to people in your iteration planning; if a task is stuck it will be because a person is stuck on it and vice versa.
Agile explicitly puts people in my way, regularly, and with demands that I report progress with imaginary metrics.
That's how I'd fix it. In fact I became a contractor so I didn't have to do agile any more. Now I get tremendous amounts of work done, using my experience and talent to attack root causes and write the critical code to get the job done.
I see its a whole different attitude from Agile, I get that. But I'm adamant that I don't want what Agile does.
Now getting to specifics:
>Here's a process that works: leave me alone to get the job done, and I'll report progress to you regularly. Leave the manager out of my day to day activities.
I do not think agile requires the manager be involved in day to day activities. If he's insisting on it, he's the problem - not agile.
Reporting progress daily is reporting progress "regularly". Having said that, I do not think agile requires daily progress reports.
As for leaving you alone - that's great if your work doesn't depend on anyone and no one depends on your work. It works if your work is small enough that it can be done by one person. Rarely is that true. But if it is for your work, by all means it's a fine approach.
>That's how I'd fix it. In fact I became a contractor so I didn't have to do agile any more. Now I get tremendous amounts of work done, using my experience and talent to attack root causes and write the critical code to get the job done.
There's plenty of work that can be done that way. I think you'll find plenty that cannot. I don't think you can build a standards observing web browser as a contractor.
And as for 'small units', that's an agile myth. Many important tasks take concentrated effort over many days or weeks. 'Small enough for one person' doesn't quite cover it. It about how many folks can understand the topic without being there with you in the trenches. Its pointless to go to standup and say "I've a problem with logging in the presence of disk errors, where the driver interacts with the log buffering by generating more log messages". Nobody going to offer useful help without actually recapitulating the work you've already done. So what's the point?
I admit there are many generate-the-web-page-of-the-day tasks that can be turned into assembly-line work. Sadly there are too many jobs like that. I'm not working at any of them.
This is commonly claimed, but I've never seen an example (in software) that stood up to scrutiny. People can always find a way to deliver some useful, visible value within two weeks of one person's work if they spend 5 minutes actually trying to think of a way to do it.
> Its pointless to go to standup and say "I've a problem with logging in the presence of disk errors, where the driver interacts with the log buffering by generating more log messages". Nobody going to offer useful help without actually recapitulating the work you've already done. So what's the point?
If you're making progress on your task and just need to spend some more time, it's fine to just say as much. If you've been stuck for a while, maybe it is time to ask someone else to come work on the problem with you - or at least time to warn the end client that what you're doing is going to be late. Taking a few minutes once a day to look back and decide whether you're actually making any progress or need to stop and reassess is about the right cadence, rather than blindly bashing your head against the problem for weeks or months.
(Sometimes bashing your head against the problem for weeks or months is the right thing, but it should be an explicit, conscious decision to do that)
And the flipside is that it gives people who need input from you a scheduled point to ask for it, rather than interrupting your work. Presumably you're working on the same product with these people and so what you do affects each other - otherwise why are you in the same standup or even the same team?
I think you're confusing me with someone who is a big fan of agile.
>And as for 'small units', that's an agile myth. Many important tasks take concentrated effort over many days or weeks.
Nothing in my comment suggested small work means it can't take days or weeks.
Note the following phrases in my comment:
>It may for you,
>But if it is for your work, by all means it's a fine approach.
>There's plenty of work that can be done that way.
I've repeatedly given hints that I don't think agile is a universally valid approach. I have my own criticisms of it. I left my last team due to some of the problems that agile presented. At the same time, I've been in teams where agile definitely would be an improvement and I would recommend it to them.
You are coming across as someone who is not OK unless everyone agrees with you that agile sucks and is always a poor idea. Sorry - I don't agree. Just please don't characterize those who disagree with you as agile fans.
Finally, let me address this (said by others in this thread):
>Yeah its always somebody's fault, never agile. That's what makes this classic No True Scotsman.
No True Scotsman applies only when there is not a clear definition or source. It arises from vague notions, which results in everyone having their own definition of what a Scotsman is to the benefit of their own argument. This is not what is going on here. In fact, the argument applies more to those who are criticizing agile as they are the ones who are creating different definitions of agile.
What is agile is not ambiguous. This document is what agile is:
http://agilemanifesto.org/principles.html
Criticizing what is not in there is like me criticizing the US Constitution because there exist some silly laws in my state. And then when people point out the constitution doesn't mandate those laws, responding with "That's just a No True Scotsman!"
If its not exactly what NTS is then lets use some other phrase that better captures "Lets continue to apologize for the failure to implement the agile manifesto effectively in many situations". An effective business practice has to be able to be put into practice. Without a large potential-energy-hill of retraining and right-think and group buyin. I don't think agile is that thing. I'm sure some small groups have successfully done something they call agile (not yet convinced its by simply adhering to the manifesto), that's great for all who succeeded.
But the war stories of failure are pervasive.
I do not find them to be any more pervasive than non-agile methodologies. And success stories do exist, so it clearly is not an unqualified failure. This looks like a case of "We can hate it because someone gave a name to it".
Hah, I almost said that that's where this genre of agile criticism seems to come from: the coder who believes they can produce a good product by writing good code without interacting with a customer and so regards any process as an impediment, and isn't actually attacking agile so much as attacking the very concept of process. What you propose is a good way to produce elegant code that doesn't actually do what the customer wanted at all; even if you personally can magically understand the requirements every time, a customer (or a manager) is right to be skeptical, because most programmers can't.
I haven't had too many problems with online scrums/standups. The basic rules are the same, every gives a quick breakdown on what they did, what they are doing and any issues they have. You just don't have people physically in the same location.
I will say the biggest help when dealing with the remote situation is having someone willing to take decent notes and send a quick email with a summary, which helps compensate for the lack of face-to-face.
If Agile is to be damned, let it be damned for what it is. But complaining that "Agile" doesn't work when you take it, do everything pretty much the opposite of what it says, but insist on slapping the label "Agile" on it anyhow, isn't a very compelling argument. Before you have a problem with methodology, you have a problem with terminology.
There is a sense in which Agile can't help but succeed, since it boils down to "Do the things that work, and keep checking that they work and check whether new things would work". The problem is, people don't want to do that. They don't want to have to do the checking work, or the thinking work, for any number of reasons (a few good, mostly bad). If you won't do things that work, check that they work, or sometimes try new things to see if they work, you can't expect the benefits of doing thing that work, checking to see if they work, and trying new things to see if they work, no matter whether you call it Agile or Scrum or Bumblekitty.
Lean (on the production side) because they failed to take into account one of the most important concepts of lean: employee empowerment. Rather than letting workers improve their own processes (or identify improvements to be approved by engineers if they made sense, some shortcuts don't need to be taken), they had management, engineers (sometimes), and manpower specialists walk through the area and come back to the workers with a statement like: Put X here, and Y there, that'll shave off 200 round trips a day and save you 2 hours for the work. They may not be wrong, but they've intruded on the worker's area without really consulting with them. They also gave the impression that the freed up time would be used to cut staffing (because now they can do more with less), rather than take on more workload. This scared the employees.
Agile (on our software and services side) is failing for the same kind of reasons.
"I heard we should have daily standups, so everyone have a daily standup!" Some teams have used it effectively, others haven't. Their leads don't know what to do with the time.
Then we had people who insisted there's no planning in Agile (which is not true), and thought you could just throw things on the backlog and pull it off the queue and that'll be fine (they never go through the backlog and treat it correctly, prioritizing and grooming it). Which creates a bad result almost every time (surprise!). This leads to a bad impression amongst workers ("Agile doesn't work here.") and management ("Agile never works.") and customers ("We want you to lay out your 5-year detailed schedule because that 2-week at a time thing failed spectacularly.").
The two extremes of Agile Adherents are both present here. Those who mistake Agile for Scrum or SAFe and believe there's a one-true-way with heavyweight (but not Waterfall!) processes. And those who believe it's an anarchic free-for-all with no processes and no plans. Both have missed the point of it, and both have made my job and efforts much harder.
I mean, I've done agile with a team of maybe 30-40 people. It worked great... for a couple of years. When it fell apart, the problem was that upper management didn't know how to manage something that wasn't waterfall-ish.