Agile Software Development

I recently had someone pose a question to me that got me thinking about the scalability of agile success. Here was the question: "I'm part of large organization of over 1,000 people. Our small team of 40 has been using agile with a great deal of success. Now our company wants to me to extrapolate the successes we've enjoyed from agile (efficiency, value, profitability) to the rest of the company. Do you think the agile success of 40 people can be extrapolated to over 1,000 people?”

It's a great question and I don't think there is an easy answer to it. Speaking from my own personal experience, it's been difficult extrapolating the success our small team of five developers had in the past to our larger organization of about 35 people. There are many challenges as you scale agile up. Agile practices depend heavily on collocated teams that are cross-functional in nature. When you start scaling agile up, you need to consider geographic dispersion of much larger project teams that may not be as cross-functional as you'd like them to be. This is just the nature of large organizations.

I don't believe in repeatable results. I only believe in repeatable success.

Repeatable Results vs. Repeatable Processes
In his recent Agile Newsletter, using the results of the latest Dr. Dobb's survey, Scott Ambler showed his readers that most developers, project managers and IT managers prefer repeatable results over repeatable processes. Not surprisingly, according to his survey results, people in the agile community lean more towards repeatable results than those working in traditional organizations. Most respondents of Scott's survey also reported that their personal preference for repeatable results is bigger than that of their organization. Everything considered, it seems that there is a global shift towards a growing importance of repeatable results vs. repeatable processes.

When is a software product successful?

We all know industry reports (particularly the infamous CHAOS report of the Standish Group) are always saying that only a small number of software products are “successful”. But what does that mean? People have been struggling to find a proper definition for years and they are still not in agreement. One traditional view has it that a product is successful when it is delivered on time, within budget, and according to specifications. Others say that a product is successful when it matches a customer’s expectations, paying back its investment in the form of business value created, as laid down in a properly defined business case. Another view, often advocated by agile experts, is that a product is successful when the stakeholders are happy, whatever this may signify at the time of delivery. But I think they are all wrong.