Right after some time off in December I’ve been back on the road and traveling each week considering that the begin of the year. In that time I’ve noticed something new: folks are telling me that Scrum is too much overhead. An excessive amount of overhead? I do not think so…
“Too much overhead” is not a complaint I heard at all last year, but I’ve heard it a handful of times considering that the start of 2006. These comments have surprised me?aScrum needs only a single fifteen-minute meeting every day plus a half- to full-day at the commence and finish of a sprint. That does not seem like considerably overhead. However, by studying the teams performing the complaining, I’ve uncovered 3 reasons why some groups may possibly harbor these misconceptions.
First, the teams may possibly actually be complaining about some thing else entirely. Comments like these might be symptomatic of Scrum adoptions that were began outside the teams. These teams, in effect, have been told that they are going to do Scrum since performing so has been established as a corporate direction. I think there’s a natural tendency to bristle at any direction given from above. Calling the couple of generative rules of Scrum “too much overhead” might be a team’s way of expressing displeasure at having any choice pushed down onto them from above.
Second, it can be feasible that Scrum could look like a great deal of overhead to a team that was running with practically no method at all. Nevertheless, I’m skeptical of the ability of a team to consistently deliver valuable items with significantly less “overhead” than Scrum. There just isn’t considerably which you could cut out of Scrum in order to minimize overhead. In among the cases I encountered, the perception of Scrum’s overhead seemed to stem from the cost of iterating each two to four weeks. Prior to adopting Scrum, this organization was not employing an iterative method at all. The want 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 method led to late goods that missed on fully fulfilling market wants.
Third, the people who believe Scrum is really a lot of overhead may possibly not fully understand it. They may be searching only at the new things they’ve to do (daily Scrum meeting, sprint planning, sprint review, and so on). They may possibly not yet see the benefits they will get from Scrum, for example greater visibility into progress, closer contact with customers and users who can validate that the most-desired functions are being built, closer coordination and greater communication with coworkers to ensure all team members are heading inside the identical direction, and so on.
If Scrum feels too heavy or if it has an excessive amount of overhead, it likely is becoming performed incorrectly. I initial ventured into Scrum since I desperately wanted a method that would enable me time to function as a manager of teams but also to program on the systems we had been developing. Scrum appealed to me due to the fact it was lightweight, the management needs had been low, and it wouldn’t take significantly of my time away from programming. Those characteristics just do not mesh with complaints of high overhead. An astute Scrum Master will hear these comments as a warning signal and investigate to determine the accurate source of the difficulty.