I have one of the best jobs in the world. I enjoy what I do and I get to help other people succeed. The challenging part of the work that I do revolves around organizational change. There are TONS of great articles out there and great science around cultural change management. What I would like to hit on here is more tactical.
In my workshops; when people are striving to implement some form of agile software development, we usually agree that "agile" itself is not a process. It is a set of values and principles that guide various processes that are said to be "agile". I love Dave Thomas' talk he gave @DFWScrum about "No one in the world is "doing", agile". His message was, you can't DO agile, you can only BE agile. I have carried that same message to my teams that wish to change and DO better.
Scrum (according to some surveys) is one of the most widely used "agile" processes. You can DO Scrum. Scrum is a tool to help you become agile. The goal is NOT to do Scrum, the goal is to BE agile and Scrum is a process that places certain constraints on a team to show them why they can't ship software within a certain time box (then of course they need to go remove those problems).
Now; let's dissect the word "agile" for a moment. Speaking to some of the authors that were in Snow Bird, UT when this word was chosen to reflect and embody a transition from traditional development to a new way; they had a very specific intent for the word. Adaptive and responsive to change is one of those themes. I never tire of hearing the arguments and debates that the original 17 folks went through back in February 2001.
Let's dissect the word for one moment. If you look it up on the Internet, the world agile means:
"the ability to move quickly and easily"
Many organizations look at this approach and say "why yes, we want to be quick (fast), lets do this agile thing". They turn the word agile into a noun when in fact it's an adjective. That's one problem, then the next problem is they focus on only one part of the definition; the word "quick". I try to help them focus on the word "easily" as well. Our goal is to move quickly (adaptive, responsive) and easily (conditioned and coordinated in our movement).
I am a pretty big guy (which is why I've been given the nickname @BiG_Agile). I used to play football and to this day, you would be very surprised how fast I can run a 40 yard sprint. You'd likely say "look at that big buffalo running so fast, I'm impressed". However, you don't want to see me after that 40 yard sprint. You'd likely think I need to go to the hospital. It will take me quite a bit of time to recover from the sprint. So, I was fast, but it took all the entire energy I had in me to do it and thus can't do it again for a bit of time.
I see software teams do the same thing. They want quick, they want speed, but they aren't willing to go through the conditioning, training, and learning required to be coordinated and make the change of direction and responsiveness "easier". If I want to run 40 yard sprints all the time and not have it suck the life out of me, I have to do it more often, train myself, and condition myself so I CAN do it often (removing all the problems that make me slower along the way).
Scrum is much the same way. There are many practices and behaviors that a team will likely need to learn to be able to compact all activities required to ship software into their time-boxed sprint. They need to start out with what they can do and then work to get better (see my other article on that).
Next time the people / organization you are working with say "we want to be agile", make sure they know that there will be training and development required for them to condition themselves. Much like a personal trainer, you let them know that they need to eat right and exercise, but they still have to be the ones to go eat right and exercise. That takes discipline and rigor and they need to understand that up front.
