[mattmanser]

I've read your comments a couple of times and still can't really see what you've added.

You're talking about very abnormal situations. Companies that are so technically incompetent they have to hire you.

And then saying that we should listen because in your abnormal experience of dealing with teams so dysfunctional they can't even ship bad software that agile at least gets them going a little bit.

I suspect almost any change would get them going a little bit as the change itself is the trigger.

EDIT: The more I think about it, the more your comment reminds me of the people defending the other fads of years gone past. Workflow diagrams, OOP-design (as a be-all-and-end-all process), UML, Worflow Engines, RAD tools. Your comment reminds me of the defences of them. These things worked because those desperate teams need a light to guide them, not because of the tool itself.

And with each of those tools, it turned out the tool itself is mainly counter-productive to functional teams. I think we're realising Agile is another of those false prophets.

[hpaavola]

The thing is that following situation is really common:

Company has an average team, maybe even bit worse + 1 good person. The managers are not that great either. Everything is average.

The team has been doing something, nobody really knows what, nobody really knows at what pace. Nobody knows what they should be doing.

Occasionally the company releases something which sells a bit and customers give some feedback. Mostly not that great.

When you tech them a bit of Scrum, help them get builds every night and help managers to try out the product once in a while (remeber, not all software is a website, some are airport weather observation systems). And help the company to get some of their customers to try out the software once in a while even though it is not "ready".

Suddenly the results of the team is visible to interest groups and interest groups needs are visible to developers, managers can get some idea of the velocity and everybody can have a better idea where we are, where we should go and when we might get there. Then iterate and improve.

What we have done here is that we improved the quality of the company with really little cost with our existing talent pool.

Yes, this is really common.

[ahomescu1]

> Company has an average team, maybe even bit worse + 1 good person. The managers are not that great either. Everything is average.

I think the application of the OP here is "fire the bad/mediocre managers, put that 1 good tech person in charge". Couldn't they do that?

[exelius]

I disagree. The "companies so technically incompetent they have to hire consultants" are the norm. Think Fortune 500 companies developing internal software tools here; a lot of these guys are still stuck in the "we release software every year and hope the requirements haven't changed" mindset. Meanwhile the "customer" expectations have changed: people expect faster releases because Google, Facebook, Netflix, etc. update their shit every month. The business environment changes quickly too; the old development ways just aren't fast enough to keep up.

Agile helps force groups like this, who have been doing things a certain way for a long time, to re-think how they manage requirements and release schedules. Most likely, the developers at the bottom level have been screaming about this for years, but middle management doesn't hear them because they're stuck in meetings all day having to explain why all their projects are over budget because change management costs are through the roof. Along comes Agile as a solution to all of this.

This isn't a technical problem, it's a management problem. So yeah, a lot of these companies hire consultants to come in and tell them how/what to do because consultants have no skin in the game and aren't involved in the typical petty management squabbles.

[ctb_mg]

I also disagree with the premise that these situations are very abnormal. Ours is a big field which expands outside of sunny California, where you can't walk a few feet without bumping into a rockstar coder. In the rest of the world where the mediocre is the status quo, Agile gets team members organized and motivated. Of course, if you could find rockstars, you'd hire them, solve many problems, and ship your product. Not everyone has the pleasure of that kind of engineer pool.

[mattmanser]

I actually live in Nottingham, UK.

Here there's dev meetups, Second Wednesday, Notts Tuesday and probably more regular events I don't even know about.

I've talked and worked with a lot of developers round here now as well as interviewed with a fair few companies and done their technical tests and talked to their lead developers.

A lot of them write better code than I've seen in the github repos of Californian 'rockstars'. And yes, there's plenty of bad code too, out-dated practices, people asking me if I know VB.Net. And yes one of the companies I worked at (oh so briefly) had terrible code.

No different from the Californian mecca I imagine. Do you think that only good developers go to SV. There's no magic forcefield keeping bad developers out of California. In fact because SV is so desperate you might even argue they probably have a lower average standard.

There's plenty of shipping, successful products coming out of this city and successful IT Teams working for other industries. And bad ones.

[twic]

The question is whether this is abnormal or not. I suspect that it is not. That is, i suspect that there are many more mediocre-to-poor developers and managers out there than there are good-to-excellent ones.

[hpaavola]

Exactly. Then the questions is how we can make most of us to perform better. The answer is not to "be excellent developer". The answer must be in the way we do things.

[_ea1k]

I disagree with your assertion that this is a "very abnormal situation". However, I think that I agree with your main assertion.

The improvement isn't really specific to bringing in Agile, but rather to giving the team a clear focus, and way to measure their improvement in deliverables. There are many ways to do that, it's just that Scrum happens to be a relatively straightforward and lightweight way to introduce that in a way that is compatible with many of these teams.

Unlike a lot of those bad approaches, though, I don't think Scrum is necessarily a hindrance to a properly functioning team. There are a lot of good ideas in Scrum that are designed to get obstacles out of the way, IMO.

[chiph]

It's not that they're incompetent - it's that they don't think about their work abstractly. They're intently focused on cranking out code, and anyone who pops his head up and says "Wait a second, is this the right thing to do?" gets taken aside by management and told: "I need you to focus on meeting your deadlines, not that other stuff".

Agile has to start with management adoption. And not Fake-Agile™ either. I've seen a PowerPoint slide a few times now that lists "Iteration 0 - Envisioning" as a bullet point. It's like RUP got painted with Agile terminology. And everyone in the room nods their heads knowingly because it's what they've been doing all along, only now they're Agile.

[joesmo]

The situation described above is far and above the norm in the industry. Bad code, bad management, bad practices, bad developers are all the norm. The abnormal situation is one where things aren't FUBAR. FUBAR is the norm.