Agile Software Development - Business Culture and Change

Traditional software development methodologies primarily focus on the process that an organization follows to build and release software. Agile software development methodologies approach software from a social perspective and advocate collaboration over strict processes. This is not to say that traditional methodologies ignore the social perspective or that agile methodologies ignore the process perspective.

Nevertheless, the methodological emphasis of traditional software development can become woven into the culture of an organization, making it difficult to adjust to agile methodologies. Large organizations would seem to have the most difficulty making changes to their culture (in general) due to the number of people they need to convert and the higher probability that individuals and teams are not in one location, making communication and reinforcement more difficult.

I have heard that deep cultural change in an organization can take 7-10 years to be successful—particularly in a large organization. While individual agile techniques predate some of the traditional methodologies, their working in synergy and the social emphasis did not come about until the late 1990s. But, putting it all together and gaining traction in an industrial environment are two different things.

As we sit on the cusp of 2008, I am starting to see some real traction in large organizations. Agile has matured as well: the zealots who wanted us to do everything in a one-size-fits-all fashion (while decrying similar calls from their more traditionally oriented bretheren) seem to no longer dominate the conversation. Nevertheless, I find myself wondering when that 7-10 year period began (or will begin, as the case may be) and whether we will be moving on to something else once that transformation is complete, as I am sure we will be.

In my own case, I think I can peg the beginning of that cultural change in my organization to early 2004 when, after a series of highly visible internal project failures, people began to ask whether they were developing software the right way. I have to admit that I was in the right place at the right time. I have always had a solid record of delivery and was asked to lead and "clean up" this troubled area. The fact that individuals were more likely to try something new is something I was happy to take advantage of. In the end, I was only able to go so far before the culture got in the way.

I guess that means we are only four years in. The next three-to-six years will be interesting.