Greg Aker

Is scrum a sham?

For most small companies, I think it is.

Filed in: Blobbing

March 29, 2012

An interesting post came out yesterday about how Agile is a sham. I've been on a few teams that have used agile development methodologies and in my experience, it just doesn't work. These methods try to make developers believe they have total control over the developement of a product. To me, that is the sham. However, I do see some valid situations to use these processes.

In full disclosure, I've never been on a product team with 20, 100, or even a 1000 developers that subscribe to agile techniques. However, I know quite a few developers who have been in this situation, and have talked at length about their experiences. For these teams, they are responsible for a small part in an enormous project. Their manager has a few managers and so on up the corporate food chain. These developers are usually paid pretty damned well, but more often than not, their opinion matters very little to the person who is overall in charge of their "product". All of that being said, more often than not, I hear that agile/scrum works for them, and works very well.

Getting cogs in a huge corporation to move in sync such a complex problem, I don't want to think about having to solve it. Team X might be waiting to implement something based on the API that Team Y is building. (Oh no scruministas, is that waterfall?!) So that being said, I think "agile" processes work in these situations. But let's stop kidding ourselves, a developer has control over things in their code like variable names and they way they structure loops, write their tests, and nothing more.

As human beings, we all suck at estimating the number of hours a task will take us. I've estimated things at a week that end up taking an hour. I've estimated things to take an hour that have taken me a week. You never know what kludge-fest you're going to get if you're going into legacy code that might be terrible or wonderful.

Next, let's talk about what motivates a developer. For me, there are a few things.

For the most part, developers of today aren't the tighty whitey-wearing nerds/geeks building their PCs that might come to mind for most people. We care about our company. We care about the products we working on. We want to build awesome shit and yell about how we built it from the rooftops. We're invested. We can't sleep at night if we feel like things aren't going right. Other than playing some Angry Birds on my iPhone or Wii Tennis with my wife, I haven't played a video game in many many years.

So this brings me to my gripes with "agile" at small companies.

I do believe that agile works in the case of a large company, however, it has no business in a small one. It burns developers out and makes them feel like shit when things go wrong. Execs, hire good developers who deeply care about what your company is building. Keep meetings to a minimum, shield your developers from clients and communicate, communicate, communicate. A developer likes feeling in the loop. Don't change things up on them mid-stream. Understand, their work is allowing you to make significantly more money than they do. They are cool with that because they know their work is having an impact. Be honest about your companies finances. Challenge your developers, stop putting arbitrary pressure on them, don't lie about the control they have. Screw story points and velocity. Show that you're passionate about your company building amazing stuff and you know your developers are the ones doing that. If you force Scrum/Agile down their throats, more often than not, your developers think it's a joke and go along just to appease you. If your developers don't buy into your passion for the company, find new developers and pay them well.

As for things a company can use from agile/scrum.

The key here is communication, people. Plain and simple. We all want to wake up and want to take on the world, not dread yet another standup meeting where we say the same thing as yesterday.

A small software company is just that, a software company. Stop worrying about processes and just build things. Are things moving slowly? Get rid of your middle management scrum master and hire another developer or two. That's going to speed up development significantly faster than anything else.