Google Tech Talks, Scrum, and Jeremy

If I have time, I like to watch the Google TechTalks at Google's video website. The problem is usually time. Most talks last an hour. The good news is that most of the talks are pretty good so the hour doesn't seem so bad. The bad news is, it still takes an hour.

Lately, I've been seeing Jeremy (Manson), who got his Ph.D. at Maryland on the Java Memory Model, host these talks. Since he is a programming languages kind-of guy, he hosts programming languages kinds of talks. For the novice, that doesn't mean he invites guests who tell you how to program in language X. This is Google, and most people could figure that out there.

Instead, the talks are sometimes about stuff that's underneath the hood (how the basic implementation of a language is done) or some software ideas or sometimes it is a new language. The talks are generally far more pragmatic than in an academic setting. There's not likely to be talks on type theory and proofs in type theory soon.

Anyway, the most recent talk I heard was titled Scrum Tuning: Lessons Learned at Google by Jeff Sutherland, who apparently invented Scrum.

Let me quickly overview what Scrum is, then tell you the problems I had with the talk. Scrum is one of several competing ideas in agile planning. Agile planning is basically being able to plan in a lightweight manner. The goal is to get people to communicate and to fix problems as quickly as they show up. Since it's somewhat introspective by nature, problems in the process can be fixed as people involved notice it.

Two keys to Scrum. One is the daily meeting. Most people usually meet once a week. Scrum claims this causes problems, which are made worse with bright people. In particular, meeting once a week causes people to discover that one person depends on another too much, or that two people are overlapping on work, etc. With a daily meeting, you spot problems sooner.

Why do people avoid daily meetings? Of course, people hate meetings. If you're meeting, you're not working (well, technically, you are). Engineers typically hate meetings because there's a forced linear structure, where each person speaks one at a time. If someone stands on a soapbox, the meetings can drag without end while they deal with something only a small subset cares about.

Scrum tries to handle this by restricting the time of the meetings. The meetings should be kept to a minute a person or so. The goal is to find out what was done the previous day, and what will be done today, and what problems have occurred. There is a "Scrum" master who organizes the meetings, and tries to force it to be short. The master then decides how to adjust resources based on that meeting.

The other aspect of Scrum is task allocation and assignment. Typically, there is a brainstorming session where a bunch of tasks are determined, and then, estimates for each task is made. Any task taking more than a few days must be further broken down into tasks that only take a few days. The idea is that huge tasks are badly estimated. Short tasks are estimated much better.

Then, there is the Sprint. The Sprint is a period of time allotted to complete the tasks. These sprints typically last one month. Within the month, certain tasks are expected to be done. The daily meetings help assess whether things are going well.

Now to the talk.

Google is famous for running their organization without much hierarchy. Even so, because of the number of people involved, they sometimes run into issues when more organization is required. Jeff Sutherland talks about how Adsense had this project, whose project leader estimated would take 3 weeks to complete. They had identified 40 tasks.

In the first week, 8 were completed. In the next, 7.5. After two weeks, the manager said he thought they would be done in another week, as planned. There were still over 20 tasks left! Needless to say, it didn't get done the next week, when 9 additional tasks were completed. While they seemed to make good progress, the following weeks saw productivity go down. They had 4-5 tasks done per week towards week 5 and 6. Eventually, it took 7 weeks to complete what they said would be done in 3.

They were using some techniques of Scrum, but the question arised "what went wrong". Obviously, it seems silly to say it will take three weeks when 1/3 of the tasks were not being completed each week. But the point was, why did productivity decrease towards the end.

Jeff points out that while 80% of the tasks were done at some point, only 20% of the features were ready. He felt that was a bad mismatch. Features are important, and if you are 80% done, you need to have closer to 80% features done. But the problem with most features is that they have dependencies. It's easier to get partly done and make progress than to complete a feature until it's really done.

I'd imagine that Googlers would find this talk rather difficult and yet intriguing. Basically, the guy essentially promises that Scrum solves all problems, and he has numbers to back it up. That's it. He's an evangelist almost of the worst kind, but because he is talking about software development and has "numbers", it makes people interested.

What would be better is to track the same team, before and after Scrum, and see what things were causing problems before and after, and how things were handled better. In particular, track what each person is doing each day, and why Scrum seems to make that better (if it does). Numbers are fine. Productivity is fine. The question is why does it work, at its most fundamental?

Again, I love hearing about agile talks, and the ideas behind them. But it's so incredibly anecdotal. One thing I did read that was good was that initially daily meetings were very long, because it was new, but eventually, got much shorter.

And, you have to worry when a guy like Sutherland, who seems kinda very touchy-feely, begins to bandy terms like "infinitely scalable". He understands that certain terms have a certain ring to it. Thus, Scrum, Spring, burndown, and so forth. These terms are meant to have positive connotations, or at least, not be wrapped up in some jargon.

So basically, interesting to listen to, but awful as a whole. It piques interest without really providing good answers.