Years ago when I was introduced to the agile process, I grasped the concept rather quickly and ran with it.  To me, it made total sense and I was all in.  As a team, we weren't full on agile necessarily (not even close), but it was a good start and we evolved.  Granted, this was a consulting group so adopting and trying things were a bit easier than it is for someone in, say, a large organization, but there are now a TON of big organizations on the agile adoption path.  I've heard many times over, "we're agile" ... and they're really not.  Old habits are tough to break, we're hard wired for it. It takes a good level of discipline to break it but that's if its just yourself.  With a team, it can be a mess.

Typically, there's a layer,  somewhere, deep within in the ranks that is all for agile (or at least really trying to do it right) and I see them kind of stuck and largely become frustrated.  [more]Stuck between procedures (tradition), policies (religion), paperwork, meetings, bottom lines, culture (work 'ethic') all the while trying so hard to figure out how to get better at writing software and enjoy doing it.  Remember the enjoyment part?  The reason why you work in software in the first place?

As of late, I've been trying to merge these worlds and explain why -- but I've noticed a trend that doesn't work.  We, and by we I mean everyone that have been doing it, insisting on this idea to be a better way...  We try to show examples, case studies, tools, etc of how but we never really explain the why.  How is easy to explain -- here, use this to fix this problem.  Why is far more complicated.  Don't believe me?  Talk to a 4 year old for a while.  I'll wait.

A team does not start miraculously one day and is "agile" -- and if they do, they're lying, it just never happens.  It's a process, it takes time. It's true, some adapt faster than others but that's why there are SO many tools out there to help teams "do the agile".  Even that's a bad excuse "we use tool because we're agile".  What it's really about is discovering how it all fits ...or doesn't fit.

What I think teams (coaches, everyone involved) miss is those initial steps, when the "why" is so crucial -- the "aha!" moment if you will.  At any point in history there's a moment in time when something happens and everything changes.  Not everyone is necessarily aware of it, but after it happens, everyone knows.  This state of transformation is often overlooked at the time because I argue that it's when then the why becomes clear.  Far too often a team is trying out their newly learned agile practices after some training or conference and they're excited about the idea but completely terrified of doing it wrong.  That transformation has to start somewhere and it starts by asking "why are we doing ?"

• Why are we having so many meetings when we have a deadline? (isn't delivery more important?)
• Why are we having to do so much busy work not related to delivering software? (shouldn't we be working on features?)
• Is this really to help us or is it a CYA clause?

Worry less about doing it wrong and more about getting code into the hands of the people that use it and thinking about "is this still the right direction?". That doesn't mean JUST features or code either, it means the team and how you operate.  Maybe kanban is the right answer today, but in 6 months its just gets in the way.  Maybe having a client sign off is the final step in delivery but now the client would rather just use it now and let that be the test.

All levels of adaption can vary wildly but MUST be questioned, regularly.  If they're not, at some point, they turn into "we've always done it this way" and the why will be completely lost -- and back to day zero.