I think I figured out why Steve Yegge was so inclined to bash Agile yesterday. It’s actually rather obvious when you think about it. I don’t think it’s some recruiting scam, like some do. No, there’s a much simpler explanation. Steve likes Google’s practices, and is trying to warn other Google employees away from Agile. It has nothing to do with the rest of the world, unless of course you’re lucky enough to have practices like Google, which work.
He went astray by thinking what’s bad for a group of Google newbies is bad for everyone. That’s an easy mistake to make since he probably spent at least 20 times more time with those young Google employees, and other Google employees then with other programmers, at least recently. I don’t really know anything more about the Google process than what Steve told us, but it sounds like it has promise. More importantly it’s working. It might be better than Agile. I say might because I don’t really know. To be honest, I’ve never had the opportunity to participate in an “Agile” project, but I’ve employed bits and pieces in different places over the years. And from those experiences one thing has been clear: anything is better than waterfall.
I can understand how, given his pre-existing skepticism, and observing a few Googlbies having problems with Agile, he might lash out. But Steve is wrong. Those Googlbies might actually be ditching a great process for a merely good process, but for the majority of us out here, the question is completely different. For us, for right now, Agile is the way to go. It’s not easy to convince management to try it, but I think it might be easier than asking to become Google. For example, if you wanted to be more like Google, the first thing you would do is fire 90% of management. That might not be such a bad thing because most bad agile is the result of bad managers who can’t adapt to the principles of agile, who keep trying to force old principles and values into the system. Principles like overwork, whipping and unrealistic date-driven development. But managers have most of the power at most companies, and it seems unlikely they’ll sign on for that plan.
The next items on the checklist are basically developer freedoms, which are hard to do if you skipped the first step and still have bad managers hovering around. Maybe you could get away with stripping those managers of their authority, so that hovering isn’t so destructive. But, I have a feeling they won’t sign up for that plan either. I mean the majority of the bad ones became managers because they crave authority, so they aren’t going to give it up easy.
Like many people have mentioned, these are people problems. What Agile is good at doing is creating an environment where management actually starts to understand what developers do. After that they’ll start to delegate more authority to the developers. Maybe one day everyone will end up like Google, but that’s not an easy change, and before anything like that happens management will have to first learn to trust development. Google probably works because management IS development. And I don’t just mean the guys at the top; I mean almost all of it.
However, the point behind all of it is trust. And trust is a tricky thing. A lot of people forget trust has two parts. The one most people focus upon, is a belief in honesty or integrity. But there is another part, a belief in capability. This division is the source of many arguments. People take it very personally if you say you don’t trust them. Much more seriously than if you simply said you didn’t think they were capable. It’s not very flattering to be told you’re not capable, but it’s a lot less insulting then to be told you’re not trusted, even though usually they mean the same thing.
In the workplace, you’ll hear people say they trust so and so, but only in the most confidence will you ever hear someone mention who they don’t trust, no matter which type of trust is involved. This is unfortunate, because when it’s a lack of trust in capability, people should know so they can respond rationally, either by proving their worthy of trust, or by improving. But trying to do this is like walking through a minefield. You never know when someone is going to blow up. Even if there is a pot of gold on the other side, is it really worth the risk?
Another part of the problem is that management often does not trust themselves, though they won’t easily admit this. They don’t trust themselves to spot the bad apples, or the incompetent. To deal with bad apples, they resort to paranoia. In their defense, part of the problem is that they are hindered by legalities put in place to protect minorities, disabled and other protected groups, they have a secondary effect of making it much more difficult to fire (or at least not promote) the incompetent. That’s a tough issue because at least for now, those groups do need some protection, and no one has found a better way of insuring it. Maybe sometime in the distant future we’ll fix that problem, but for now it’s a bit harder than any of our development quibbles.
To bring this back on track, Agile development is intended to encourage communication that promotes trust. It’s intended not only to help the developers understand the customer’s needs better, but also to help the customer understand the developer’s role better. Waterfall on the other hand attempts to squeeze every ounce of risk out of any decision. Unfortunately it makes the mistake of forgetting that by avoiding a decision, you have made a decision; a decision to stall.
And stall is what happens to project after project under a waterfall development methodology. By the time a decision is made, there may be no chance of misstep, but you’ve taken a considerable penalty for that piece of mind. Even worse you often find that things change so rapidly, that this point is unreachable. Organizations try to make up for lost time by cramming the follow up to the decision in unreasonable ways, and well.. we know what happens then, don’t we?
This has been quite a ramble, even for me, but overall what did I say? We need trust, Agile is a path from the here and now to trust, once we have mutual trust we can tackle the next stage, and according to Steve, Google already has done all of this. Wow, can that really be true?