I consider myself a proponent of agile methologies (such as Scrum) and agile project management. I support and live Agile not because it is a fad but because I believe it is the right approach to running projects and develop products, especially when we are talking about developoing software. The good news that more and more companies realize the immense value Agile brings to the table. This is not limited to smaller projects in IT. Whole companies such as Amazon, Google or Zappos embrace the philosophy of agile. Such companies stress the importance of delighting customers, adding value first. Consequently the output, i.e., money, is much better than in traditional management models.
Having introduced Agile methodologies to a number of companies such as TuneUp software my experience is that Agile works. Or, shall I say, can work. For you have to be aware of some pitfalls the introduction of Agile brings. To start with, you have to understand the project and company environment. How did it manage projects in the past? How open are people to new approaches? How fast do requirements change? – And, how dogmatic are people about their past (and present) methodologies and beliefs?
This last question goes in both directions. Namely, it is easy to pinpoint those who we call traditionalist, waterfall proponents. But we should also ask us, how dogmatic are we about Agile? If you force Agile into an organization without preparing the soil, you are likely to fail. Not because your methodology is flawed, but because of your own flawed myopic mindset. Agile calls for an open attitude to new and changing environments. This is the counterpart of any dogmatic belief structure. Hence, I have always been very skeptical of those folks who believe, for example, that Scrum can be introduced and practiced only in a certain way, i.e., by following the pure textbook. It may work in some settings. In environments where people, especially managers, are skeptical about anything new and resistant to change, we have to be flexible. We may have to come up with ways to gradually introduce agile elements, avoid the typical Scrum terminology, use established planning techniques (at least for some time) rather than throwing all former templates and methodologies overboard. It is a matter of respect and professional maturity. Watch, listen and learn before you come up with a solution. And best, help the customer find it. Don’t talk about theortical constructs, show how Agile works in real life, involve the customer and let the customer realize the immense potential value Agile brings with it.
There are endless blogs about the right use of Agile. A recent discussion on Mike Cottmeyer’s blog post “Why is Agile hard to sell?” is especially worth mentioning.