Casey viator@Colorado Experiment - photo credit to oldtime strongman
“If you find a man in the desert who has been digging a hole with his bare hands for months and you show him a shovel, he will probably try to kill you with your own tool. If you dare come back later, he will still be digging the hole with his bare hands, even though he still has your shovel with him.” — Unknown
The muscle memory theory
In 1973, the Colorado experiment was conducted in order to test the effectiveness of brief and extremely intense exercise. The pictured subject, Casey Viator was a de-trained bodybuilder coming off a year long layoff. The experiment lasted exactly 4 weeks. By the end of the 28th day, he had gained 63 pounds of muscle and lost over 17 pounds of fat. To the author’s knowledge, such results had never been produced prior to this experiment and have not been replicated since. The results have often been attributed to “muscle memory”.
The theory behind muscle memory is that the body always tries to maintain a certain balance. In order to grow, it has to be overloaded in order to give the body the signal it needs to adapt. Over a period of time, once the body grows accustomed to a certain level of muscle size/strength it then becomes the the new balance the body tries to maintain.
When someone is under stimulated, the body will regress somewhat rapidly until it falls back to it’s “balance level”. Once there, it will try to hold on to the balance it was accustomed to. Eventually, since it is under stimulated, it can actually regress back to previous levels of size/strength since higher levels are no longer required. But with proper stimulation, it can grow back to the previous maximum levels in less time than it first took to reach those levels because of the so-called muscle memory.
When it comes to human behaviour, the same phenomenon is visible. Just like with with muscular balance, the body seems to try and maintain it’s comfort zone as some sort of defence mechanism. Once taken out of the comfort zone, it often triggers the reflex of going back to the old ways of doing things, no matter if it the previous behavior has a positive effect on the person or not.
An Agile transition as an example
When putting forth a transition in an enterprise such behavioral patterns must be understood and dealt with. Let’s take an Agile transition that takes employees who are used to a very hierarchical environment and are moving into self-organized teams as our example.
Applied to teams
For starters, let’s take a look at something as simple as task assignment. This shouldn’t be rocket surgery right ? Well, it depends on you standpoint. Many people have become so accustomed to having tasks assigned to themselves they have a hard time dealing with the relatively simple responsibility of self task assignment. Actually, many people will look around for somebody to assign something to them or pretend they are committing to something while in fact they let everybody else decide and take what’s left.
Just dealing with the Product Owner on the appropriate scope of a sprint is something a lot of team members might find hard at first. Telling no to somebody who is asking you to do more stuff is not the usual behaviour most of us are accustomed to. Not convinced. Here are some examples. When we were young, we were expected to do what our parents asked us to do. In school, we were supposed to act the way the teacher asked and to do all our homework. At work, we are supposed to accomplish whatever work we are asked to do. See a behavioural pattern there ?
On the technical side, it is quite the challenge to ask developers with 20 years of experience who have never written a single test in their lives to do all their programming test-first. By TDD we don’t just mean writing test. What we mean is that while developing software, not a single line of code is written without a test written to test it first. None.
Funny thing is, once most people get the hang of TDD, they will have a hard time going back to your old ways. Unfortunately, you will often find programmers skipping tests altogether, even though they are at least aware of the benefits. In extreme dissonant cases, some will be sabotaging their own work on purpose for no apparent logical reason other than to maintain their previous ways of working.
Applied to managers
It also works the other way around. Having power over people is something that is seemingly very hard to let go of. In Agile teams, management is often seem as an umbrella protecting the team or as a coaches. Either way, they are helping the team attain it’s goal while supporting it when it needs to and protecting it from distractions. Other responsibilities might be helping team members get the proper training and also by keeping them on track regarding delivery objectives.
It requires a lot more soft skills to be a successful Agile manager than to simply be someone who’s main attribute is to dispatches work. It also involves the humbling task of letting go some of the grasp managers often have over every doing of their employees. It is only too common to hear about managers embracing Scrum, only to find them minutes later behaving exactly as they were before. This is done in spite of them being entirely aware that their previous behavior is unproductive and is what conducted the requirement for change in the first place.
Just like with weight training, it takes a long period of stimulus for the body to recognize the current state as the state the body needs to maintain. It is the same with change, the longer you keep at it, the more and more it will feel natural and it will just become the new habit. Remember, some things you think of as an habit now might have once looked to you as insane too.
-Nicholas Lemay
