This is the second installment in my series on Agile development. In the first installment, I discussed some of the history around process expectations. This time I'll discuss some of the corporate cultures that Agile development upsets.
Corporate structures are command and control based. Every manager gets asked "what is happening, when will it be done, how much will it cost," so every manager expects to be able to ask that question and get a definitive answer. If I am running a factory, I need to be able to answer questions around how many units can be produced, what load are we currently running at, etc. At the executive level, that expectation naturally flows into the software parts of the company.
In the 1970's, there was an effort to put more process behind software development than the "code it and fix it" non-process that was happening. Some organizations were having success with iterative methods, but, in one of those twists of fate, iterative was going to take the backseat for a while. In the 1980's, the US DoD released a software procurement standard1 that was based on the waterfall model. This became the basis of procurement standards worldwide.
One of the key papers2 written in the 1970's that was used in support of waterfall development was written by Winston Royce. Ironically, the paper very clearly states that there is a need to plan on doing the development more than once before releasing in all but the most simple, straightforward systems.
So we have a management structure that expects top-down answers and a historical predisposition towards trying to manage the software lifecycle in a waterfall fashion. Much in the same way as "alcohol may intensify the effects of this drug", putting the two together causes greater mayhem. Many of the managers at a decision-making level in the marketplace today were the same engineers being taught the values of waterfall historically.
In other words, we have a layer of management who was instilled the values of the waterfall method. They were told that they could answer the questions their managers were asking them. And they were ensured that their products could be successful. Now, being on the other side, they need those same values, answers, and success. They want to go with what they know, even if it has been proven unsuccessful and down right risky.
I've discussed a little about how cultural history, corporate structures, and individuals' histories have made the adoption of Agile methods difficult. In the last installment of "Why It Scares Management", I will discuss the financial aspects that scare management. Following that, we'll begin talking about the benefits and how those can and should reassure everybody involved with the development process.
1. DOD-STD-2167, United States Department of Defence
2. "Managing the Development of Large Software Systems", Winston Royce, Proceedings of the IEEE Westcon, 1970