After some time off in December I've been back on the road and traveling every week since the start of the year. In that time I've noticed something new: people are telling me that Scrum is too much overhead. Too much overhead? I don't think so. "Too much overhead" isn't a complaint I heard at all last year, but I've heard it a handful of times since the start of 2006. These comments have surprised me --Scrum requires only a single fifteen-minute meeting each day plus a half- to full-day at the start and finish of a sprint. That doesn't seem like much overhead. However, by studying the teams doing the complaining, I have uncovered three reasons why some groups might harbor these misconceptions.
First, the teams may really be complaining about something else entirely. Comments like these could be symptomatic of Scrum adoptions that were started outside the teams. These teams, in effect, have been told that they will do Scrum because doing so has been established as a corporate direction. I believe there's a natural tendency to bristle at any direction given from above. Calling the few generative rules of Scrum "too much overhead" may be a team's way of expressing displeasure at having any decision pushed down onto them from above.
“Scrum requires only a single fifteen-minute meeting each day plus a half- to full-day at the start and finish of a sprint.”
Second, it is possible that Scrum could look like a lot of overhead to a team that was running with almost no process at all. However, I'm skeptical of the ability to a team to consistently deliver valuable products with much less "overhead" than Scrum. There just isn't much that you could cut out of Scrum in order to reduce overhead. In one of the cases I encountered, the perception of Scrum's overhead seemed to stem from the cost of iterating every two to four weeks. Prior to adopting Scrum, this company was not using an iterative process at all. The need to periodically drive the software to a shippable state must have felt like needless overhead to some individuals in that company. On the other hand, their prior process led to late products that missed on fully fulfilling market needs.
Third, the individuals who believe Scrum is a lot overhead may not fully understand it. They may be looking only at the new things they have to do (daily Scrum meeting, sprint planning, sprint review, and so on). They may not yet see the benefits they will get from Scrum, such as greater visibility into progress, closer contact with customers and users who can validate that the most-desired features are being built, closer coordination and greater communication with coworkers to ensure all team members are heading in the same direction, and so on.
If Scrum feels too heavy or as if it has too much overhead, it likely is being done incorrectly. I first ventured into Scrum because I desperately wanted a process that would allow me time to work as a manager of teams but also to program on the systems we were developing. Scrum appealed to me because it was lightweight, the management needs were low, and it wouldn't take much of my time away from programming. Those characteristics just don't mesh with complaints of high overhead. An astute ScrumMaster will hear these comments as a warning signal and investigate to determine the true source of the problem.
