Bill Wagner has a great post on agile titled “What can we learn from the Agile Backlash”
Every time I read about agile I’m reminded of how distorted my view of agile had become because I was listening to everyone else’s distortions of agile. I always go back to the manifesto and read a few simple words
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to change over following a plan
The rest of the manifesto is important too, but I find these points are to what I come back the most often. It took someone smart figuratively smacking me in the face for me to notice how messed up I was and then I noticed how messed up many others are on the meaning of agile. (Thanks Amanda!)
Something that agile states is that your goal is to write software in ways better than you are doing now. This is from the first sentence of the manifesto, “We are uncovering better ways of developing software…” What I’ve noticed on a current consulting project is that agile is not applicable if the team (or client) is not interested in this goal.
Unbelievable I know, but not everyone is a software developer and so developing software in better ways may not be important to everyone. Specifically, it probably isn’t important to management, until you can show management that it saves them money.
Even given all of that evidence, some groups may still not share values with agile. For example, favoring individuals and interactions over processes and tools is not going to fit into an organization whose top down leadership absolutely requires people to use tool X from vendor Y, and it doesn’t matter that it doesn’t fit the current project or that it slows down velocity. It doesn’t fit when developers (individuals) show evidence (Mythical Man Month is the tip of the iceberg) that working on many projects causes thrashing that greatly hinders developer productivity when the organization doesn’t value delivery of software in a timely manner, but instead values a high number of concurrent projects. Its not that one set of values is necessarily better than the other, there might be a very good business case to retain existing values in that organization over the agile values.
Finally, it is of absolute importance as a consultant, programmer, team lead or program manager to recognize what you can change and what you can not in any organization. Sometimes you won’t know and you may go ahead trying to get some change. This is fine, but always be on the lookout to see how well that change is being adopted and be ready to “respond to change” even if that means not adopting agile in that particular situation.