Greg Aker

Is scrum a sham?

For most small companies, I think it is.

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.

• Building something I think is fucking awesome and I'm proud of.
• I'd rather be building things than be in meetings.
• Solving interesting problems.

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 hate meetings. Meetings are for execs. I'm not in it for the pension like some might be at a goverment agency or large company. I care about how much I'm getting done, and I feel like shit when I'm billing meeting time back to the client. Depending on the sprint length, I might be in meeting 2 days a week. If my team is 4 developers, that's 64 out of a possible 160 hours of dev time spent in meetings! Do the math execs, is this worth it?
• Along with other members of my team, I'm smart enough to realize that despite what you say, I have no control. This is my single biggest gripe with Scrum. I don't need my middle management Scrum Master telling me I have control when I know it's a flat out lie. Be honest with me.
• What the hell is "velocity"? I see this as an arbitrary number that means absolutely nothing. A dev goes on vacation or gets sick, your team velocity goes down. You run into a serious problem that takes significatly longer than you thought? Velocity goes down. So is this arbitray metric something to just make a developer feel like shit when things don't go as planned? Sure I know you're supposed to burn up, but on a small team, you should all be communicating. If your company culture doesn't suck, the other developers will know about the issue, they might be helping you. The execs, product owners, or whatever you call them should be kept in the loop too. If the exec doesn't try to communicate, you have way more issues to deal with.
• Publicly communicating release dates put undue pressure on developers. I've pulled all nighters to make these deadlines due to things going wrong. That's no way to live life. My quality of life suffered. If a developer isn't proud of what she/he has done and isn't ready to release it, then an exec needs to back up and understand it. If you need another day to be comfortable, the world isn't going to end. We build things on the internet. It's not like we are a Nurse Anesthestist or an Anaesthesiologist keeping a patient sedated and alive during surgery. A small team isn't building something like Facebook. The company generally isn't going to lose big bucks over missing something by a day.

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.

• Backlogs This is great. It's nice to know what the execs are thinking we need to do in the future.
• Epics/Stories Have your UX designer do these. They should communicate with developers as they go, but this saves a lot of work.
• Test your fucking code If you don't want to go all-in with TDD, subscribe to "Oh Fuck" or "Stupidity" driven development. Write regression tests, write tests to make sure complex actions work the way they are supposed to. Spending a few weeks to get tests up and running is going to save you time and money in the long run.
• Pair Programming can help in some situations Have something REALLY complex? Maybe two sets of eyes on it would be helpful. There's no reason to pair program "hello world" or 1 + 1. Use your head here and do what makes sense.

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.