Some Overhead is Good Overhead

A common complaint by software developers about Scrum is that it supposedly creates overhead by forcing them into a sprint structure with many meetings. This is somewhat paradoxical, considering that Scrum is basically an extension of how probably all software developers choose to work when left to their own devices.

When a software developer works on a piece of code, they compile it to see if there are any compilation errors. Then they either run their test suite or, if possible, run their code to see if it works as expected and check debug or log output to determine if anything went wrong. After writing some code, they once again compile the code and check if it works.

Now, how long, on average, is the interval between these compile/test/run/check cycles? Is it months? Weeks? Days?

My assumption is that in most cases, the interval is just a few minutes long and rarely longer. If for any reason, developers are forced into longer intervals, I believe that they become more worried and impatient, eager to finally see if their latest additions to the code are correct.

So why do developers do this? After all, every compile/test/run/check cycle causes a lot of overhead. In fact, it might take longer to compile and test the code than it took to write it. Why introduce such an immense overhead? Would it not be much more efficient to just write all the code and then compile and test it? Coding efficiency could easily double, couldn’t it?

Obviously, that suggestion is complete nonsense. No software developer would write 10,000 lines of code without even compiling it once to see if it is correct. So, developers naturally accept a lot of “overhead” in their daily work. And why? Because they intuitively understand that they are working on a complex problem that requires a lot of intermediate checking, fixing of unavoidable bugs or unforeseeable problems, and potentially replanning.

Scrum is only an extension of this natural way of working from a single-developer methodology to a framework that works in the same way for teams of several developers working together on the same product. And the “overhead” seen by many developers is only a reproduction of the intermediate checking, fixing of unavoidable bugs or unforeseeable problems, and potentially replanning. Any Scrum event serves only this purpose.

I guess the usual problem is that Scrum events are often added on top of other meetings that add little or no value for the software developers, so they feel that the Scrum events are adding overhead to their work. But I believe that all software developers can easily understand that an iterative incremental approach is the most natural approach to software development.