So, your boss is expecting an 8 hour day of constant productivity on a given project. He or she has planned on that code jockeying to meet a an agreed upon mythical deadline.  Your actual day, however, looks dramatically different than what you or your boss expected…

8:00am:    Phone rings – You’re asked to help a new employee who doesn’t understand the system you were part of implementing a year ago. You take an hour and a half to help out because a departmental manager who believes training is “an IT thing,” has conveniently passed the buck and absolved himself/herself of the responsibility.

9:30am:    You get a coffee break and vent to a coworker that training was not part of why you signed up. Your manager has seen and condoned this 1.5 hours, but still expects you to commit to the "deadline".

10:00am: You get an email that a self-important departmental manager would like changes to an existing system. He has escalated it to all departmental heads because the competition is doing it and it’s the latest priority #1. He is a predictable squeaky wheel, but he generates fear so well that IT is forced to drop everything and respond.

10:01am: You check in with your boss, and indeed, find out that this has been deemed “an emergency.” You both question the need for a steering committee governing best business interests, but realize that the company should have the ability to change its mind… And they do – often.

10:15am: You both hurry to meet the departmental head to understand this dangerous threat to the stability of the company and experience a venting session about how your software is non-competitive. The specifics are short, but the emotions are high, and IT is to blame for a sudden marketplace inequity.

11:00am: You decompress with your boss and attempt a course correction to help out Mr. Needy and his attempts to sully the credibility of the IT department.

11:30am: You’re still in the dark as to what the specifics of marketplace advantage translates to, so you go to lunch and spend an entire personal hour discussing and interpreting his needs while two tables over, he has a relaxed meal with the competition.

12:30pm: You check email and find there’s another departmental head with an operational crisis. It turns out to be something that’s happened repeatedly before, but your past help hadn’t championed any advocates – it had only created a technology (help-desk) dependency situation. You help the user find the ALT key, resize a window and listen to them talk for an hour about their fear of pressing the wrong button.

1:30pm:   You try to redress where your day has gone and what project it started out being. You start getting back to the project that you’re meant to be working on. You view the code, attempt to assimilate it back into to your memory and get on track. The conflicting needs of departmental heads predominate your thoughts and concentration and effort seems a joke if your priorities are forced to change tomorrow.

2:00pm:   You start to question your priorities with your manager. Your manager attempts to run interference but is conflicted by whose political needs will help his own cause. Everything seems to be Priority #1. There seems to be no visibility to the department or company on your ever-changing work schedule.

2:30pm:    Things go quiet for a while as if the drama might pass and tomorrow might be a set of new priorities. You feel like a pawn in a game with an allegiance to a department rather than a company. Because no new priorities have actually been set, you go back to your scheduled development work with a tinge of guilt because you’ve not really received any true guidance and instead, feel like you should be providing some.

3:30pm:   You get back to the code you were meant to start at 8am this morning.

5:00pm    Your boss stops by to ask about the progress of “the project”. He reminds you of "the deadline" while your mind wanders more consciously where your subconcious has been all day…..thinking about finding a new job. 

At the end of your 8-hour day, you’ve lost 6.5 hours against that project “deadline” (not including your personal lunch time) and are still expected to deliver a miracle. You wonder how tomorrow will look. You know it’s not predictable, and you know that the work you did today will not be accounted  for against the project. It will become invisible to your boss, the department and the company.

All they will see is the looming mythical deadline…and a false perception of IT incompetence. 

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?