Introducing agile into a new organization, big or small, requires careful thought on how to do it. One important aspect is to determine why the organization needs agile. (See, for example, http://www.marcusoft.net/2012/06/experience-report-from-rolling-out.html).
However, this could also be viewed from another perspective.
Let’s assume that you have an organization that is not doing agile. Your organization is not team-based; instead it is running in a classic matrix organization with resource managers owning the resources that project managers are requesting for their projects. Your projects are using some kind of a waterfall model, with requirements analysis, development, testing and deployment as separate, sequential phases. When a project is done, the result is delivered to the end user and to another part of the organization responsible for maintenance.
Your organization is doing okay. Sure, things could be better, but this is the way it has always worked.
You’ve heard about this agile thing, but determined that this is not for you, not for your organization.
It’s about the people
Around you, companies and other organizations are changing their way of thinking. Being first in a rapidly changing market place counts, as well as being able to respond to changes in consumer and technology behaviour. For these other organizations, agile methods are necessary to survive. And so they adopt it, run with it, reach various stages of agile maturity.
But your organization do not. It is not for you, and perhaps you do not need to move that quickly; you have your product or niche and that has been working for you so far. Why fix what ain’t broken?
Your employees quit occasionally and you hire replacements. From where? Well, typically, you hire them either fresh out of school or they have been working for another of those organizations. In both cases, chances are your new hires have some experience with agile.
Also, it is very likely that your existing employees will see and hear what is going on in those other organizations, and hear positive things about agile and working in teams.
So, what is likely to happen over time? Will you be able to keep your best, high-performing employees, or will they quit and start working for one of the other – agile – organizations? Who will want to work in your organization? Will you, after a time, only receive applications from those that did not really like working in a team? Are those the individuals that you want in your organizations? How will you be able to attract the best competence? How much will it cost you?
There are many other arguments that could be made, in the same way – but I’ll stop here, at least for now. For me, agile is about people and their motivations. The point is that this works both ways – just as it is important to find a why (as in ”why should we”), it is important to answer the question what if you don’t.