Aaron Held, coworker at CIM, “A House With No Front Door Keeps you off the streets”:

Scrum and Agile are desinged to solve this by making it a team effort. So in Scrum it is not the “developers” that build this Dr Seuss house, but the team. I think this is why many people fear Scrum. There is no “justifiable failure”.

CIO.com: When Agile Projects Go Bad:

Agile development also depends upon the engagement of the sponsors or customers in the process. That’s a difficult transition for some, according to Cockburn. “It looked like for a while that we were pushing all the power down to the programmers, but in fact we were evening out the power and responsibilities. Everyone gets to feel awkward about that.” In some organizations, he says, programmers ignored their bosses and built whatever they wanted.

At the other extreme, programmers expected the bosses or managers or sponsors to tell them accurately what the priorities were–not something the managers were used to. “So you get a breakdown on both sides,” says Cockburn. “The sponsors aren’t used to being asked to show up and care about the project, even [about] the requirements. … They say ‘No, that’s what we hired you to do.'” The programmers respond, ‘We don’t know; we need you to help us figure it out,'” he adds. And the sponsors say, ‘We don’t have time. Work it out yourselves.'”

Scrum – when practiced as intended, makes it hard to for CYA measures in development, planning, or management. Aaron has a point. That’s scary to some I would think.

Steve Yegge talks about Google’s development (circa 2006) process – a process that is focused on being agile – and riffs on just how bad “Bad Agile” can be: Good Agile, Bad Agile:

Bad Agile hurts teams in several ways.

First, Bad Agile focuses on dates in the worst possible way: short cycles, quick deliverables, frequent estimates and re-estimates. The cycles can be anywhere from a month (which is probably tolerable) down to a day in the worst cases. It’s a nicely idealistic view of the world.

In the real world, every single participant on a project is, as it turns out, a human being. We have up days and down days. Some days you have so much energy you feel you could code for 18 hours straight. Some days you have a ton of energy, but you just don’t feel like focusing on coding. Some days you’re just exhausted. Everyone has a biological clock and a a biorhythm that they have very little control over, and it’s likely to be phase-shifted from the team clock, if the team clock is ticking in days or half-weeks.

Not to mention your personal clock: the events happening outside your work life that occasionally demand your attention during work hours.

None of that matters in Bad Agile. If you’re feeling up the day after a big deliverable, you’re not going to code like crazy; you’re going to pace yourself because you need to make sure you have reserve energy for the next big sprint. This impedance mismatch drives great engineers to mediocrity.

There’s also your extracurricular clock: the set of things you want to accomplish in addition to your main project: often important cleanups or other things that will ultimately improve your whole team’s productivity. Bad Agile is exceptionally bad at handling this, and usually winds up reserving large blocks of time after big milestones for everyone to catch up on their side-project time, whether they’re feeling creative or not. Bad Agile folks keep their eye on the goal, which hurts innovation. Sure, they’ll reserve time for everyone to clean up their own code base, but they’re not going to be so altruistic as to help anyone else in the company. How can you, when you’re effectively operating in a permanent day-for-day slip?

Bad Agile seems for some reason to be embraced by early risers. I think there’s some mystical relationship between the personality traits of “wakes up before dawn”, “likes static typing but not type inference”, “is organized to the point of being anal”, “likes team meetings”, and “likes Bad Agile”. I’m not quite sure what it is, but I see it a lot.

Read the whole thing.