These days a lot of companies seemed to be interested in either adopting agile or trying agile in a sandbox. If the underlying reason for this interest is misplaced then this is actually not a good thing. If you are testing the waters with agile because you are not happy with your process heavy methodolgy then you can find success, however if you are happy with that methodolgy and are just wanting to just do a clean swap with the newest trend then you need to just stop right now.

Approaching things in an agile and lean manner is a philosophy, and as such it's not something you do only while at work or even during a certain project. Some people will always run and be comfortable with a waterfall project because that is their internal process. 

Planning

If you are an inherent 'planner' then being agile to you will feel very chaotic and out of control, however it is mearly about only planning as much as necessary and delaying decisions until the last possible responsible moment.

You might be a waterfall-ist if:

• When planning a family vacation are you the type that planned on Thursday 4 days from now at 1:15PM you will be stopping by the worlds largest Starship Enterprise?
• Instead of going to the grocery store every 2 or 3 days to food for what you feel like at the time or do you buy 10 lbs of beef at a time from Costco and commit yourself to eating it all that week even if you find out Wednesday that all beef was a bad choice?

Being agile is not making so many plans that you are heavly invested in them not changing, instead you should be able to switch directions quickly enough to respond to changes or unforeseen obstacles. As valiant as it seems sticking to your orginal plans no matter the developments along the way, it is actually not good decision making. Unless your filming National Lampoon's Business Vacation, then you can go crazy Clark.

Constraints

Another attribute is how do you handle failures or other undesired results. If you have seen huge process maps with seemingly endless hoops to jump through to get work done, its most likely the result of over compensation for failures. Everytime something has gone wrong in your process, it is not an immediate invitation for extra constraints, contstraints in a process should exist to provide benefits not to just stifle flow. Sometimes the cost of a failure is less than the cost of the constraint, in which case it makes more sense only to work on lessening the impact than to implement a prevention constraint. If you don't know the cost of the failure or the constraint then it's irresponsible to implement one.

To put this into everyday perspective… car wrecks happen everyday and people get seriously injured and even killed. This is obviously a very bad result that can be solved by constraining car speed to 5mph. While this will work the cost of this constraint is quite massive and not ultimately beneficial. A better solution than simply slowing traffic to a crawl would be to develop smarter and safer cars to make wrecks less dangerous.

So before you go out and try to do an agile implementation do you think you have the mindset for it?