Scrum and other Agile methodologies have spread very quickly, which is good, but the essence of what they’re really all about hasn’t spread quite as far yet. Object-oriented programming (OO) was very popular starting in 1990 and almost everyone uses an OO language like Java, C++, or C#. But when you look at their code they’re really not using OO; they’re not really understanding the essence of the advantages OO languages have over procedural languages. They’re not using objects to encapsulate behavior, to increase testability and decouple designs…It’s just procedural code wrapped in a class statement.
Sort of the same thing is true with Agile. “The State of Scrum” came out in June 2013 and reported that 40% of the companies surveyed—and I think this is a good cross section of the whole industry—say that they’re doing some form of Scrum. But when you ask them what it is they’re doing you find they’re doing stand-up meetings and iterations, and they’re not even taking those iterations and bringing them to completion. Only 13% of those organizations are practicing continuous integration and only 37% of the organizations practicing continuous integration integrate daily or more frequently. In other words, fewer than 5% of the companies who say they are practicing Scrum actually integrate their code at least once a day. They’re taking tasks to a point where they’re not quite done and sticking them somewhere near the end of the cycle, and then they test it.
That’s Waterfall.
You’ll see some benefits, but you’re not changing the game. Scrum isn’t an all-or-nothing proposition. There are elements of Scrum methodology that you can do that will help in certain areas. But in terms of risk, it is all or nothing. It’s binary. You either have risk or you don’t have risk. When you have risk, it’s unknown. That’s why it’s risky.