As Agile becomes widely accepted as a software development approach, many large organizations have adopted it, mainly in its Scrum form to reduce development cycle. There might be even a fair share of adopters that are trying really to apply Agile values. If the topic of scaling Agile has been discussed for many years and you can read the excellent books of Graig Larman and Bas Vodde on this topic. We have also recently seen the emergence of proprietary” approaches, like SAFE, to achieve this goal. At the same time, I have recently read many opinions about the fact that Agile is not working or might be dying.
The notion of scaling has two dimensions. An approach should be able to be used in larger projects and it should be also used by different software development organizations, each having their own culture. In a simplistic view, there are two approaches to craft a software development organization that produce quality software to meet the needs of users and produce value for business. You can define a prescriptive process that institutionalize “best practices” for software development and you implement them through training and a monitoring system to ensure that people follow them. On the other side, you can nurture a continuous improvement movement for your (good) software development people and you let them gradually create a good software organization. This could be summarized as CMMI/RUP versus Agile/Lean. Yes, this is a simplistic view ;O)
Whatever approach you take, you need discipline and at the end it is only people making good or bad decisions. We might think that we are all above average software developers or project managers, but statistics say the contrary. I doubt that the average quality of developers, project managers and business users has improved in recent years. When you scale a software development approach, you will gradually include people that feel less “concerned” by the output of your project or the need to change their working habits. The implied values of your approach have also more chances to confront with local and organizational cultural values that might be different. It is then inevitable that trying to scale any approach has its limits and increases the chances of failure. You should not consider your favorite approach as a silver bullet, but, paraphrasing Churchill’s definition of democracy, as the worst approach to software development except all the others that have been tried, as all approaches have their strength and weaknesses. I remember that years ago some Agile supporters where claiming a 100% rate and saying that if they were some failure it was because people were not “Agile enough”. It is true that when you eliminate users, people and printers, software development efforts have a higher success rate ;O)
As a conclusion, I will cite what Graig Larman and Bas Vodde wrote in the first page of their first book “After working for some years in the domain of large, multisite, and offshore development, we have distilled our experience and advice down to the following: Don’t do it”. You can try to scale everything, but you have to be aware of the negative side effects that are associated to this journey. So just follow the advice from the same authors “start small with a group of smart people and only grew when it really start to hurt”.